RDS не позволява дори на главния потребител SUPER привилегия и това е необходимо, за да се изпълни FLUSH TABLES WITH READ LOCK . (Това е жалко ограничение на RDS).
Неуспешният израз се генерира от --master-data опция, която, разбира се, е необходима, ако искате да можете да научите точните binlog координати, където започва архивирането. FLUSH TABLES WITH READ LOCK придобива глобално заключване за четене на всички таблици, което позволява на mysqldump да START TRANSACTION WITH CONSISTENT SNAPSHOT (както става с --single-transaction ) и след това SHOW MASTER STATUS за да получи двоичните координати на регистрационния файл, след което освобождава глобалното заключване за четене, тъй като има транзакция, която ще поддържа видимите данни в състояние, съответстващо на тази позиция в регистъра.
RDS нарушава този механизъм, като отказва SUPER привилегия и не предоставя очевидно решение.
Има някои хакерски опции за правилно заобикаляне на това, нито една от които може да е особено привлекателна:
-
направете архивиране по време на период на нисък трафик. Ако координатите на binlog не са се променили между момента, в който стартирате архивирането и след като архивирането започне да записва данни в изходния файл или целевия сървър (ако приемем, че сте използвали
--single-transaction) тогава това ще работи, защото знаете, че координатите не са се променили, докато процесът се изпълняваше. -
наблюдавайте позицията на binlog на главния точно преди стартиране на архивирането и използвайте тези координати с
CHANGE MASTER TO. Ако вашият господар еbinlog_formatе настроен наROWтогава това трябва да работи, въпреки че вероятно ще трябва да пропуснете няколко първоначални грешки, но не би трябвало да имате впоследствие грешки. Това работи, защото базираната на ред репликация е много детерминистична и ще спре, ако се опита да вмъкне нещо, което вече е там, или да изтрие нещо, което вече е изчезнало. След като преминете грешките, вие ще бъдете на истинските координати на binlog, където всъщност е започнала последователната моментна снимка. -
както в предишния елемент, но след възстановяване на архива опитайте да определите правилната позиция, като използвате
mysqlbinlog --base64-output=decode-rows --verboseза да прочетете binlog на главния в получените от вас координати, като проверите новия си подчинен, за да видите кои от събитията трябва да са вече изпълнени, преди моментната снимка действително да започне, и като използвате координатите, определени по този начин, заCHANGE MASTER TO. -
използвайте външен процес, за да получите заключване за четене на всяка таблица на сървъра, което ще спре всички записи; обърнете внимание, че позицията на binlog от
SHOW MASTER STATUSе спрял да нараства, стартирайте архивирането и освободете тези заключвания.
Ако използвате някой от тези подходи, различен от може би последния, особено важно е да правите сравнения на таблици, за да сте сигурни, че вашият подчинен е идентичен с главния, след като се изпълнява. Ако ударите последващи грешки при репликация... значи не е било.
Вероятно най-безопасният вариант, но и може би най-досадният тъй като изглежда, че не би трябвало да е необходимо - е да започнете със създаване на RDS реплика за четене на вашия RDS master. След като е направен и синхронизиран с главния, можете да спрете репликацията на репликата за четене на RDS, като изпълните предоставена от RDS съхранена процедура, CALL mysql.rds_stop_replication който беше въведен в RDS 5.6.13 и 5.5.33 което не изисква SUPER привилегия.
При спряно подчинено устройство на RDS, вземете вашия mysqldump от репликата за четене на RDS, която вече ще има непроменен набор от данни за конкретен набор от главни координати. Възстановете това резервно копие във вашия служебен извън сайта и след това използвайте главните координати на RDS прочетете репликата от SHOW SLAVE STATUS Exec_Master_Log_Pos и Relay_Master_Log_File като ваш CHANGE MASTER TO координати.
Стойността, показана в Exec_Master_Log_Pos на подчинен е началото на следващата транзакция или събитие за обработка
, и точно това е мястото, където вашият нов подчинен трябва да започне да чете на главния.
След това можете да изведете от експлоатация репликата за четене на RDS, след като вашият външен подчинен е стартиран и работи.
