Hoewel het een goed idee is om de database te vergrendelen en het bestandssysteem te bevriezen wanneer u de snapshot start, duurt de eigenlijke API-aanroep om de snapshot te starten een fractie van een seconde, zodat uw database en bestandssysteem niet lang vergrendeld/bevroren zijn.
Dat gezegd hebbende, zijn er nog een paar andere overwegingen die je niet hebt genoemd:
-
Wanneer u probeert de vergrendeling op de database te maken, moet u mogelijk wachten tot andere instructies zijn voltooid voordat de vergrendeling wordt verleend. Gedurende deze tijd kan uw openstaande vergrendeling wachten met verdere verklaringen totdat u de vergrendeling krijgt en weer vrijgeeft. Dit kan onderbrekingen veroorzaken in de stroom van verklaringen in uw productiedatabase.
-
Nadat u het maken van de snapshot hebt gestart, is uw toepassing/database vrij om het bestandssysteem op het volume te gebruiken, maar als u veel schrijfbewerkingen heeft, kunt u een hoge iowait ervaren, soms genoeg om een merkbare vertraging van uw toepassing te veroorzaken. De reden hiervoor is dat het snapshotproces op de achtergrond een blok naar S3 moet kopiëren voordat het schrijven naar dat blok op het actieve volume toestaat.
Ik los het eerste probleem op door een slot aan te vragen en een time-out te krijgen als deze niet snel wordt verleend. Ik wacht dan een beetje en blijf het opnieuw proberen totdat ik het slot krijg. De juiste time-outs en vertraging bij het opnieuw proberen kunnen variëren voor verschillende databaseladingen.
Ik los het tweede probleem op door de frequente, consistente snapshots uit te voeren op de slave in plaats van op de master, precies zoals je voorstelde. Ik raad nog steeds aan om af en toe snapshots tegen de master uit te voeren, gewoon om de intrinsieke duurzaamheid te verbeteren (een diepe EBS-eigenschap), maar die snapshots hoeven niet te worden uitgevoerd met vergrendeling of bevriezing, omdat je ze niet voor back-ups gaat gebruiken.
Ik raad ook het gebruik van een bestandssysteem aan dat flushen en bevriezen (XFS) ondersteunt. Anders maakt u snapshots van vergrendelde tabellen in MySQL die misschien nog niet eens al hun blokken op het EBS-volume hebben, of andere delen van het bestandssysteem zijn mogelijk gewijzigd en inconsistent in de snapshot.
Als je geïnteresseerd bent, heb ik open source-software gepubliceerd die de best practices uitvoert die ik heb verzameld met betrekking tot het maken van consistente EBS-snapshots met MySQL en XFS (beide optioneel).
Om uw laatste vraag te beantwoorden, het vergrendelen van tabellen in de master zal de replicatie niet verbreken. In mijn snapshot-software spoel ik ook de tabellen door met leesvergrendeling om er zeker van te zijn dat alles op de schijf staat die wordt gesnapt en ik voeg het trefwoord "LOCAL" toe zodat de flush niet wordt gerepliceerd naar potentiële slaven.