Sauvegarde MySQL Amazon RDS

RDS n'autorise même pas l'utilisateur maître le SUPER privilège, et cela est nécessaire pour exécuter FLUSH TABLES WITH READ LOCK . (C'est une limitation malheureuse de RDS).

L'instruction défaillante est générée par le --master-data option, qui est, bien sûr, nécessaire si vous voulez être en mesure d'apprendre les coordonnées exactes du binlog où la sauvegarde commence. FLUSH TABLES WITH READ LOCK acquiert un verrou de lecture global sur toutes les tables, ce qui permet à mysqldump de START TRANSACTION WITH CONSISTENT SNAPSHOT (comme avec --single-transaction ) puis SHOW MASTER STATUS pour obtenir les coordonnées binaires du journal, après quoi il libère le verrou de lecture global car il a une transaction qui conservera les données visibles dans un état cohérent avec cette position du journal.

RDS casse ce mécanisme en refusant le SUPER privilège et ne fournissant aucune solution de contournement évidente.

Il existe quelques options de piratage disponibles pour contourner correctement ce problème, dont aucune n'est particulièrement attrayante :

• effectuez la sauvegarde pendant une période de faible trafic. Si les coordonnées binlog n'ont pas changé entre le moment où vous démarrez la sauvegarde et après que la sauvegarde a commencé à écrire des données dans le fichier de sortie ou le serveur de destination (en supposant que vous avez utilisé --single-transaction ) alors cela fonctionnera car vous savez que les coordonnées n'ont pas changé pendant l'exécution du processus.

• observez la position binlog sur le maître juste avant de commencer la sauvegarde, et utilisez ces coordonnées avec CHANGE MASTER TO . Si le binlog_format de votre master est défini sur ROW alors cela devrait fonctionner, même si vous devrez probablement ignorer quelques erreurs initiales, mais ne devriez pas avoir d'erreurs par la suite. Cela fonctionne car la réplication basée sur les lignes est très déterministe et s'arrêtera si elle essaie d'insérer quelque chose qui est déjà là ou de supprimer quelque chose qui a déjà disparu. Une fois les erreurs passées, vous serez aux vraies coordonnées binlog où l'instantané cohérent a réellement commencé.

• comme dans l'élément précédent, mais, après la restauration de la sauvegarde, essayez de déterminer la position correcte en utilisant mysqlbinlog --base64-output=decode-rows --verbose pour lire le binlog du maître aux coordonnées que vous avez obtenues, en vérifiant votre nouvel esclave pour voir lequel des événements doit déjà avoir été exécuté avant le démarrage effectif de l'instantané, et en utilisant les coordonnées ainsi déterminées pour CHANGE MASTER TO .

• utiliser un processus externe pour obtenir un verrou en lecture sur chaque table du serveur, ce qui arrêtera toutes les écritures ; observez que la position binlog de SHOW MASTER STATUS a cessé d'incrémenter, démarrez la sauvegarde et libérez ces verrous.

Si vous utilisez l'une de ces approches autre que peut-être la dernière, il est particulièrement important que vous fassiez des comparaisons de table pour être certain que votre esclave est identique au maître une fois qu'il est en cours d'exécution. Si vous rencontriez des erreurs de réplication ultérieures... alors ce n'était pas le cas.

Probablement l'option la plus sûre -- mais peut-être aussi la plus ennuyeuse puisqu'il semble que cela ne devrait pas être nécessaire - est de commencer par créer une réplique en lecture RDS de votre maître RDS. Une fois qu'il est opérationnel et synchronisé avec le maître, vous pouvez arrêter la réplication sur le réplica en lecture RDS en exécutant une procédure stockée fournie par RDS, CALL mysql.rds_stop_replication qui a été introduit dans RDS 5.6.13 et 5.5.33 qui ne nécessite pas le SUPER privilège.

Avec l'esclave de réplique RDS arrêté, prenez votre mysqldump à partir du réplica en lecture RDS, qui contiendra désormais un ensemble de données inchangé à partir d'un ensemble spécifique de coordonnées principales. Restaurez cette sauvegarde sur votre esclave hors site, puis utilisez les coordonnées principales du réplica en lecture RDS à partir de SHOW SLAVE STATUS Exec_Master_Log_Pos et Relay_Master_Log_File comme votre CHANGE MASTER TO coordonnées.

La valeur affichée dans Exec_Master_Log_Pos sur un esclave est le début de la prochaine transaction ou événement à traiter , et c'est exactement là que votre nouvel esclave doit commencer à lire sur le maître.

Ensuite, vous pouvez mettre hors service le réplica en lecture RDS une fois que votre esclave externe est opérationnel.