Jeśli masz następujący scenariusz
- wszystkie twoje dane są innodb
- masz włączone rejestrowanie binarne na RDS
możesz utworzyć użytkownika w RDS w ten sposób
GRANT REPLICATION SLAVE,REPLICATION CLIENT ON *.* TO 'leopd'@'%' IDENTIFIED BY 'repl_password';
Jeśli Amazon nie zezwala na „%” dla nazwy hosta, potrzebny będzie konkretny publiczny adres IP
GRANT REPLICATION SLAVE,REPLICATION CLIENT ON *.* TO 'leopd'@'xxx.xx.xx.xxx';
Następnie mysqldump dane z RDS jako pojedynczą transakcję
mysqldump -u... -p... --single-transaction --master-data=1 --all-databases --routines --triggers > /root/MySQLData.sql
Uruchom komendę CHANGE MASTER TO, używając jako adresu użytkownika leopd@'xxx.xx.xx.xxxx (xxx.xx.xx.xxxx to adres IP RDS)
CHANGE MASTER TO
master_host = 'xxx.xx.xx.xxxx',
master_port = 3306,
master_user = 'leopd',
master_passwowrd = 'repl_pass'
master_log_file='slsnbj',
master_log_pos=1;
Załaduj dane na nowy serwer. Nie przejmuj się plikiem master_log_file = 'slsnbj' i master_log_pos = 1. Wiersz 22 zrzutu będzie miał poprawny plik dziennika i położenie.
Uruchom START SLAVE; na nowym serwerze
Powinno zacząć działać. Być może będziesz musiał się martwić o względy zapory.
Spróbuj !!!
AKTUALIZACJA 23.03.2012 17:11 EDT
Masz tylko jedną szansę. Sprawdź, czy możesz ustawić ten ostatni przywilej za pomocą:
UPDATE mysql.user SET Repl_slave_priv = 'Y' WHERE user='root' AND host='%';
FLUSH PRIVILEGES;
Być może jest to blokowane dla użytkowników, którzy mają% w kolumnie hosta mysql.user.
Może być konieczne utworzenie innego użytkownika z twardym publicznym adresem IP, jak zasugerowałem wcześniej
GRANT REPLICATION SLAVE,REPLICATION CLIENT ON *.* TO 'leopd'@'xxx.xx.xx.xxx';
Możliwe, że urządzenia slave do replikacji w RDS również muszą być RDS.