SQL Azure'daki Veritabanınızı Yedeklemek

0 dakikada yazıldı

29906 defa okundu

Düzenle

Daha önceki yazılarda SQL
Azure konusuna göz atmış ve geçişin kısmen de olsa ne kadar kolay
olduğunu görmüştük. Genel PAAS manzarasında geçişin en kolay olduğu veya
diğer bir tanımla grilerin olmadığı :) siyah ve beyazların olduğu bir
migration süreci gerektiriyor SQL Azure. Bu yazıda ilgileneceğimiz kısım
ise "backup" senaryosu. Doğal olarak SQL Azure'daki veritabanınız
belirli aralıklarla backuplarını almak isteyeceksiniz. Bu problemin
çözümü için birçok yol önerilebilir. Yedekleme stratejisi yerine veriyi
azure ortamından dışarı çıkaracak scheduled bir kopyalama stratejisini
de tarcih edebilirsiniz. Tercihlerinizi tabi ki iyi düşünmek ve
planlamak gerek. Şimdilik odaklanacağımız kısım Azure'da datacenter
içerisinde yedek almak olacak. Bunun avantajlarından biri yedeği aslında
yine belirli bir SLA sağlayan Azure ortamında, Cloud'da tutuyor olmanız.
İkinci büyük avantajı ise restore senaryosunda yedeğinizin zaten
Cloud'da olması ve restore'un olabildiğince hızlı gerçekleşebiliyor
olması.

Konunun detaylarına girmeden önce, özellikle SQL'da "High Availability"
konusuna hakim olmayan arkadaşlar veya bugüne kadar ihtiyacı olmamış
arkadaşlar için SQL Azure ortamındaki "backup"'ın ne anlama geldiğine
hızlıca bakalım istiyorum. "High Availability" derdi olmayan bir ortamda
backuplar hem altyapının hem de yazılımın olası hataları ile başa
çıkabilmek için alınabilirler. Tabi ki ihtyiaçlar sadece bu kadarla
bitmiyor ama listenin üstünde bunlar var. SQL Azure ortamında zaten
veritabanınızın iki replikasının olduğunu hatırlarsak backup alma
sebeplerimizi oluşturan liste biraz daha farklı şekilleniyor ve olası
yazılım hatalarına karşı önlem alma maddesi daha önce çıkıyor. İtiraf
etmek gerekirse ideal durumda zaten aldığınız backup'ı kullanmak zorunda
kalmamalısınız. Eğer 2 replika yetmez bana diyorsanız yazının sonunda
normal backup senaryosu ile entegre bir tavsiyede daha bulunacağım :)
Neden mi? "Restore" dediğiniz şey anlık gerçekleşmiyor sonuçta ve bir
downtime söz konusu olabiliyor. Cloud'da SAAS sattığımızı düşündüğümüzde
downtime kesinlikle göze alamayacağımız birşey.

Peki nasıl olacak bu işler?

Teoriyi biraz kenara bırakalım diyeceğim ama birkaç şeyi daha
netleştirmemiz gerek. Hatırlarsanızeski
yazılarda

SQL Azure'da backup yok demiştik :) Aslında var... Azure'da veritabanı
yedeğinizi almanızı sağlayacak bir servis mevcut. Bu servis Azure
Management Portal'ının içerisinde. Yedeğini almak istediğiniz
veritabanının erişim bilgilerini ve yedeğin konacak Storage Hesabının
erişim bilgilerini vermenizle beraber aslında bir yedek talebinde
bulunmuş oluyorsunuz. Bu talep arka planda işleniyor ve yedeğiniz bir
BACPAC dosyası olarak Storage hesabınızda bir bloba yerleştiriliyor.
Blob'un bulunduğu Container'ı "Private" set etmeyi unutmayın :) yoksa
dosya adını bulan veritabanı yedeğini güzelce indirir :)

Herşey çok kolay geliyor kulağa değil mi? Ama birkaç sorunumuz var.
Birincisi management portal'ında sunulan bu servisi biz kod ile nasıl
kullanılırız? Neden kod ile kullanalım ki? diye soruyor olabilirsiniz.
Azure management portalında bir schedule'in servisi yok. Yani veritabanı
yedeklerimi şu aralıkla al, şuraya şöyle koy vs gibi bir ayarlama yapma
şansınız yok. O nedenle kendi scheduler'ımızı ve kendi backup
sistemimizi kendimiz yazacağız :) Bunun için basit bir WorkerRole
kullanabiliriz. WorkerRole belirli aralıkla uyanarak bizim backup
işlemimizle ilgili talebi sisteme gönderecek.

