Configuration, démarrage et arrêt de la réplication des journaux binaires (binlog)

Vous pouvez appeler les procédures stockées suivantes lorsque vous êtes connecté à l’instance principale dans un cluster Aurora MySQL. Ces procédures contrôlent la façon dont les transactions sont répliquées à partir d’une base de données externe dans Aurora MySQL, ou à partir de Aurora MySQL vers une base de données externe.

mysql.rds_disable_session_binlog (Aurora MySQL version 2)

Désactive la journalisation binaire pour la session en cours en définissant la variable sql_log_bin sur OFF.

Syntaxe

CALL mysql.rds_disable_session_binlog;

Paramètres

Aucune

Notes d’utilisation

Pour un cluster de bases de données Aurora MySQL, vous appelez cette procédure stockée lorsque vous êtes connecté à l’instance principale.

Pour Aurora, cette procédure est prise en charge pour Aurora MySQL version 2.12 et les versions ultérieures, compatibles avec MySQL 5.7.

SET SESSION sql_log_bin = OFF;

mysql.rds_enable_session_binlog (Aurora MySQL version 2)

Active la journalisation binaire pour la session en cours en définissant la variable sql_log_bin sur ON.

Syntaxe

CALL mysql.rds_enable_session_binlog;

Paramètres

Aucune

Notes d’utilisation

Pour un cluster de bases de données Aurora MySQL, vous appelez cette procédure stockée lorsque vous êtes connecté à l’instance principale.

Pour Aurora, cette procédure est prise en charge pour Aurora MySQL version 2.12 et les versions ultérieures, compatibles avec MySQL 5.7.

SET SESSION sql_log_bin = ON;

mysql.rds_import_binlog_ssl_material

Importe le certificat d’autorité de certification, le certificat client et la clé client dans un cluster de bases de données Aurora MySQL. Les informations sont requises pour la communication SSL et la réplication chiffrée.

Syntaxe

CALL mysql.rds_import_binlog_ssl_material (
  ssl_material
);

Paramètres

Notes d’utilisation

Avant d’exécuter cette procédure, préparez-vous à la réplication chiffrée :

Pour plus d’informations, consultez Création de certificats et clés SSL à l’aide d’openssl dans la documentation MySQL.

Cette procédure permet d’importer des informations SSL entre une base de données MySQL externe et un cluster de bases de données Aurora MySQL. Les informations SSL se trouvent dans des fichiers au format .pem contenant les informations SSL du cluster de bases de données Aurora MySQL. Pendant la réplication chiffrée, le cluster de bases de données Aurora MySQL agit comme client du serveur de base de données MySQL. Les certificats et les clés privées du client Aurora MySQL sont au format .pem dans les fichiers.

Vous pouvez copier les informations de ces fichiers dans le paramètre ssl_material des données utiles JSON correspondantes. Pour prendre en charge la réplication chiffrée, importez les informations SSL dans le cluster de bases de données Aurora MySQL.

Les données utiles JSON doivent être au format suivant.

'{"ssl_ca":"-----BEGIN CERTIFICATE-----
ssl_ca_pem_body_code
-----END CERTIFICATE-----\n","ssl_cert":"-----BEGIN CERTIFICATE-----
ssl_cert_pem_body_code
-----END CERTIFICATE-----\n","ssl_key":"-----BEGIN RSA PRIVATE KEY-----
ssl_key_pem_body_code
-----END RSA PRIVATE KEY-----\n"}'
            

Exemples

L’exemple suivant importe des informations SSL dans Aurora MySQL. Dans les fichiers au format .pem, le code du corps est généralement plus long que le code du corps affiché dans l’exemple.

