Analysera beslutskriterierna för verktygsval och migreringsmodell
Nu när vi har utforskat alternativen för migreringsmetoder och verktygsalternativ kan vi utforska de beslutskriterier som vi behöver överväga för att köra våra migreringar till Azure Database for PostgreSQL – flexibel server. De tre viktigaste kriterierna som hjälper oss att göra våra val är Stilleståndstid, Källdatabasplats och Anpassningsbarhet.
Driftstopp
Stilleståndstid är en viktig aspekt av migreringsaktiviteter och den varaktighet som är acceptabel för intressenterna hjälper oss att avgöra om vi måste utföra en offline- eller onlinemigreringsaktivitet.
Normalt planeras migreringsaktiviteter i god tid för att säkerställa att lämpliga ändringskontroller och tillhörande styrning slutförs för aktiviteten. Med den här planeringen kan en dialogruta med viktiga intressenter förstå hur länge systemet kan vara offline. I den här situationen rekommenderar vi att du vet hur lång tid det tar för de olika alternativen att fastställa uppskattade minimi- och maximala stilleståndstider.
Det är viktigt att fastställa den minsta stilleståndstid som krävs för att utföra en programnedskärning. I slutändan är den här gången det belopp som du måste ta systemet offline även för en onlinemigreringsaktivitet (eller minimal stilleståndstid). Programmets komplexitet kommer att diktera den här tidsskalan. För ett relativt enkelt program kan den här processen handla om att stoppa en tjänst, uppdatera en konfigurationsfil och sedan aktivera den igen. I mer komplexa miljöer kan den här processen ta mycket längre tid om det finns flera servrar och programlager i spel.
Att förstå varaktigheten som krävs för online- eller offlinemigreringsaktiviteter är nästa viktiga element som rör stilleståndstid. Om det är en offlinemigrering är den tid det tar att extrahera, överföra och läsa in data från källan till målet följt av validering och verifiering din stilleståndstid. Den här stilleståndstiden fördelas sedan mellan den tid det tar att stänga av appen/arbetsbelastningen och den tid det tar att aktivera appen/arbetsbelastningen igen.
Om det är en onlinemigrering (minimal stilleståndstid) är stilleståndstiden den varaktighet som krävs för att synkronisera de slutliga ändringarna från källan till målet när programmet är inaktiverat. Lägg till den stilleståndstiden, verifierings- och verifieringsaktiviteterna innan du konfigurerar om och aktiverar programmet/arbetsbelastningen.
När vi har den här informationen kan vi titta på de tekniska delarna i migreringen för att fastställa vilka våra genomförbara alternativ är.
Källdatabasplats
Källplatsen för de databaser som ska migreras spelar en roll på grund av de begränsningar som sannolikt kommer att finnas för en viss konfiguration.
Lokala eller icke-Azure-källor
För en lokal eller icke-Azure-lokaliserad databas är den viktigaste begränsningen vanligtvis nätverksanslutningen mellan källa och mål. De tre punkterna att tänka på här är bandbredd, svarstid och datavolym. När vi förstår dessa punkter kan vi fatta ett välgrundat beslut om vilken typ av migrering som är livskraftig.
Om vi har en stor mängd data att migrera och en proportionellt liten mängd bandbredd kommer en enkel dump och återställning förmodligen inte att vara genomförbar. Om vi har en stor mängd data och en stor mängd bandbredd är det mindre problem.
På samma sätt är svarstiden en av de viktigaste faktorerna om det är en onlinemigrering där datasynkronisering ska ske. Om svarstiden är hög kan det påverka systemets prestanda negativt eftersom synkroniseringsprocessen tar för lång tid att slutföra.
En viktig faktor att tänka på när du migrerar från andra molnleverantörer är om de debiterar för utgående data. I så fall kan det vara ett övervägande att kunna minimera det fysiska fotavtrycket för de data som överförs. I sådana här situationer kan komprimeringsteknik vara viktig för dumpar eller dataströmmar som används för synkronisering.
Andra Azure-baserade tjänster
Det kommer att finnas situationer där du vill migrera från andra Azure-baserade tjänster till Azure Database for PostgreSQL – flexibel server. Dessa källdatabaser kan finnas i virtuella Azure-datorer, containrar eller eventuellt Azure Database for PostgreSQL – enskild server. I så fall finns det en annan uppsättning överväganden att utforska, men samtidigt flera möjligheter att dra nytta av optimeringar inom Azure-tjänsterna för dessa scenarier.
Anpassningsbarhet
Det sista området att tänka på är hur mycket anpassning som behövs eller önskas. Det här kan bero på att du behöver ändra källdatabasstrukturen för att stödja datareplikering, alternativt kan det innebära hur enkelt det är för dig att automatisera via skript.
Ett bra exempel är att automatisera offlinemigreringen av en databas via pg_dump och pg_restore men samtidigt inklusive komprimering och dekomprimering av dumpfilerna.
Beslutsfattande
Nu när vi har gått igenom processen för att samla in all den här informationen kan vi samarbeta med intressenterna för att fastställa det bästa alternativet för ett visst scenario. När du fattar beslut om vilken metod och teknik som ska användas är det viktigt att inte bara arbeta med affärsintressenterna, utan även de tekniska intressenterna. Det här samarbetet hjälper till att undvika en situation där företaget driver på för en minimal stilleståndstidsmigrering, som det tekniska teamet inte kan leverera på grund av personal-, resurs- eller teknikbegränsningar.
Det viktigaste här är att hantera förväntningar och ha en öppen och ärlig dialogruta. Det är också viktigt att se till att företaget tar ansvar för valideringsuppgifter som ligger utanför ansvarsområdet för de tekniska team som levererar databasmigreringen. Den här valideringen kan omfatta datakonsekvens- och valideringskontroller samt testning av användarupplevelser.