Hala herşey kulağa çok basit geliyor :) Biraz daha zorlaştırmamız lazım.
:) Şaka bir yana, olay gerçekten de bu kadarla bitmiyor. Worker'ı
yazdınız ve bir şekilde azure management portalındaki talebi kod
management API'lerine göndermeyi de başardınız diyelim.... Bu işlemi
"transactionally consistent" olmadığını söylesem? Peki şimdi bu da ne
demek? Basit bir şekilde bir transaction tam ortadayken backup alıyor
olabilirsiniz demek? Farklı tablolarıdaki transactional FK
relation'larınız saçma sapan şekillerde backup'da kendini gösterebilir
demek. Emin olun, bunu kimse istemez :)

Canımızı sıkmayalım :)

Tam herşey kısmen iyi gidiyordu ki bir de başımıza "transactional
conssitency" çıktı. Peki ne yapacağız o zaman? Çözüm basit. SQL Azure
ortamında "copy database" kullanacağız. Var olan bir veritabanının
kopyasını alabiliyorsunuz. Kopyalama işlemi "transactional conssitency"
sağlıyor. Kopyamızı aldıktan sonra kopyanın yedeğini alıyoruz. Sonra da
kopya veritabanını silip, atıyoruz. İşte yedekleme stratejimiz bu
olacak. Şimdi gelin bunları sırası ile nasıl yaparız :) tek tek
inceleyelim.

Kod yazma zamanı!

İlk yapmamız gereken bir WorkerRole içeren Azure projesi yaratmak. Bu
Worker içerisinde SQL Azure veritabanımızın bulunduğu sunucuya bağlanıp
Master veritabanını hedefleyerek çalıştırabileceğimiz bir T-SQL ile
istediğimiz bir veritabanının kopyalanmasını sağlayabiliyoruz.

[C#]

SqlCommand cmd = new SqlCommand(
                    string
.Format("CREATE DATABASE Backup{0} AS COPY OF {0};", sqldbname), 
                                    cnn);
cnn.Open();
cmd.ExecuteNonQuery();
cnn.Close();

Kodun tamamını paylaşmama sanırım gerek yok :) sqldbname adındaki
değişkenimizde kopyalamak istediğimiz veritabanının adının bulunduğu
düşünün. Veritabanını alıp aynı isimde fakat önünde "Backup" yazan yeni
bir veritabanı yaratıyoruz. Kopyalama işlemini başlattıktan sonra
işlemin ne zaman tamamlandığını takip etmemiz gerek. Malum büyük
veritabanları için bu işlem saatler bulabiliyor. Bizim worker zaten
şimdilik While(true)'da. O kısmı değiştirmeyeceğiz. O nedenle uygun bir
şekilde bu kopyalama işleminin durumunu kontrol edip, işlem bitene kadar
içerisinde olduğumuz worker'ı belirli aralıklarla uyutmamız gerek.

[C#]

int StateEnum = 7;
while (StateEnum != 0)
{
    cmd = new SqlCommand("SELECT state FROM sys.databases WHERE name = @BackupDBName", cnn);
    cmd.Parameters.AddWithValue("@BackupDBName""Backup" + sqldbname);
    cnn.Open();
    StateEnum = int.Parse(cmd.ExecuteScalar().ToString());
    cnn.Close();

    if (StateEnum == 4)
    {
        throw new Exception("Something is badly wrong. The DB is in SUSPECT state");
    }
    Thread.Sleep(TimeSpan.FromMinutes(1));
}

Hmm şimdi düşündüm de yukarıda ExecuteScalar'daki olası exception'ları
handle etsek iyi olur :) Her neyse :) burada yaptığımız şey sistemdeki
tüm veritabanlarının durumunu kontrol etmek. Bizim kopya veritabanının
durum bilgisi "0" geldiğinde kopyalama bitmiş demektir. Eğer durum
bilgisi "4" gelirse ciddi kritik birşeyler var anlamına geliyor. O zaman
bir yerlere bir notification atmak, durumu manual kontrol etmek anlamlı
olacaktır. Kodumuz içerisinde kopyalanan veritabanının durumu "0" olana
kadar bir dakika aralıklarla durumu kontrol ediyoruz. İşlem
tamamlandığınızda artık kopya veritabanımız hazır demektir. Sıra geliyor
BACPAC için Azure'da talep göndermeye.

Azure Import Export Service Client v 1.6