call mysql.rds_import_binlog_ssl_material(
'{"ssl_ca":"-----BEGIN CERTIFICATE-----
AAAAB3NzaC1yc2EAAAADAQABAAABAQClKsfkNkuSevGj3eYhCe53pcjqP3maAhDFcvBS7O6V
hz2ItxCih+PnDSUaw+WNQn/mZphTk/a/gU8jEzoOWbkM4yxyb/wB96xbiFveSFJuOp/d6RJhJOI0iBXr
lsLnBItntckiJ7FbtxJMXLvvwJryDUilBMTjYtwB+QhYXUMOzce5Pjz5/i8SeJtjnV3iAoG/cQk+0FzZ
qaeJAAHco+CY/5WrUBkrHmFJr6HcXkvJdWPkYQS3xqC0+FmUZofz221CBt5IMucxXPkX4rWi+z7wB3Rb
BQoQzd8v7yeb7OzlPnWOyN0qFU0XA246RA8QFYiCNYwI3f05p6KLxEXAMPLE
-----END CERTIFICATE-----\n","ssl_cert":"-----BEGIN CERTIFICATE-----
AAAAB3NzaC1yc2EAAAADAQABAAABAQClKsfkNkuSevGj3eYhCe53pcjqP3maAhDFcvBS7O6V
hz2ItxCih+PnDSUaw+WNQn/mZphTk/a/gU8jEzoOWbkM4yxyb/wB96xbiFveSFJuOp/d6RJhJOI0iBXr
lsLnBItntckiJ7FbtxJMXLvvwJryDUilBMTjYtwB+QhYXUMOzce5Pjz5/i8SeJtjnV3iAoG/cQk+0FzZ
qaeJAAHco+CY/5WrUBkrHmFJr6HcXkvJdWPkYQS3xqC0+FmUZofz221CBt5IMucxXPkX4rWi+z7wB3Rb
BQoQzd8v7yeb7OzlPnWOyN0qFU0XA246RA8QFYiCNYwI3f05p6KLxEXAMPLE
-----END CERTIFICATE-----\n","ssl_key":"-----BEGIN RSA PRIVATE KEY-----
AAAAB3NzaC1yc2EAAAADAQABAAABAQClKsfkNkuSevGj3eYhCe53pcjqP3maAhDFcvBS7O6V
hz2ItxCih+PnDSUaw+WNQn/mZphTk/a/gU8jEzoOWbkM4yxyb/wB96xbiFveSFJuOp/d6RJhJOI0iBXr
lsLnBItntckiJ7FbtxJMXLvvwJryDUilBMTjYtwB+QhYXUMOzce5Pjz5/i8SeJtjnV3iAoG/cQk+0FzZ
qaeJAAHco+CY/5WrUBkrHmFJr6HcXkvJdWPkYQS3xqC0+FmUZofz221CBt5IMucxXPkX4rWi+z7wB3Rb
BQoQzd8v7yeb7OzlPnWOyN0qFU0XA246RA8QFYiCNYwI3f05p6KLxEXAMPLE
-----END RSA PRIVATE KEY-----\n"}');

mysql.rds_next_master_log (Aurora MySQL version 2)

Modifie la position du journal de l’instance de base de données source au début du journal binaire suivant sur l’instance de base de données source. Utilisez cette procédure uniquement si vous recevez l' I/O erreur de réplication 1236 sur une réplique en lecture.

Syntaxe

CALL mysql.rds_next_master_log(
curr_master_log
);

Paramètres

Notes d’utilisation

L’utilisateur principal doit exécuter la procédure mysql.rds_next_master_log.

Exemples

Supposons que la réplication échoue sur un réplica en lecture Aurora MySQL. L’exécution de SHOW REPLICA STATUS\G sur le réplica en lecture renvoie le résultat suivant :

*************************** 1. row ***************************
             Replica_IO_State:
                  Source_Host: myhost.XXXXXXXXXXXXXXX.rr-rrrr-1.rds.amazonaws.com
                  Source_User: MasterUser
                  Source_Port: 3306
                Connect_Retry: 10
              Source_Log_File: mysql-bin-changelog.012345
          Read_Source_Log_Pos: 1219393
               Relay_Log_File: relaylog.012340
                Relay_Log_Pos: 30223388
        Relay_Source_Log_File: mysql-bin-changelog.012345
           Replica_IO_Running: No
          Replica_SQL_Running: Yes
              Replicate_Do_DB:
          Replicate_Ignore_DB:
           Replicate_Do_Table:
       Replicate_Ignore_Table:
      Replicate_Wild_Do_Table:
  Replicate_Wild_Ignore_Table:
                   Last_Errno: 0
                   Last_Error:
                 Skip_Counter: 0
          Exec_Source_Log_Pos: 30223232
              Relay_Log_Space: 5248928866
              Until_Condition: None
               Until_Log_File:
                Until_Log_Pos: 0
           Source_SSL_Allowed: No
           Source_SSL_CA_File:
           Source_SSL_CA_Path:
              Source_SSL_Cert:
            Source_SSL_Cipher:
               Source_SSL_Key:
        Seconds_Behind_Master: NULL
Source_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 1236
                Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'Client requested master to start replication from impossible position; the first event 'mysql-bin-changelog.013406' at 1219393, the last event read from '/rdsdbdata/log/binlog/mysql-bin-changelog.012345' at 4, the last byte read from '/rdsdbdata/log/binlog/mysql-bin-changelog.012345' at 4.'
               Last_SQL_Errno: 0
               Last_SQL_Error:
  Replicate_Ignore_Server_Ids:
             Source_Server_Id: 67285976

Le champ Last_IO_Errno montre que l’instance reçoit une erreur 1236 d’I/O. Le champ Master_Log_File montre que le nom du fichier est mysql-bin-changelog.012345, ce qui signifie que l’index du fichier journal est 12345. Pour résoudre l’erreur, vous pouvez appeler mysql.rds_next_master_log avec le paramètre suivant :

CALL mysql.rds_next_master_log(12345);

mysql.rds_next_source_log (Aurora MySQL version 3)

Modifie la position du journal de l’instance de base de données source au début du journal binaire suivant sur l’instance de base de données source. Utilisez cette procédure uniquement si vous recevez l' I/O erreur de réplication 1236 sur une réplique en lecture.

Syntaxe

CALL mysql.rds_next_source_log(
curr_source_log
);

Paramètres

Notes d’utilisation

L’utilisateur administratif doit exécuter la procédure mysql.rds_next_source_log.

Exemples

Supposons que la réplication échoue sur un réplica en lecture Aurora MySQL. L’exécution de SHOW REPLICA STATUS\G sur le réplica en lecture renvoie le résultat suivant :

*************************** 1. row ***************************
             Replica_IO_State:
                  Source_Host: myhost.XXXXXXXXXXXXXXX.rr-rrrr-1.rds.amazonaws.com
                  Source_User: MasterUser
                  Source_Port: 3306
                Connect_Retry: 10
              Source_Log_File: mysql-bin-changelog.012345
          Read_Source_Log_Pos: 1219393
               Relay_Log_File: relaylog.012340
                Relay_Log_Pos: 30223388
        Relay_Source_Log_File: mysql-bin-changelog.012345
           Replica_IO_Running: No
          Replica_SQL_Running: Yes
              Replicate_Do_DB:
          Replicate_Ignore_DB:
           Replicate_Do_Table:
       Replicate_Ignore_Table:
      Replicate_Wild_Do_Table:
  Replicate_Wild_Ignore_Table:
                   Last_Errno: 0
                   Last_Error:
                 Skip_Counter: 0
          Exec_Source_Log_Pos: 30223232
              Relay_Log_Space: 5248928866
              Until_Condition: None
               Until_Log_File:
                Until_Log_Pos: 0
           Source_SSL_Allowed: No
           Source_SSL_CA_File:
           Source_SSL_CA_Path:
              Source_SSL_Cert:
            Source_SSL_Cipher:
               Source_SSL_Key:
        Seconds_Behind_Source: NULL
Source_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 1236
                Last_IO_Error: Got fatal error 1236 from source when reading data from binary log: 'Client requested source to start replication from impossible position; the first event 'mysql-bin-changelog.013406' at 1219393, the last event read from '/rdsdbdata/log/binlog/mysql-bin-changelog.012345' at 4, the last byte read from '/rdsdbdata/log/binlog/mysql-bin-changelog.012345' at 4.'
               Last_SQL_Errno: 0
               Last_SQL_Error:
  Replicate_Ignore_Server_Ids:
             Source_Server_Id: 67285976

Le champ Last_IO_Errno montre que l’instance reçoit une erreur 1236 d’I/O. Le champ Source_Log_File montre que le nom du fichier est mysql-bin-changelog.012345, ce qui signifie que l’index du fichier journal est 12345. Pour résoudre l’erreur, vous pouvez appeler mysql.rds_next_source_log avec le paramètre suivant :

CALL mysql.rds_next_source_log(12345);

mysql.rds_remove_binlog_ssl_material

Supprime le certificat de l’autorité de certification, le certificat du client et la clé du client pour la communication SSL et la réplication chiffrée. Ces informations sont importées à l’aide de mysql.rds_import_binlog_ssl_material.

Syntaxe

CALL mysql.rds_remove_binlog_ssl_material;

mysql.rds_reset_external_master (Aurora MySQL version 2)

Reconfigure une instance de base de données Aurora MySQL comme n’étant plus un réplica en lecture d’une instance de MySQL s’exécutant à l’extérieur d’Amazon RDS.

Syntaxe

CALL mysql.rds_reset_external_master;

Notes d’utilisation

L’utilisateur principal doit exécuter la procédure mysql.rds_reset_external_master. Cette procédure doit être exécutée sur l’instance de base de données MySQL à supprimer comme réplica en lecture d’une instance MySQL s’exécutant en dehors d’Amazon RDS.

Pour plus d’informations sur l’utilisation de la réplication pour importer des données à partir d’une instance de MySQL s’exécutant à l’extérieur d’Aurora MySQL, consultez Réplication entre Aurora et MySQL ou entre Aurora et un autre cluster de bases de données Aurora (réplication de journaux binaires).

mysql.rds_reset_external_source (Aurora MySQL version 3)

Reconfigure une instance de base de données Aurora MySQL comme n’étant plus un réplica en lecture d’une instance de MySQL s’exécutant à l’extérieur d’Amazon RDS.

Syntaxe

CALL mysql.rds_reset_external_source;

Notes d’utilisation

L’utilisateur administratif doit exécuter la procédure mysql.rds_reset_external_source. Cette procédure doit être exécutée sur l’instance de base de données MySQL à supprimer comme réplica en lecture d’une instance MySQL s’exécutant en dehors d’Amazon RDS.

mysql.rds_set_binlog_source_ssl (Aurora MySQL version 3)

Active le chiffrement SOURCE_SSL pour la réplication des journaux binaires. Pour plus d’informations, consultez Instruction CHANGE REPLICATION SOURCE TO dans la documentation MySQL.

Syntaxe

CALL mysql.rds_set_binlog_source_ssl(mode);

Paramètres

Notes d’utilisation

Cette procédure est prise en charge pour les versions 3.06 et supérieures d'Aurora MySQL.

mysql.rds_set_external_master (Aurora MySQL version 2)

Configure une instance de base de données Aurora MySQL comme réplica en lecture d’une instance de MySQL s’exécutant à l’extérieur d’Amazon RDS.

La procédure mysql.rds_set_external_master est obsolète et sera supprimée dans une version future. Utilisez mysql.rds_set_external_source à la place.

Syntaxe

CALL mysql.rds_set_external_master (
  host_name
  , host_port
  , replication_user_name
  , replication_user_password
  , mysql_binary_log_file_name
  , mysql_binary_log_file_location
  , ssl_encryption
);

Paramètres

Notes d’utilisation

L’utilisateur principal doit exécuter la procédure mysql.rds_set_external_master. Cette procédure doit être exécutée sur l’instance de base de données MySQL qui doit être configurée comme réplica en lecture d’une instance MySQL s’exécutant en dehors d’Amazon RDS.

Avant d’exécuter mysql.rds_set_external_master, vous devez configurer l’instance de MySQL s’exécutant en dehors de Amazon RDS comme instance de base de données source. Pour vous connecter à l’instance MySQL en cours d’exécution en dehors de Amazon RDS, vous devez spécifier des valeurs replication_user_name et replication_user_password qui indiquent un utilisateur de réplication possédant des autorisations REPLICATION CLIENT et REPLICATION SLAVE sur l’instance externe de MySQL.

Pour utiliser la réplication chiffrée, configurez l’instance de base de données source de façon à utiliser les connexions SSL. De même, importez le certificat de l’autorité de certification, le certificat du client et la clé du client dans l’instance de base de données ou le cluster de bases de données à l’aide de la procédure mysql.rds_import_binlog_ssl_material.

Après avoir appelé mysql.rds_set_external_master pour configurer une instance de base de données Amazon RDS comme réplica en lecture, vous pouvez appeler mysql.rds_start_replication sur le réplica en lecture pour démarrer le processus de réplication. Vous pouvez appeler mysql.rds_reset_external_master (Aurora MySQL version 2) pour supprimer la configuration du réplica en lecture.

Quand la procédure mysql.rds_set_external_master est appelée, Amazon RDS enregistre l’heure, l’utilisateur et une action de set master dans les tables mysql.rds_history et mysql.rds_replication_status.

Exemples

Lors d’une exécution sur une instance de base de données MySQL, l’exemple suivant configure l’instance de base de données comme réplica en lecture d’une instance de MySQL s’exécutant à l’extérieur d’Amazon RDS.

call mysql.rds_set_external_master(
  'Externaldb.some.com',
  3306,
  'repl_user',
  'password',
  'mysql-bin-changelog.0777',
  120,
  1);

mysql.rds_set_external_source (Aurora MySQL version 3)

Configure une instance de base de données Aurora MySQL comme réplica en lecture d’une instance de MySQL s’exécutant à l’extérieur d’Amazon RDS.

Syntaxe

CALL mysql.rds_set_external_source (
  host_name
  , host_port
  , replication_user_name
  , replication_user_password
  , mysql_binary_log_file_name
  , mysql_binary_log_file_location
  , ssl_encryption
);

Paramètres

Notes d’utilisation

L’utilisateur administratif doit exécuter la procédure mysql.rds_set_external_source. Cette procédure doit être exécutée sur l’instance de base de données Aurora MySQL qui doit être configurée comme réplica en lecture d’une instance MySQL s’exécutant en dehors d’Amazon RDS.

Avant d’exécuter mysql.rds_set_external_source, vous devez configurer l’instance de MySQL s’exécutant en dehors de Amazon RDS comme instance de base de données source. Pour vous connecter à l’instance MySQL en cours d’exécution en dehors de Amazon RDS, vous devez spécifier des valeurs replication_user_name et replication_user_password qui indiquent un utilisateur de réplication possédant des autorisations REPLICATION CLIENT et REPLICATION SLAVE sur l’instance externe de MySQL.

Pour utiliser la réplication chiffrée, configurez l’instance de base de données source de façon à utiliser les connexions SSL. De plus, importez le certificat de l’autorité de certification, le certificat du client et la clé du client dans l’instance de base de données ou le cluster de bases de données à l’aide de la procédure mysql.rds_import_binlog_ssl_material.

Après avoir appelé mysql.rds_set_external_source pour configurer une instance de base de données Aurora MySQL comme réplica en lecture, vous pouvez appeler mysql.rds_start_replication sur le réplica en lecture pour démarrer le processus de réplication. Vous pouvez appeler mysql.rds_reset_external_source (Aurora MySQL version 3) pour supprimer la configuration du réplica en lecture.

Quand la procédure mysql.rds_set_external_source est appelée, Amazon RDS enregistre l’heure, l’utilisateur et une action de set master dans les tables mysql.rds_history et mysql.rds_replication_status.

Exemples

Lors d’une exécution sur une instance de base de données Aurora MySQL, l’exemple suivant configure l’instance de base de données comme réplica en lecture d’une instance de MySQL s’exécutant à l’extérieur d’Amazon RDS.

call mysql.rds_set_external_source(
  'Externaldb.some.com',
  3306,
  'repl_user',
  'password',
  'mysql-bin-changelog.0777',
  120,
  1);

mysql.rds_set_external_master_with_auto_position (Aurora MySQL version 2)

Configure une instance principale Aurora MySQL afin d’accepter la réplication entrante à partir d’une instance MySQL externe. Cette procédure configure également la réplication en fonction des identifiants de transaction globaux ()GTIDs.

Cette procédure ne configure pas la réplication retardée, car Aurora MySQL ne prend pas en charge la réplication retardée.

Syntaxe

CALL mysql.rds_set_external_master_with_auto_position (
  host_name
  , host_port
  , replication_user_name
  , replication_user_password
  , ssl_encryption
);

Paramètres

Notes d’utilisation

Pour un cluster de bases de données Aurora MySQL, vous appelez cette procédure stockée lorsque vous êtes connecté à l’instance principale.

L'utilisateur principal doit exécuter la procédure mysql.rds_set_external_master_with_auto_position. L’utilisateur principal exécute cette procédure sur l’instance principale d’un cluster de bases de données Aurora MySQL qui agit en tant que cible de réplication. Il peut s’agir de la cible de réplication d’une instance de base de données MySQL externe ou d’un cluster de bases de données Aurora MySQL.

Cette procédure est prise en charge pour Aurora MySQL version 2. Pour Aurora MySQL version 3, utilisez la procédure mysql.rds_set_external_source_with_auto_position (Aurora MySQL version 3).

Avant d’exécuter mysql.rds_set_external_master_with_auto_position, configurez l’instance de base de données MySQL comme source de réplication. Pour vous connecter à l’instance MySQL externe, spécifiez des valeurs pour replication_user_name et replication_user_password. Ces valeurs doivent indiquer un utilisateur de réplication disposant des autorisations REPLICATION CLIENT et REPLICATION SLAVE sur l’instance MySQL externe.

Lorsque vous appelez mysql.rds_set_external_master_with_auto_position, Amazon RDS enregistre certaines informations. Il s’agit de l’heure, de l’utilisateur et d’une action de "set master" dans les tables mysql.rds_history et mysql.rds_replication_status.

Pour ignorer une transaction basée sur des identifiants de transaction globaux spécifique qui est réputée entraîner un problème, vous pouvez utiliser la procédure stockée mysql.rds_skip_transaction_with_gtid (Aurora MySQL versions 2 et 3). Pour plus d’informations sur la gestion d’une réplication basée sur des identifiants de transaction globaux, consultez Utilisation de la réplication basée sur des identifiants de transaction globaux (GTID).

Exemples

Lorsqu’il est exécuté sur une instance principale Aurora, l’exemple suivant configure le cluster Aurora pour qu’il agisse comme réplica en lecture d’une instance de MySQL s’exécutant à l’extérieur d’Aurora.

call mysql.rds_set_external_master_with_auto_position(
  'Externaldb.some.com',
  3306,
  'repl_user'@'mydomain.com',
  'SomePassW0rd');

mysql.rds_set_external_source_with_auto_position (Aurora MySQL version 3)

Configure une instance principale Aurora MySQL afin d’accepter la réplication entrante à partir d’une instance MySQL externe. Cette procédure configure également la réplication en fonction des identifiants de transaction globaux ()GTIDs.

Syntaxe

CALL mysql.rds_set_external_source_with_auto_position (
  host_name
  , host_port
  , replication_user_name
  , replication_user_password
  , ssl_encryption
);

Paramètres

Notes d’utilisation

Pour un cluster de bases de données Aurora MySQL, vous appelez cette procédure stockée lorsque vous êtes connecté à l’instance principale.

L’utilisateur administratif doit exécuter la procédure mysql.rds_set_external_source_with_auto_position. L’utilisateur administratif exécute cette procédure sur l’instance principale d’un cluster de bases de données Aurora MySQL qui agit en tant que cible de réplication. Il peut s’agir de la cible de réplication d’une instance de base de données MySQL externe ou d’un cluster de bases de données Aurora MySQL.

Cette procédure est prise en charge pour Aurora MySQL version 3. Cette procédure ne configure pas la réplication retardée, car Aurora MySQL ne prend pas en charge la réplication retardée.

Avant d’exécuter mysql.rds_set_external_source_with_auto_position, configurez l’instance de base de données MySQL comme source de réplication. Pour vous connecter à l’instance MySQL externe, spécifiez des valeurs pour replication_user_name et replication_user_password. Ces valeurs doivent indiquer un utilisateur de réplication disposant des autorisations REPLICATION CLIENT et REPLICATION SLAVE sur l’instance MySQL externe.

Lorsque vous appelez mysql.rds_set_external_source_with_auto_position, Amazon RDS enregistre certaines informations. Il s’agit de l’heure, de l’utilisateur et d’une action de "set master" dans les tables mysql.rds_history et mysql.rds_replication_status.

Pour ignorer une transaction basée sur des identifiants de transaction globaux spécifique qui est réputée entraîner un problème, vous pouvez utiliser la procédure stockée mysql.rds_skip_transaction_with_gtid (Aurora MySQL versions 2 et 3). Pour plus d’informations sur la gestion d’une réplication basée sur des identifiants de transaction globaux, consultez Utilisation de la réplication basée sur des identifiants de transaction globaux (GTID).

Exemples

Lorsqu’il est exécuté sur une instance principale Aurora, l’exemple suivant configure le cluster Aurora pour qu’il agisse comme réplica en lecture d’une instance de MySQL s’exécutant à l’extérieur d’Aurora.

call mysql.rds_set_external_source_with_auto_position(
  'Externaldb.some.com',
  3306,
  'repl_user'@'mydomain.com',
  'SomePassW0rd');

mysql.rds_set_master_auto_position (Aurora MySQL version 2)

Définit le mode de réplication en fonction des positions du fichier journal binaire ou des identificateurs de transaction globaux (GTIDs).

Syntaxe

CALL mysql.rds_set_master_auto_position (
auto_position_mode
);

Paramètres

Notes d’utilisation

L’utilisateur principal doit exécuter la procédure mysql.rds_set_master_auto_position.

Cette procédure est prise en charge pour Aurora MySQL version 2.

mysql.rds_set_read_only (Aurora MySQL version 3)

Active ou désactive le mode read_only de manière globale pour l’instance de base de données.

Syntaxe

CALL mysql.rds_set_read_only(mode);

Paramètres

Notes d’utilisation

La procédure mysql.rds_set_read_only stockée modifie uniquement le paramètre read_only. Le paramètre innodb_read_only ne peut pas être modifié sur les instances de base de données du lecteur.

Le changement du paramètre read_only ne persiste pas au redémarrage. Pour apporter des modifications permanentes à read_only, vous devez utiliser le paramètre read_only du cluster de bases de données.

Cette procédure est prise en charge pour les versions 3.06 et supérieures d'Aurora MySQL.

mysql.rds_set_session_binlog_format (Aurora MySQL version 2)

Définit le format de journal binaire pour la session en cours.

Syntaxe

CALL mysql.rds_set_session_binlog_format(format);

Paramètres

Notes d’utilisation

Pour un cluster de bases de données Aurora MySQL, vous appelez cette procédure stockée lorsque vous êtes connecté à l’instance principale.

Pour utiliser cette procédure stockée, la journalisation binaire doit être configurée pour la session en cours.

Pour Aurora, cette procédure est prise en charge pour Aurora MySQL version 2.12 et les versions ultérieures, compatibles avec MySQL 5.7.

mysql.rds_set_source_auto_position (Aurora MySQL version 3)

Définit le mode de réplication en fonction des positions du fichier journal binaire ou des identificateurs de transaction globaux (GTIDs).

Syntaxe

CALL mysql.rds_set_source_auto_position (auto_position_mode);

Paramètres

Notes d’utilisation

Pour un cluster de bases de données Aurora MySQL, vous appelez cette procédure stockée lorsque vous êtes connecté à l’instance principale.

L’utilisateur administratif doit exécuter la procédure mysql.rds_set_source_auto_position.

mysql.rds_skip_repl_error

Ignore et supprime une erreur de réplication sur un réplica en lecture d’une base de données MySQL.

Syntaxe

CALL mysql.rds_skip_repl_error;

Notes d’utilisation

L’utilisateur principal doit exécuter la procédure mysql.rds_skip_repl_error sur un réplica en lecture. Pour plus d’informations sur cette procédure, consultez Ignorer une erreur de réplication.

Pour déterminer s’il y a des erreurs, exécutez la commande MySQL SHOW REPLICA STATUS\G. Si une erreur de réplication n’est pas critique, vous pouvez exécuter mysql.rds_skip_repl_error pour ignorer l’erreur. S’il y a plusieurs erreurs, mysql.rds_skip_repl_error supprime la première erreur, puis avertit qu’il y a d’autres erreurs. Vous pouvez alors utiliser SHOW REPLICA STATUS\G pour déterminer l’action appropriée pour l’erreur suivante. Pour obtenir des informations sur les valeurs renvoyées, consultez Instruction SHOW REPLICA STATUS dans la documentation sur MySQL.

Pour plus d’informations sur le traitement des erreurs de réplication avec Aurora MySQL, consultez Diagnostic et résolution d’une défaillance de la réplication en lecture MySQL.

Erreur d’arrêt de réplication

Lorsque vous appelez la procédure mysql.rds_skip_repl_error, un message d’erreur peut s’afficher pour indiquer que le réplica a rencontré une erreur ou est désactivé.

Ce message d’erreur s’affiche si vous exécutez la procédure sur l’instance principale plutôt que sur le réplica en lecture. Vous devez exécuter cette procédure sur le réplica en lecture pour que la procédure fonctionne.

Ce message d’erreur peut également s’afficher si vous exécutez la procédure sur le réplica en lecture, mais que la réplication ne peut pas être redémarrée correctement.

Si vous avez besoin d’ignorer un grand nombre d’erreurs, le retard de réplication peut augmenter et dépasser la période de rétention par défaut pour les fichiers journaux binaires (binlog). Dans ce cas, vous pouvez rencontrer une erreur irrécupérable due à des fichiers journaux binaires purgés avant d’avoir été réutilisés sur le réplica en lecture. Cette purge entraîne l’arrêt de la réplication et vous ne pouvez plus appeler la commande mysql.rds_skip_repl_error pour ignorer les erreurs de réplication.

Vous pouvez atténuer ce problème en augmentant le nombre d’heures pendant lequel les fichiers journaux binaires sont conservés sur votre instance de base de données source. Une fois que vous avez augmenté le temps de rétention de journaux binaires, vous pouvez redémarrer la réplication et appeler la commande mysql.rds_skip_repl_error en fonction des besoins.

Pour définir la période de rétention des journaux binaires, utilisez la procédure mysql.rds_set_configuration et spécifiez un paramètre de configuration 'binlog retention hours', ainsi que le nombre d’heures pendant lequel conserver les fichiers journaux binaires sur le cluster de bases de données. L’exemple suivant définit la période de rétention des fichiers journaux binaires à 48 heures.

CALL mysql.rds_set_configuration('binlog retention hours', 48);

mysql.rds_start_replication

Lance la réplication à partir d’un cluster de bases de données Aurora MySQL.

Syntaxe

CALL mysql.rds_start_replication;

Notes d’utilisation

L’utilisateur principal doit exécuter la procédure mysql.rds_start_replication.

Pour importer des données à partir d’une instance de MySQL externe à Amazon RDS, appelez mysql.rds_start_replication sur le réplica en lecture pour démarrer le processus de réplication après avoir appelé mysql.rds_set_external_master (Aurora MySQL version 2)ou mysql.rds_set_external_source (Aurora MySQL version 3) pour créer la configuration de réplication. Pour plus d’informations, consultez Réplication entre Aurora et MySQL ou entre Aurora et un autre cluster de bases de données Aurora (réplication de journaux binaires).

Pour exporter des données vers une instance de MySQL extérieure à Amazon RDS, appelez mysql.rds_start_replication et mysql.rds_stop_replication sur le réplica en lecture pour contrôler certaines actions de réplication, telles que la purge des journaux binaires. Pour plus d’informations, consultez Réplication entre Aurora et MySQL ou entre Aurora et un autre cluster de bases de données Aurora (réplication de journaux binaires).

Vous pouvez aussi appeler mysql.rds_start_replication sur le réplica en lecture pour redémarrer un processus de réplication que vous avez précédemment arrêté en appelant mysql.rds_stop_replication. Pour plus d’informations, consultez Erreur d’arrêt de réplication.

mysql.rds_start_replication_until (Aurora MySQL version 3)

Lance la réplication à partir d’un cluster de bases de données Aurora MySQL et arrête la réplication à la position spécifiée dans le fichier journal binaire.

Syntaxe

CALL mysql.rds_start_replication_until (
replication_log_file
  , replication_stop_point
);

Paramètres

Notes d’utilisation

L’utilisateur principal doit exécuter la procédure mysql.rds_start_replication_until.

Cette procédure est prise en charge pour Aurora MySQL versions 3.04 et ultérieures.

La procédure mysql.rds_start_replication_until stockée n’est pas prise en charge pour la réplication gérée, qui inclut les éléments suivants :

Le nom de fichier spécifié pour le paramètre replication_log_file doit correspondre au nom du fichier binlog de l’instance de base de données source.

Lorsque le paramètre replication_stop_point spécifie une position d’arrêt survenant dans le passé, la réplication est arrêtée immédiatement.

Exemples

L’exemple suivant lance la réplication et réplique les modifications jusqu’à ce qu’il atteigne la position 120 dans le fichier journal binaire mysql-bin-changelog.000777.

call mysql.rds_start_replication_until(
  'mysql-bin-changelog.000777',
  120);

mysql.rds_stop_replication

Arrête la réplication à partir d’une instance de base de données MySQL.

Syntaxe

CALL mysql.rds_stop_replication;

Notes d’utilisation

L’utilisateur principal doit exécuter la procédure mysql.rds_stop_replication.

Si vous configurez la réplication pour importer des données à partir d’une instance de MySQL s’exécutant à l’extérieur d’Amazon RDS, vous appelez mysql.rds_stop_replication sur le réplica en lecture pour arrêter le processus de réplication après que l’importation soit terminée. Pour plus d’informations, consultez Réplication entre Aurora et MySQL ou entre Aurora et un autre cluster de bases de données Aurora (réplication de journaux binaires).

Si vous configurez la réplication pour exporter les données vers une instance de MySQL extérieure à Amazon RDS, vous appelez mysql.rds_start_replication et mysql.rds_stop_replication sur le réplica en lecture pour contrôler certaines actions de réplication, telles que la purge des journaux binaires. Pour plus d’informations, consultez Réplication entre Aurora et MySQL ou entre Aurora et un autre cluster de bases de données Aurora (réplication de journaux binaires).

La procédure mysql.rds_stop_replication stockée n’est pas prise en charge pour la réplication gérée, qui inclut les éléments suivants :