RDS neumožňuje ani hlavnímu uživateli SUPER oprávnění a je vyžadováno ke spuštění FLUSH TABLES WITH READ LOCK . (Toto je nešťastné omezení RDS).
Chybný příkaz je generován --master-data možnost, která je samozřejmě nezbytná, pokud chcete mít možnost zjistit přesné souřadnice binlogu, kde záloha začíná. FLUSH TABLES WITH READ LOCK získává globální zámek čtení na všech tabulkách, což umožňuje mysqldump START TRANSACTION WITH CONSISTENT SNAPSHOT (stejně jako u --single-transaction ) a poté SHOW MASTER STATUS získat souřadnice binárního protokolu, načež uvolní globální zámek čtení, protože má transakci, která udrží viditelná data ve stavu konzistentním s pozicí protokolu.
RDS narušuje tento mechanismus odmítnutím SUPER privilegium a neposkytuje žádné zjevné řešení.
Existuje několik hackerských možností, jak to správně obejít, z nichž žádná nemusí být zvlášť atraktivní:
-
zálohujte v období nízkého provozu. Pokud se souřadnice binlogu nezměnily v době od spuštění zálohy do doby, kdy záloha začala zapisovat data do výstupního souboru nebo cílového serveru (za předpokladu, že jste použili
--single-transaction), pak to bude fungovat, protože víte, že se souřadnice během procesu nezměnily. -
sledujte pozici binlogu na hlavním serveru těsně před zahájením zálohování a použijte tyto souřadnice s
CHANGE MASTER TO. Pokud jebinlog_formatvašeho mistra je nastaven naROWpak by to mělo fungovat, ačkoli pravděpodobně budete muset přeskočit několik počátečních chyb, ale neměli byste mít následně žádné chyby. Funguje to proto, že replikace založená na řádcích je velmi deterministická a zastaví se, pokud se pokusí vložit něco, co již existuje, nebo odstranit něco, co již bylo pryč. Jakmile chyby překonáte, budete na skutečných souřadnicích binlogu, kde konzistentní snímek ve skutečnosti začal. -
jako v předchozí položce, ale po obnovení zálohy zkuste určit správnou pozici pomocí
mysqlbinlog --base64-output=decode-rows --verbosepro přečtení hlavního binlogu na souřadnicích, které jste získali, kontrolu vašeho nového otroka, abyste viděli, které z událostí již musely být provedeny, než snímek skutečně začal, a pomocí takto určených souřadnicCHANGE MASTER TO. -
použít externí proces k získání zámku pro čtení na každé tabulce na serveru, což zastaví všechny zápisy; všimněte si, že pozice binlogu z
SHOW MASTER STATUSse zastavilo zvyšování, spusťte zálohování a uvolněte tyto zámky.
Pokud použijete některý z těchto přístupů jiný než možná ten poslední, je obzvláště důležité, abyste provedli porovnání tabulek, abyste se ujistili, že váš slave je po spuštění identický s hlavním. Pokud narazíte na následné chyby replikace... pak tomu tak nebylo.
Pravděpodobně nejbezpečnější možnost – ale také možná nejotravnější protože se zdá, že by to nemělo být nutné -- je začít vytvořením repliky pro čtení RDS vašeho hlavního serveru RDS. Jakmile bude spuštěna a synchronizována s hlavním serverem, můžete zastavit replikaci na čtecí replice RDS provedením uložené procedury poskytované RDS, CALL mysql.rds_stop_replication který byl představen v RDS 5.6.13 a 5.5.33 což nevyžaduje SUPER privilegium.
Když je RDS replika slave zastavena, vezměte mysqldump z repliky čtení RDS, která nyní bude mít na sobě neměnnou sadu dat jako konkrétní sadu hlavních souřadnic. Obnovte tuto zálohu do svého podřízeného zařízení mimo pracoviště a poté použijte hlavní souřadnice repliky čtení RDS z SHOW SLAVE STATUS Exec_Master_Log_Pos a Relay_Master_Log_File jako váš CHANGE MASTER TO souřadnice.
Hodnota zobrazená v Exec_Master_Log_Pos na slave je začátek další transakce nebo událost ke zpracování
, a to je přesně místo, kde váš nový otrok potřebuje začít číst na hlavním zařízení.
Poté můžete repliku čtení RDS vyřadit z provozu, jakmile bude vaše externí podřízená jednotka v provozu.