Încep cu un scurt rezumat al articolului precedent:
Se dădea o arhitectură "clasică" de web: un portal dezvoltat în ASP.net MVC (3 şi 4) având în spate o bază de date ce rula pe MS SQL server ascunsă de Entity Framework.
Aceasta arhitectură trebuia pregatită de "scalare" - trecută pe un sistem ce permitea deservirea unui număr mare de request-uri.
După ce am analizat mai multe opţiuni de upgrade a arhitecturii (discursul logic poate fi revăzut în articolul precendet) ne-am decis asupra SQL Azure şi Windows Azure ca platformă de migrare.
În articolul curent vom descrie pas cu pas cum exact am făcut migrarea, ce tooling am folosit şi ce probleme au apărut sau pot apărea.
Baza de date
Baza de date era ascusă în spatele Entity Framework - aceasta ne uşurează considerabil munca, unul dintre scopurile unui ORM fiind exact transparenţa în alegerea bazei de date.
În primul rând trebuie să vedem dacă SQL Azure şi SQL Server sunt compatibile - ce se poate migra, ce trebuie schimbat şi ce nu se poate migra.
Un loc bun de documentare este Windows Azure General Guidelines and Limitations . Dacă lucraţi cu o bază de date enterprise trebuie să parcurgeţi tot articolul, dacă nu atunci ajunge să ştiţi că următoarele nu sunt suportate de SQL Azure:
Proceduri stocate ce folosesc mai multe baze de date (cross db stored procedures) - dacă aveţi un astfel de scenariu atunci trebuie să mutaţi join-urile la un nivel superior (e.g. LINQ);
Tranzacţii pe operaţii ce folosesc mai multe baze de date (automatic transactions on operations across multiple databases) - la fel ca mai sus, va trebui să mutaţi sincronizarea & procedura de rollback la un nivel superior de abstracţiune;
SQL Server agent sau SQL server jobs - SQL agent lipseşte cu desavârşire din SQL Azure aşa că va trebui să mutaţi toată logica într-un serviciu exterior ce va fi executat periodic (de exemplu să creaţi un thread pe un Azure WebRole). Mai multe soluţii alternative sunt dezbătute aici
Tabele fără index tip cluster (tables without clustered indexes) - partea bună e ca pe fiecare tabel se poate adăuga un index de tip cluster fără probleme. Dacă vă întrebaţi de ce există această limitere citiţi acest articol .
Pentru a afla rapid dacă baza noastră de date este compatibilă cu SQL Azure putem folosi unul din tool-urile de migrare şi încercând migrarea propriu-zisă - în caz de incompatibilitate, toate tool-urile ne vor da un raport detaliat.
Tooling migrare
Se poate folosi pentru a migra baza de date în SQL Azure?
SQL Management Studio 2012 (SSMS) - neapărat versiunea 2012 (sau mai nouă) pentru că în această versiune a fost introdus un task special pentru migrarea în Azure. Dacă nu aveţi licenţa de SSMS atunci puteţi folosi varianta Express.
RedGate SQL Toolkit - ca grad de complexitate şi utilitate e comparabil cu SSMS. Şi pentru SQL Tookit veţi avea nevoie de licenţă - în funcţie de preferinţe şi necesităţi echipa voastră va avea (probabil) ori SQL Toolkit ori SSMS.
SQL Azure Migration Wizard - disponibil pe codeplex, e alternativa free (dar nu mai puţin bună) la migrare.
Noi am folosit SQL Management Studio 2012 (ca membru în Bizspark avem acces gratuit la SSMS)
Cum decurge procedura de migrare:
Selectăm din Management Studio baza de date ce dorim să o migrăm şi selectam din Tasks -> Deploy database to Azure.
Selectăm numele bazei de date pe care dorim să o creem + serverul de Azure unde dorim să rulăm baza de date (serverul va trebui creat în prealabil în windows azure management dashboard ). Notă: dacă deja am mai creat baze de date în Azure, wizard-ul are prostul obicei de a seta în Connection Properties la "Connect to database" baza de date ce a fost creată anterior. Cum noi dorim să creăm o nouă bază de date trebuie să ne asigurăm că acolo e trecut "default" - în caz contrar o eroare va fi semnalată în raportul de migrare
Dăm drumul la procedura de migrare şi citim Logul migrării - aici vor fi semnalate eventualele incompatibilităţi. În cazul nostru am scăpat uşor: singura problemă era că nu toate tabelele aveau indecşi tip cluster-a trebui să îi adăugăm manual pe fiecare tabelă. Operaţiunea aceasta se poate face uşor tot din SSMS.
După ce am rezolvat toate incompatibilităţile se repetă pasul 1
Verificare şi validare
După ce am migrat baza de date, ca să verificăm corectitudinea migrării schimbăm connection string-ul în proiectul ce foloseşte baza de date veche. O dată redirecţionat către SQL Azure totul ar trebui să funcţioneze fără ca nici o altă schimbare să fie necesară.
Note finale
Cam atât despre migrarea bazei de date. Dacă întâmpinaţi probleme la migrare, sau aveţi întrebări mă puteţi contacta direct la dragos(at)txtfeedback.net
În urmatorul articol voi detalia cum am transferat arhitectura si structura de websiteri/directoare virtuale in Azure.