RDS tillader ikke engang masterbrugeren SUPER privilegium, og dette er påkrævet for at udføre FLUSH TABLES WITH READ LOCK . (Dette er en uheldig begrænsning af RDS).
Den fejlagtige sætning genereres af --master-data mulighed, hvilket naturligvis er nødvendigt, hvis du vil kunne lære de præcise binlog-koordinater, hvor sikkerhedskopieringen begynder. FLUSH TABLES WITH READ LOCK anskaffer en global læselås på alle tabeller, som gør det muligt for mysqldump at START TRANSACTION WITH CONSISTENT SNAPSHOT (som det gør med --single-transaction ) og derefter SHOW MASTER STATUS for at få de binære logkoordinater, hvorefter den frigiver den globale læselås, fordi den har en transaktion, der vil holde de synlige data i en tilstand, der stemmer overens med den pågældende logposition.
RDS bryder denne mekanisme ved at afvise SUPER privilegium og giver ingen åbenlys løsning.
Der er nogle hacky-muligheder tilgængelige for korrekt at omgå dette, og ingen af dem kan være særligt attraktive:
-
lav backup i en periode med lav trafik. Hvis binlog-koordinaterne ikke har ændret sig mellem det tidspunkt, du starter sikkerhedskopieringen, og efter sikkerhedskopieringen er begyndt at skrive data til outputfilen eller destinationsserveren (forudsat at du brugte
--single-transaction), så vil dette virke, fordi du ved, at koordinaterne ikke ændrede sig, mens processen kørte. -
observer binlog-positionen på masteren lige før du starter sikkerhedskopieringen, og brug disse koordinater med
CHANGE MASTER TO. Hvis din mastersbinlog_formater indstillet tilROWså burde dette virke, selvom du sandsynligvis skal springe forbi et par indledende fejl, men du skal ikke efterfølgende have nogen fejl. Dette virker, fordi rækkebaseret replikering er meget deterministisk og vil stoppe, hvis den forsøger at indsætte noget, der allerede er der, eller slette noget, der allerede er væk. Når du har passeret fejlene, vil du være ved de sande binlog-koordinater, hvor det konsistente øjebliksbillede faktisk startede. -
som i det forrige punkt, men efter at have gendannet sikkerhedskopien, prøv at bestemme den korrekte position ved at bruge
mysqlbinlog --base64-output=decode-rows --verboseat læse masterens binlog på de koordinater, du har opnået, kontrollere din nye slave for at se, hvilke af begivenhederne der allerede skal være udført, før snapshottet rent faktisk startede, og bruge koordinaterne bestemt på denne måde til atCHANGE MASTER TO. -
brug en ekstern proces til at opnå en læselås på hver eneste tabel på serveren, som vil stoppe alle skrivninger; Bemærk, at binlog-positionen fra
SHOW MASTER STATUSer stoppet med at stige, start sikkerhedskopieringen, og slip disse låse.
Hvis du bruger nogen af disse metoder bortset fra måske den sidste, er det især vigtigt, at du laver tabelsammenligninger for at være sikker på, at din slave er identisk med masteren, når den kører. Hvis du rammer efterfølgende replikeringsfejl... så var det ikke.
Sandsynligvis den sikreste mulighed -- men måske også den mest irriterende da det ser ud til at det ikke burde være nødvendigt -- er at begynde med at lave en RDS-læse-replika af din RDS-master. Når den først er oppe og synkroniseret til masteren, kan du stoppe replikering på RDS læse replikaen ved at udføre en RDS-leveret lagret procedure, CALL mysql.rds_stop_replication som blev introduceret i RDS 5.6.13 og 5.5.33 som ikke kræver SUPER privilegium.
Med RDS replika-slaven stoppet, tag din mysqldump fra RDS læse replikaen, som nu vil have et uforanderligt datasæt på sig som et specifikt sæt masterkoordinater. Gendan denne sikkerhedskopi til din off-site slave, og brug derefter RDS-læs replikaens masterkoordinater fra SHOW SLAVE STATUS Exec_Master_Log_Pos og Relay_Master_Log_File som din CHANGE MASTER TO koordinater.
Værdien vist i Exec_Master_Log_Pos på en slave er starten på den næste transaktion eller begivenhed, der skal behandles
, og det er præcis her, din nye slave skal begynde at læse på masteren.
Derefter kan du tage RDS-læse-replikaen ud af drift, når din eksterne slave er oppe og køre.