Azure'daki backup servisini kullanmak için yardımımıza yetişebilecek bir
Client var. "DAC Import/Export" aracını hemen CodePlex'ten
indirebilirsiniz
. Paketin
içerisinde "DacIESvcCli.exe" adındaki client bizim Azure'a backup
talebimizi göndermemizi ve sonrasında da backup işlemini takip etmemizi
sağlayacak olan arkadaşın ta kendisi. EXE'nin yanındaki
"DacIESvcCli.exe.config"'yi de unutmayın derim :) Orada da datacenter
mapping'leri bulunuyor management servisleri ile ilgili. Bu iki dosyayı
bizim Worker'ın kullanabiliyor olması gerek. Ama nasıl? Bizim worker'ın
yanında böyle bir EXE'yi nasıl koyarız? Koymayacağız zaten :) Hemen
Storage Account'unuzu "tools" adında bir container yaratıp bu iki
dosyayı oraya atın. Evet, kullanacağımız araçları cloud'daki storage'a
atıyoruz. Worker ilk açıldığında o storage'dan kullanacağı tooları alıp
kendi çalıştığı makineden temporary bir klasöre kopyalayabilir değil mi?
Süper :)

[C#]

string TempFolder = System.IO.Path.GetTempPath();
Trace.WriteLine(TempFolder);

//Temp
folder'ı bir temizlesek fena olmaz.

System.IO.DirectoryInfo allFiles = new DirectoryInfo(TempFolder);
foreach (FileInfo file in allFiles.GetFiles())
{
    file.Delete();
}

//Kullanacağımız araçları makineye
indirelim.

CloudBlobClient BlobClient = CloudHelpers.Storage.Blob.GetBlobClient();
CloudBlobContainer ToolsContainer = BlobClient.GetContainerReference("tools");
var AllBlobs = ToolsContainer.ListBlobs();
foreach (CloudBlob item in AllBlobs)
{
    item.DownloadToFile(string.Format(@"{0}\{1}", TempFolder, item.Name));
}

Yukarıdaki kod aslında hepimiz bildiği basit Storage işlemleri.
WorkerRole'ün çalıştığı yerde temp folder'ı bir temizliyoruz. Hani olur
ya WorkerRole restart yemiştir, orada kirli birşeyler kalmıştır :)
Temizlemekte fayda var. Sonra da storage'dan araçları temp folder'ımıza
indiriyoruz. Bunun workerın "OnStart"ında yapabilirsiniz, sonuç olarak
sadece bir defa yapılacak.

Artık kullanacağımız araçları makineye indi. Veritabanının kopyasını
alacak kodu da yazmıştık. Yani kopya da alındı ve hazır. Sıra geldi
bizim DAC Client'a doğru komutları gönderip backup talebini azure'a
göndermek.

[C#]

string BackupCommand = string.Format(@"-s {0}.database.windows.net 
-d Backup{1} -u {2} -p {3} -bloburl 
http://{4}.blob.core.windows.net/{5}/{6}.bacpac -blobaccesskey 
{7} -accesskeytype storage -x ",
    sqlservername, sqldbname, sqlusername, 
    sqlpassword, storageaccountname, 
    storagecontainername, storageblobname, storageaccesskey);

ProcessStartInfo ExtProcess = new ProcessStartInfo();
ExtProcess.FileName = string.Format(@"{0}\{1}", TempFolder, "DacIESvcCli.exe");
ExtProcess.Arguments = BackupCommand;
ExtProcess.CreateNoWindow = true;
ExtProcess.ErrorDialog = false;
ExtProcess.UseShellExecute = false;
ExtProcess.WindowStyle = ProcessWindowStyle.Hidden;
ExtProcess.RedirectStandardOutput = true;
ExtProcess.RedirectStandardInput = false;
ExtProcess.RedirectStandardError = true;

Process exeProcess = Process.Start(ExtProcess);

Olayımız budur :) Olayın özü yukarıdaki BackupCommand. SQL sunucusunun
adresi, veritabanı adı, erişim bilgileri, storage account'ın erişim
bilgileri ve BACPAC'ın kaydedileceği yer gibi bir seri parametreyi DAC
Client'ı veriyoruz. Böylece talebimizi göndermiş olduk. Bundan sonra
sıra geliyor talebin, yani işlemin durumunu takip etmeye. İşte bu
noktada ciddi saçmalıklar var :) Aslında DAC Client bir requestID alarak
belirli bir işlemin durumunu report edebiliyor fakat ben o requestID'yi
yukarıdaki request sonucunda nasıl alabileceğimizi bulamadım :) Yok öyle
birşey :D API Request'i biz yapsak alırız da DAC Client'da sanki o kısım
encapsulate olmuş gibi duruyor. Yine de son işlemlerin statuslerini
alabileceğimiz bir komut mevcut. Request ID vermeden status talebinde
bulunursak tüm son işlemlerin durumlarını alabiliyoruz ama bu sefer de
işin pis tarafı :) EXE'nin raporu output string olarak vermesi :) Sonuç
itibari ile amacına uygun ama raporu XML olarak file system'e falan
koysa süper olurmuş :)

