Verbeterde prepostscripts voor databaseconsistente momentopname
De Azure Backup-service biedt al een prepostscriptframework voor het bereiken van toepassingsconsistentie in Linux-VM's met behulp van Azure Backup. Dit proces omvat het aanroepen van een prescript (om de toepassingen stil te zetten) voordat u een momentopname van schijven maakt en postscript aanroept (opdrachten om de toepassingen te blokkeren) nadat de momentopname is voltooid om de toepassingen terug te zetten naar de normale modus.
Ontwerpen, foutopsporing en onderhoud van e pre/post-scripts kan lastig zijn. Om deze complexiteit te verwijderen, biedt Azure Backup een vereenvoudigde pre-/postscript-ervaring voor databases om toepassingsconsistente momentopnamen te krijgen met minimale overhead.
Het nieuwe verbeterde pre-postscriptframework heeft de volgende belangrijke voordelen:
- Deze pre-postscripts worden rechtstreeks geïnstalleerd in Azure-VM's, samen met de back-upextensie, waarmee u creatie kunt elimineren en downloaden vanaf een externe locatie.
- U kunt de definitie en inhoud van pre-postscripts in GitHub bekijken, zelfs suggesties en wijzigingen indienen. U kunt zelfs suggesties en wijzigingen indienen via GitHub, die worden gesorteerd en toegevoegd aan de bredere community.
- U kunt zelfs nieuwe pre-postscripts toevoegen voor andere databases via GitHub, die worden gesorteerd en geadresseerd om de bredere community te helpen.
- Het robuuste framework is efficiënt voor het afhandelen van scenario's, zoals mislukte uitvoering van scripts of crashes. In ieder geval wordt het postscript automatisch uitgevoerd om alle wijzigingen die in het prescript zijn uitgevoerd, terug te draaien.
- Het framework biedt ook een berichtenkanaal voor externe hulpprogramma's voor het ophalen van updates en het voorbereiden van hun eigen actieplan voor elk bericht/gebeurtenis.
Oplossingsstroom
Ondersteuningsmatrix
De volgende lijst met databases wordt behandeld onder het verbeterde framework:
- Oracle (algemeen beschikbaar) - Koppeling naar ondersteuningsmatrix
- MySQL (preview)
Vereisten
U hoeft alleen een configuratiebestand, workload.conf in /etc/azure, te wijzigen om verbindingsgegevens op te geven. Hierdoor kan Azure Backup verbinding maken met de relevante toepassing en pre- en postscripts uitvoeren. Het configuratiebestand heeft de volgende parameters.
[workload]
# valid values are mysql, oracle
workload_name =
command_path =
linux_user =
credString =
ipc_folder =
timeout =
In de volgende tabel worden de parameters beschreven:
| Parameter | Verplicht | Uitleg |
|---|---|---|
| workload_name | Ja | Dit bevat de naam van de database waarvoor u toepassingsconsistente back-up nodig hebt. De huidige ondersteunde waarden zijn oracle of mysql. |
| command_path/configuration_path | Dit bevat het pad naar het binaire werkbelastingbestand. Dit is geen verplicht veld als het binaire bestand van de werkbelasting is ingesteld als padvariabele. | |
| linux_user | Ja | Dit bevat de gebruikersnaam van de Linux-gebruiker met toegang tot de aanmelding van de databasegebruiker. Als deze waarde niet is ingesteld, wordt root beschouwd als de standaardgebruiker. |
| credString | Dit staat voor referentiereeks om verbinding te maken met de database. Dit bevat de volledige aanmeldingsreeks. | |
| ipc_folder | De workload kan alleen naar bepaalde bestandssysteempaden schrijven. U moet hier dit mappad opgeven, zodat het prescript de statussen naar dit mappad kan schrijven. | |
| timeout | Ja | Dit is de maximale tijdslimiet waarvoor de database stilstaat. De standaardwaarde is 90 seconden. Het is niet raadzaam om een waarde in te stellen die kleiner is dan 60 seconden. |
Notitie
De JSON-definitie is een sjabloon die de Azure Backup-service kan aanpassen aan een bepaalde database. Raadpleeg de handleiding van elke database voor meer informatie over het configuratiebestand voor elke database.
De algehele ervaring voor het gebruik van het verbeterde pre-postscriptframework is als volgt:
- De databaseomgeving voorbereiden
- Het configuratiebestand bewerken
- De vm-back-up activeren
- Herstel vm's of schijven/bestanden vanaf het toepassingsconsistente herstelpunt, indien nodig.
Een back-upstrategie voor databases maken
Momentopnamen gebruiken in plaats van streaming
Normaal gesproken worden streamingback-ups (zoals volledige, differentiële of incrementele) en logboeken gebruikt door databasebeheerders in hun back-upstrategie. Hieronder volgen enkele belangrijke draaipunten in het ontwerp.
- Prestaties en kosten: Een dagelijkse volledige en logboeken zijn de snelste tijdens het herstellen, maar brengt aanzienlijke kosten met zich mee. Als u het type differentiële/incrementele streamingback-up opneemt, vermindert u de kosten, maar kan dit van invloed zijn op de herstelprestaties. Maar momentopnamen bieden de beste combinatie van prestaties en kosten. Omdat momentopnamen inherent incrementeel zijn, hebben ze de minste invloed op de prestaties tijdens het maken van back-ups, worden ze snel hersteld en bespaart u ook kosten.
- Impact op database/infrastructuur: de prestaties van een streamingback-up zijn afhankelijk van de onderliggende opslag-IOPS en de netwerkbandbreedte die beschikbaar is wanneer de stream is gericht op een externe locatie. Momentopnamen hebben deze afhankelijkheid niet en de vraag naar IOPS en netwerkbandbreedte is aanzienlijk verminderd.
- Opnieuw bruikbaarheid: de opdrachten voor het activeren van verschillende typen streamingback-ups zijn verschillend voor elke database. Scripts kunnen dus niet eenvoudig opnieuw worden gebruikt. Als u verschillende back-uptypen gebruikt, moet u ook de afhankelijkheidsketen evalueren om de levenscyclus te behouden. Voor momentopnamen is het eenvoudig om script te schrijven omdat er geen afhankelijkheidsketen is.
- Langetermijnretentie: volledige back-ups zijn altijd nuttig voor langetermijnretentie0, omdat ze onafhankelijk kunnen worden verplaatst en hersteld. Maar voor operationele back-ups met kortetermijnretentie zijn momentopnamen gunstig.
Daarom is een dagelijkse momentopname en logboeken met incidentele volledige back-up voor langetermijnretentie het beste back-upbeleid voor databases.
Strategie voor logboekback-up
Het verbeterde pre-postscriptframework is gebouwd op Azure VM-back-up die één keer per dag een back-up plant. Het venster voor gegevensverlies met Recovery Point Objective (RPO) als 24 uur is dus niet geschikt voor productiedatabases. Deze oplossing wordt aangevuld met een strategie voor logboekback-ups waarbij logboekback-ups expliciet worden gestreamd.
NFS op blob en NFS op AFS (preview) helpen bij het eenvoudig koppelen van volumes rechtstreeks op database-VM's en het gebruik van databaseclients om logboekback-ups over te dragen. Het venster voor gegevensverlies dat RPO is, valt onder de frequentie van logboekback-ups. Bovendien hoeven NFS-doelen niet zeer goed te presteren, omdat u mogelijk geen reguliere streaming (volledig en incrementeel) hoeft te activeren voor operationele back-ups nadat u een databaseconsistente momentopnamen hebt.
Notitie
Het verbeterde prescript zorgt er meestal voor dat alle logboektransacties die worden verzonden naar de back-upbestemming van het logboek leegmaken voordat u de database stillegt om een momentopname te maken. De momentopnamen zijn daarom databaseconsistent en betrouwbaar tijdens het herstel.
Herstelstrategie
Zodra de databaseconsistente momentopnamen zijn gemaakt en de logboekback-ups worden gestreamd naar een NFS-volume, kan de herstelstrategie van de database gebruikmaken van de herstelfunctionaliteit van Azure VM-back-ups. De mogelijkheid van logboekback-ups wordt er ook op toegepast met behulp van de databaseclient. Hieronder volgen enkele opties voor herstelstrategie:
- Nieuwe VM's maken op basis van databaseconsistent herstelpunt. Op de VM moet al het koppelpunt voor logboeken zijn verbonden. Gebruik databaseclients om herstelopdrachten uit te voeren voor herstel naar een bepaald tijdstip.
- Maak schijven van databaseconsistent herstelpunt en koppel deze aan een andere doel-VM. Koppel vervolgens het logboekdoel en gebruik databaseclients om herstelopdrachten uit te voeren voor herstel naar een bepaald tijdstip
- Gebruik de optie voor bestandsherstel en genereer een script. Voer het script uit op de doel-VM en koppel het herstelpunt als iSCSI-schijven. Gebruik vervolgens databaseclients om de databasespecifieke validatiefuncties op de gekoppelde schijven uit te voeren en de back-upgegevens te valideren. Gebruik ook databaseclients om enkele tabellen/bestanden te exporteren/herstellen in plaats van de hele database te herstellen.
- Gebruik de functie Herstel tussen regio's om de bovenstaande acties uit te voeren vanuit een secundair gekoppelde regio tijdens regionale noodgevallen.
Samenvatting
Met behulp van databaseconsistente momentopnamen en logboeken waarvan een back-up is gemaakt met behulp van een aangepaste oplossing, kunt u een krachtige en rendabele back-upoplossing voor databases maken met behulp van de voordelen van Azure VM-back-ups en ook de mogelijkheden van databaseclients opnieuw gebruiken.