Si vous avez le scénario suivant
- toutes vos données sont innodb
- la journalisation binaire est activée sur RDS
vous pouvez créer un utilisateur dans RDS comme celui-ci
GRANT REPLICATION SLAVE,REPLICATION CLIENT ON *.* TO 'leopd'@'%' IDENTIFIED BY 'repl_password';
Si Amazon n'autorise pas «%» pour le nom d'hôte, vous aurez besoin d'une adresse IP publique spécifique
GRANT REPLICATION SLAVE,REPLICATION CLIENT ON *.* TO 'leopd'@'xxx.xx.xx.xxx';
Ensuite, mysqldump les données de RDS en une seule transaction
mysqldump -u... -p... --single-transaction --master-data=1 --all-databases --routines --triggers > /root/MySQLData.sql
Exécutez la commande CHANGE MASTER TO en utilisant leopd@'xxx.xx.xx.xxxx 'en tant qu'utilisateur (xxx.xx.xx.xxxx est l'adresse IP de 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;
Chargez les données sur un nouveau serveur. Ne vous inquiétez pas pour master_log_file = 'slsnbj' et master_log_pos = 1. La ligne 22 du vidage aura le fichier journal et la position corrects.
Exécutez START SLAVE; sur le nouveau serveur
Il devrait commencer à fonctionner. Vous devrez peut-être vous soucier des considérations relatives au pare-feu.
Essaie !!!
MISE À JOUR 2012-03-23 17:11 EDT
Il ne vous reste qu'une seule chance. Voyez si vous pouvez définir ce dernier privilège avec ceci:
UPDATE mysql.user SET Repl_slave_priv = 'Y' WHERE user='root' AND host='%';
FLUSH PRIVILEGES;
Peut-être que cela est bloqué pour les utilisateurs qui ont% dans la colonne hôte de mysql.user.
Vous devrez peut-être créer un autre utilisateur avec une adresse IP publique dure comme je l'ai suggéré plus tôt
GRANT REPLICATION SLAVE,REPLICATION CLIENT ON *.* TO 'leopd'@'xxx.xx.xx.xxx';
Il est possible que les esclaves de réplication dans RDS doivent également être RDS.