DACClient'ın raporu bu şekilde :)
DACClient'ın raporu bu şekilde :)

Yukarıdaki screenshot'da da gördüğün gibi bize gelen bu raporu alıp
içerisinden bizim bir önceki talebe denk gelen "Status" kısmına bakmamız
lazım. "Status" eğer "Completed" ise işlem tamamlandı demektir. İşlem
tamamlandığı gibi de backup bittiğinde göre sadece backup amacı ile
kopyaladığımız veritabanını kopyasını silebiliriz ki sürekli para
ödemeyelim onun için.

[C#]

string CheckStatus = string.Format(@"-s {0}.database.windows.net -u {1} -p {2} -status ",
   sqlservername, sqlusername, sqlpassword);

ExtProcess = new ProcessStartInfo();
ExtProcess.FileName = string.Format(@"{0}\{1}", TempFolder, "DacIESvcCli.exe");
ExtProcess.Arguments = CheckStatus;
ExtProcess.CreateNoWindow = true;
ExtProcess.ErrorDialog = false;
ExtProcess.UseShellExecute = false;
ExtProcess.WindowStyle = ProcessWindowStyle.Hidden;
ExtProcess.RedirectStandardOutput = true;
ExtProcess.RedirectStandardInput = false;
ExtProcess.RedirectStandardError = true;

string StatusText = "";
while (StatusText.Contains("Completed") == false)
{
    string Output = Process.Start(ExtProcess).StandardOutput.ReadToEnd();
    string BlobFullUri = string.Format("http://{0}.blob.core.windows.net/{1}/{2}.bacpac"
        storageaccountname, storagecontainername, storageblobname);
    StatusText = Output.Substring(Output.IndexOf(BlobFullUri) + BlobFullUri.Length, 20);
    Thread.Sleep(TimeSpan.FromMinutes(1));
}

CheckStatus commandini en üstte görüyorsunuz. Yine DAC Client'ı
kullanarak status report istiyoruz. EXE'yi çalıştırırken output'unu da
alıp string olarak parse etmemiz gerekiyor :) Biliyorum, durum pek iç
açıcı değil ama direk management API'lerini çağırmaktan daha pratik ve
çalışıyor :) Parsing tarafındaki mantığımız süper basit. Yedekleme
hedefi olarak verdiğimiz BlobUri'yi arayıp onu takip eden Status'ü
alıyoruz. Burada tabi ki önemli olan BlobUri'nizin unique olması ki
zaten öyle olmak zorunda. Aynı BlobUri hedefi ile birden çok talep
göndermemiş olmanız gerekiyor. Kodumuz Status'ü dakikada bir kontrol
ediyor ve tamamlandığında da bir anlamda artık :) kodu akışına bırakıyor
:).

Tüm bu işlemleri yaptıktan sonra artık kopya veritabanını DROP
edebilirsiniz. Ama... drop etmeyebilirsiniz de! Niye mi? Yazının başında
restore operasyonunun downtime'a neden olabileceğinden bahsetmiştik.
Tabi diğer yandan "dakikada bir restore" yapmayacağınızı da biliyoruz.
Genel olarak backupları günlük tutsanız bile bir hafta öncesi bir
backup'a restore etme ihtimaliniz düşük. Genelde bir önceki backupa
restore edilir değil mi? Güzel. Peki diğer yandan aldığımız kopya
veritabanı için de günlük para ödediğimizi biliyor muyuz? Yani o
veritabanını 2 saatliğine sunucuda tutmuş olsanız da günlük parasını
vereceksiniz. Bunun üzerine eğer günlük yedek alıyorsanız :) aslında
veritabanını kopyaladıktan sonra hemen silmenin sizin için hiçbir maddi
faydası olmadığını düşünebilirsiniz. Gerçekten de öyle. Buna ek olarak
bir de o kopya veritabanını ayakta tutmak demek aslında restore
gerekmesi durumunda direk veritabanı switch edebileceğiniz anlamına
geliyor! Yazılımınızda bunu yapabileceğiniz bir mimari var mıdır, yok
mudur bilemem ama full bir restore yapmaktan çok daha pratik ve
downtime'ı düşük bir seçenek olduğu kesin.

Özetle, tüm bu senaryoyu implemente ettiğinizde geçmişe dönük günlük
yedekleriniz varken bir tane de bir gün öncenin yedeği sürekli bir
sunucuda ayakta backup bekliyor olacak :) Yine de umuyoruz ki bunların
hiçbirine ihtiyacımız olmaz.

Hepinize kolay gelsin!