Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# 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.
**Topics**
+ [mysql.rds\$1disable\$1session\$1binlog (Aurora MySQL version 2)](#mysql_rds_disable_session_binlog)
+ [mysql.rds\$1enable\$1session\$1binlog (Aurora MySQL version 2)](#mysql_rds_enable_session_binlog)
+ [mysql.rds\$1import\$1binlog\$1ssl\$1material](#mysql_rds_import_binlog_ssl_material)
+ [mysql.rds\$1next\$1master\$1log ( 2)](#mysql_rds_next_master_log)
+ [mysql.rds\$1next\$1source\$1log (Aurora MySQL version 3)](#mysql_rds_next_source_log)
+ [mysql.rds\$1remove\$1binlog\$1ssl\$1material](#mysql_rds_remove_binlog_ssl_material)
+ [mysql.rds\$1reset\$1external\$1master (Aurora MySQL version 2)](#mysql_rds_reset_external_master)
+ [mysql.rds\$1reset\$1external\$1source (Aurora MySQL version 3)](#mysql_rds_reset_external_source)
+ [mysql.rds\$1set\$1binlog\$1source\$1ssl (Aurora MySQL version 3)](#mysql_rds_set_binlog_source_ssl)
+ [mysql.rds\$1set\$1external\$1master (Aurora MySQL version 2)](#mysql_rds_set_external_master)
+ [mysql.rds\$1set\$1external\$1source (Aurora MySQL version 3)](#mysql_rds_set_external_source)
+ [mysql.rds\$1set\$1external\$1master\$1with\$1auto\$1position (Aurora MySQL version 2)](#mysql_rds_set_external_master_with_auto_position)
+ [mysql.rds\$1set\$1external\$1source\$1with\$1auto\$1position (Aurora MySQL version 3)](#mysql_rds_set_external_source_with_auto_position)
+ [mysql.rds\$1set\$1master\$1auto\$1position 2)](#mysql_rds_set_master_auto_position)
+ [mysql.rds\$1set\$1read\$1only (Aurora MySQL version 3)](#mysql_rds_set_read_only)
+ [mysql.rds\$1set\$1session\$1binlog\$1format (Aurora MySQL version 2)](#mysql_rds_set_session_binlog_format)
+ [mysql.rds\$1set\$1source\$1auto\$1position (Aurora MySQL version 3)](#mysql_rds_set_source_auto_position)
+ [mysql.rds\$1skip\$1repl\$1error](#mysql_rds_skip_repl_error)
+ [mysql.rds\$1start\$1replication](#mysql_rds_start_replication)
+ [mysql.rds\$1start\$1replication\$1until (Aurora MySQL version 3)](#mysql_rds_start_replication_until)
+ [mysql.rds\$1stop\$1replication](#mysql_rds_stop_replication)
## mysql.rds\$1disable\$1session\$1binlog (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;
```
### Parameters
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.
**Note**
Dans Aurora MySQL version 3, vous pouvez utiliser la commande suivante pour désactiver la journalisation binaire pour la session en cours si vous disposez du privilège `SESSION_VARIABLES_ADMIN` :
```
SET SESSION sql_log_bin = OFF;
```
## mysql.rds\$1enable\$1session\$1binlog (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;
```
### Parameters
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.
**Note**
Dans Aurora MySQL version 3, vous pouvez utiliser la commande suivante pour activer la journalisation binaire pour la session en cours si vous disposez du privilège `SESSION_VARIABLES_ADMIN` :
```
SET SESSION sql_log_bin = ON;
```
## mysql.rds\$1import\$1binlog\$1ssl\$1material
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.
**Note**
Actuellement, cette procédure est prise en charge pour Aurora MySQL version 2 : 2.09.2, 2.10.0, 2.10.1 et 2.11.0 ; et version 3 : 3.01.1 et versions ultérieures.
### Syntaxe
```
CALL mysql.rds_import_binlog_ssl_material (
ssl_material
);
```
### Parameters
*ssl\$1material*
Données utiles JSON contenant le contenu des fichiers au format .pem suivants pour un client MySQL :
+ « ssl\$1ca » : » » *Certificate authority certificate*
+ « certificat SSL » : » » *Client certificate*
+ « clé\$1SSL » : » » *Client key*
### Notes d’utilisation
Avant d’exécuter cette procédure, préparez-vous à la réplication chiffrée :
+ Si le protocole SSL n’est pas activé sur l’instance de base de données source MySQL externe et que vous ne disposez pas d’une clé client et d’un certificat client prêts, activez le protocole SSL sur le serveur de base de données MySQL et générez la clé client et le certificat client requis.
+ Si le protocole SSL est activé sur l’instance de base de données source externe, fournissez une clé et un certificat client pour le cluster de bases de données Aurora MySQL. En leur absence, générez une nouvelle clé et un nouveau certificat pour le cluster de bases de données Aurora MySQL. Pour signer le certificat client, vous devez disposer de la clé d’autorité de certification utilisée pour configurer le protocole SSL sur l’instance de base de données source MySQL externe.
Pour plus d’informations, consultez [Création de certificats et clés SSL à l’aide d’openssl](https://dev.mysql.com/doc/refman/8.0/en/creating-ssl-files-using-openssl.html) dans la documentation MySQL.
**Important**
Après vous être préparé à la réplication chiffrée, utilisez une connexion SSL pour exécuter cette procédure. La clé du client ne doit pas être transférée au moyen d’une connexion non sécurisée.
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\$1next\$1master\$1log ( 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
);
```
### Parameters
*curr\$1master\$1log*
Index du fichier journal maître actif. Par exemple, si le fichier en cours se nomme `mysql-bin-changelog.012345`, l’index est 12345. Pour déterminer le nom du fichier journal maître actif, exécutez la commande `SHOW REPLICA STATUS` et affichez le champ `Master_Log_File`.
### Notes d’utilisation
L’utilisateur principal doit exécuter la procédure `mysql.rds_next_master_log`.
**Avertissement**
Appelez `mysql.rds_next_master_log` uniquement si la réplication échoue après le basculement d'une instance de base de données multi-AZ qui est la source de réplication et si le `Last_IO_Errno` champ de `SHOW REPLICA STATUS` signale l' I/O erreur 1236.
L’appel de `mysql.rds_next_master_log` peut se traduire par une perte de données dans le réplica en lecture si les transactions de l’instance source n’ont pas été écrites dans le journal binaire sur disque avant que l’événement de basculement se produise.
### 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\$1next\$1source\$1log (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
);
```
### Parameters
*curr\$1source\$1log*
Index du fichier journal source actuel. Par exemple, si le fichier en cours se nomme `mysql-bin-changelog.012345`, l’index est 12345. Pour déterminer le nom du fichier journal actuel, exécutez la commande `SHOW REPLICA STATUS` et affichez le champ `Source_Log_File`.
### Notes d’utilisation
L’utilisateur administratif doit exécuter la procédure `mysql.rds_next_source_log`.
**Avertissement**
Appelez `mysql.rds_next_source_log` uniquement si la réplication échoue après le basculement d'une instance de base de données multi-AZ qui est la source de réplication et si le `Last_IO_Errno` champ de `SHOW REPLICA STATUS` signale l' I/O erreur 1236.
L’appel de `mysql.rds_next_source_log` peut se traduire par une perte de données dans le réplica en lecture si les transactions de l’instance source n’ont pas été écrites dans le journal binaire sur disque avant que l’événement de basculement se produise. Vous pouvez réduire la probabilité que cela se produise en définissant les paramètres d’instance source `sync_binlog` et `innodb_support_xa` sur `1`, même si cela peut compromettre les performances.
### 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\$1remove\$1binlog\$1ssl\$1material
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\$1import\$1binlog\$1ssl\$1material](#mysql_rds_import_binlog_ssl_material).
### Syntaxe
```
CALL mysql.rds_remove_binlog_ssl_material;
```
## mysql.rds\$1reset\$1external\$1master (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.
**Important**
Pour exécuter cette procédure, `autocommit` doit être activé. Pour l’activer, définissez le paramètre `autocommit` sur `1`. Pour plus d’informations sur la modification des paramètres d’instance, consultez [Modification de paramètres dans un groupe de paramètres de base de données dans Amazon Aurora](USER_WorkingWithParamGroups.Modifying.md).
### 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.
**Note**
Nous proposons ces procédures stockées avant tout pour permettre la réplication avec les instances MySQL s’exécutant en dehors d’Amazon RDS. Nous vous conseillons d’utiliser les réplicas Aurora pour gérer la réplication au sein d’un cluster de bases de données Aurora MySQL, dès que possible. Pour plus d’informations sur la gestion de la réplication dans des clusters de bases de données Aurora MySQL, consultez [Utilisation de réplicas Aurora](AuroraMySQL.Replication.md#AuroraMySQL.Replication.Replicas).
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)](AuroraMySQL.Replication.MySQL.md).
## mysql.rds\$1reset\$1external\$1source (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.
**Important**
Pour exécuter cette procédure, `autocommit` doit être activé. Pour l’activer, définissez le paramètre `autocommit` sur `1`. Pour plus d’informations sur la modification des paramètres d’instance, consultez [Modification de paramètres dans un groupe de paramètres de base de données dans Amazon Aurora](USER_WorkingWithParamGroups.Modifying.md).
### 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.
**Note**
Nous proposons ces procédures stockées avant tout pour permettre la réplication avec les instances MySQL s’exécutant en dehors d’Amazon RDS. Nous vous conseillons d’utiliser les réplicas Aurora pour gérer la réplication au sein d’un cluster de bases de données Aurora MySQL, dès que possible. Pour plus d’informations sur la gestion de la réplication dans des clusters de bases de données Aurora MySQL, consultez [Utilisation de réplicas Aurora](AuroraMySQL.Replication.md#AuroraMySQL.Replication.Replicas).
## mysql.rds\$1set\$1binlog\$1source\$1ssl (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](https://dev.mysql.com/doc/refman/8.0/en/change-replication-source-to.html) dans la documentation MySQL.
### Syntaxe
```
CALL mysql.rds_set_binlog_source_ssl(mode);
```
### Parameters
*mode*
Valeur qui indique si le chiffrement `SOURCE_SSL` est activé :
+ `0` : le chiffrement `SOURCE_SSL` est désactivé. La valeur par défaut est `0`.
+ `1` : le chiffrement `SOURCE_SSL` est activé. Vous pouvez configurer le chiffrement à l’aide du protocole SSL ou TLS.
### Notes d’utilisation
Cette procédure est prise en charge pour les versions 3.06 et supérieures d'Aurora MySQL.
## mysql.rds\$1set\$1external\$1master (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\$1set\$1external\$1source` à la place.
**Important**
Pour exécuter cette procédure, `autocommit` doit être activé. Pour l’activer, définissez le paramètre `autocommit` sur `1`. Pour plus d’informations sur la modification des paramètres d’instance, consultez [Modification de paramètres dans un groupe de paramètres de base de données dans Amazon Aurora](USER_WorkingWithParamGroups.Modifying.md).
### 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
);
```
### Parameters
*host\$1name*
Nom d’hôte ou adresse IP de l’instance MySQL s’exécutant à l’extérieur d’Amazon RDS pour devenir l’instance de base de données source.
*host\$1port*
Port utilisé par l’instance MySQL s’exécutant à l’extérieur d’Amazon RDS et à configurer comme instance de base de données source. Si votre configuration réseau inclut une réplication de port Secure Shell (SSH) qui convertit le numéro de port, spécifiez le numéro de port qui est exposé par SSH.
*replication\$1user\$1name*
ID d’un utilisateur disposant des autorisations `REPLICATION CLIENT` et `REPLICATION SLAVE` sur l’instance MySQL s’exécutant à l’extérieur d’Amazon RDS. Nous vous recommandons de fournir un compte qui soit utilisé uniquement pour la réplication avec l’instance externe.
*replication\$1user\$1password*
Mot de passe de l’ID utilisateur spécifié dans `replication_user_name`.
*mysql\$1binary\$1log\$1file\$1name*
Nom du journal binaire sur l’instance de base de données source qui contient les informations de réplication.
*mysql\$1binary\$1log\$1file\$1location*
Emplacement dans le journal binaire `mysql_binary_log_file_name` à partir duquel la réplication commence à lire les informations de réplication.
Vous pouvez déterminer le nom et l’emplacement du fichier journal binaire en exécutant `SHOW MASTER STATUS` sur l’instance de base de données source.
*ssl\$1encryption*
Valeur indiquant si le chiffrement Secure Socket Layer (SSL) est utilisé sur la connexion de réplication. La valeur 1 spécifie d’utiliser le chiffrement SSL, et la valeur 0 de ne pas l’utiliser. La valeur par défaut est 0.
L’option `MASTER_SSL_VERIFY_SERVER_CERT` n’est pas prise en charge. Cette option est définie sur 0, ce qui signifie que la connexion est chiffrée, mais que les certificats ne sont pas vérifiés.
### 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 configurer une instance externe de MySQL en tant qu’instance de base de données source**
1. A l’aide du client MySQL de votre choix, connectez-vous à l’instance externe de MySQL et créez un compte d’utilisateur à utiliser pour la réplication. Voici un exemple.
**MySQL 5.7**
```
CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY 'password';
```
**MySQL 8.0**
```
CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED WITH mysql_native_password BY 'password';
```
**Note**
Spécifiez un mot de passe autre que celui indiqué ici, en tant que bonne pratique de sécurité.
1. Sur l’instance externe de MySQL, accordez les privilèges `REPLICATION CLIENT` et `REPLICATION SLAVE` à votre utilisateur de réplication. L’exemple suivant accorde les privilèges `REPLICATION CLIENT` et `REPLICATION SLAVE` sur toutes les bases de données pour l’utilisateur « repl\$1user » de votre domaine.
**MySQL 5.7**
```
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com' IDENTIFIED BY 'password';
```
**MySQL 8.0**
```
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com';
```
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\$1import\$1binlog\$1ssl\$1material](#mysql_rds_import_binlog_ssl_material).
**Note**
Nous proposons ces procédures stockées avant tout pour permettre la réplication avec les instances MySQL s’exécutant en dehors d’Amazon RDS. Nous vous conseillons d’utiliser les réplicas Aurora pour gérer la réplication au sein d’un cluster de bases de données Aurora MySQL, dès que possible. Pour plus d’informations sur la gestion de la réplication dans des clusters de bases de données Aurora MySQL, consultez [Utilisation de réplicas Aurora](AuroraMySQL.Replication.md#AuroraMySQL.Replication.Replicas).
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\$1start\$1replication](#mysql_rds_start_replication) sur le réplica en lecture pour démarrer le processus de réplication. Vous pouvez appeler [mysql.rds\$1reset\$1external\$1master (Aurora MySQL version 2)](#mysql_rds_reset_external_master) 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\$1set\$1external\$1source (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.
**Important**
Pour exécuter cette procédure, `autocommit` doit être activé. Pour l’activer, définissez le paramètre `autocommit` sur `1`. Pour plus d’informations sur la modification des paramètres d’instance, consultez [Modification de paramètres dans un groupe de paramètres de base de données dans Amazon Aurora](USER_WorkingWithParamGroups.Modifying.md).
### 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
);
```
### Parameters
*host\$1name*
Nom d’hôte ou adresse IP de l’instance MySQL s’exécutant à l’extérieur d’Amazon RDS pour devenir l’instance de base de données source.
*host\$1port*
Port utilisé par l’instance MySQL s’exécutant à l’extérieur d’Amazon RDS et à configurer comme instance de base de données source. Si votre configuration réseau inclut une réplication de port Secure Shell (SSH) qui convertit le numéro de port, spécifiez le numéro de port qui est exposé par SSH.
*replication\$1user\$1name*
ID d’un utilisateur disposant des autorisations `REPLICATION CLIENT` et `REPLICATION SLAVE` sur l’instance MySQL s’exécutant à l’extérieur d’Amazon RDS. Nous vous recommandons de fournir un compte qui soit utilisé uniquement pour la réplication avec l’instance externe.
*replication\$1user\$1password*
Mot de passe de l’ID utilisateur spécifié dans `replication_user_name`.
*mysql\$1binary\$1log\$1file\$1name*
Nom du journal binaire sur l’instance de base de données source qui contient les informations de réplication.
*mysql\$1binary\$1log\$1file\$1location*
Emplacement dans le journal binaire `mysql_binary_log_file_name` à partir duquel la réplication commence à lire les informations de réplication.
Vous pouvez déterminer le nom et l’emplacement du fichier journal binaire en exécutant `SHOW MASTER STATUS` sur l’instance de base de données source.
*ssl\$1encryption*
Valeur indiquant si le chiffrement Secure Socket Layer (SSL) est utilisé sur la connexion de réplication. La valeur 1 spécifie d’utiliser le chiffrement SSL, et la valeur 0 de ne pas l’utiliser. La valeur par défaut est 0.
Vous devez avoir importé un certificat SSL personnalisé [mysql.rds\$1import\$1binlog\$1ssl\$1material](#mysql_rds_import_binlog_ssl_material) pour activer cette option. Si vous n’avez pas importé de certificat SSL personnalisé, définissez ce paramètre sur 0 et utilisez [mysql.rds\$1set\$1binlog\$1source\$1ssl (Aurora MySQL version 3)](#mysql_rds_set_binlog_source_ssl) pour activer le protocole SSL pour la réplication des journaux binaires.
L’option `SOURCE_SSL_VERIFY_SERVER_CERT` n’est pas prise en charge. Cette option est définie sur 0, ce qui signifie que la connexion est chiffrée, mais que les certificats ne sont pas vérifiés.
### 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 configurer une instance externe de MySQL en tant qu’instance de base de données source**
1. A l’aide du client MySQL de votre choix, connectez-vous à l’instance externe de MySQL et créez un compte d’utilisateur à utiliser pour la réplication. Voici un exemple.
```
CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY 'password';
```
**Note**
Spécifiez un mot de passe autre que celui indiqué ici, en tant que bonne pratique de sécurité.
1. Sur l’instance externe de MySQL, accordez les privilèges `REPLICATION CLIENT` et `REPLICATION SLAVE` à votre utilisateur de réplication. L’exemple suivant accorde les privilèges `REPLICATION CLIENT` et `REPLICATION SLAVE` sur toutes les bases de données pour l’utilisateur « repl\$1user » de votre domaine.
```
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com';
```
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\$1import\$1binlog\$1ssl\$1material](url-rds-user;mysql_rds_import_binlog_ssl_material.html).
**Note**
Nous proposons ces procédures stockées avant tout pour permettre la réplication avec les instances MySQL s’exécutant en dehors d’Amazon RDS. Nous vous conseillons d’utiliser les réplicas Aurora pour gérer la réplication au sein d’un cluster de bases de données Aurora MySQL, dès que possible. Pour plus d’informations sur la gestion de la réplication dans des clusters de bases de données Aurora MySQL, consultez [Utilisation de réplicas Aurora](AuroraMySQL.Replication.md#AuroraMySQL.Replication.Replicas).
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\$1start\$1replication](#mysql_rds_start_replication) sur le réplica en lecture pour démarrer le processus de réplication. Vous pouvez appeler [mysql.rds\$1reset\$1external\$1source (Aurora MySQL version 3)](#mysql_rds_reset_external_source) 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\$1set\$1external\$1master\$1with\$1auto\$1position (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
);
```
### Parameters
*host\$1name*
Nom d’hôte ou adresse IP de l’instance MySQL s’exécutant à l’extérieur d’Aurora pour devenir la source de réplication.
*host\$1port*
Port utilisé par l’instance MySQL s’exécutant à l’extérieur d’Aurora et à configurer comme source de réplication. Si votre configuration réseau inclut une réplication de port Secure Shell (SSH) qui convertit le numéro de port, spécifiez le numéro de port qui est exposé par SSH.
*replication\$1user\$1name*
ID d’un utilisateur disposant des autorisations `REPLICATION CLIENT` et `REPLICATION SLAVE` sur l’instance MySQL s’exécutant à l’extérieur d’Aurora. Nous vous recommandons de fournir un compte qui soit utilisé uniquement pour la réplication avec l’instance externe.
*replication\$1user\$1password*
Mot de passe de l’ID utilisateur spécifié dans `replication_user_name`.
*ssl\$1encryption*
Cette option n’est pas actuellement implémentée. La valeur par défaut est 0.
### 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\$1set\$1external\$1source\$1with\$1auto\$1position (Aurora MySQL version 3)](#mysql_rds_set_external_source_with_auto_position).
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.
**Pour configurer une instance MySQL externe comme source de réplication**
1. À l’aide du client MySQL de votre choix, connectez-vous à l’instance MySQL externe et créez un compte utilisateur à utiliser pour la réplication. Voici un exemple de.
```
CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY 'SomePassW0rd'
```
1. Sur l’instance MySQL externe, attribuez les privilèges `REPLICATION CLIENT` et `REPLICATION SLAVE` à votre utilisateur de réplication. L’exemple suivant accorde les privilèges `REPLICATION CLIENT` et `REPLICATION SLAVE` sur toutes les bases de données pour l’utilisateur `'repl_user'` de votre domaine.
```
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com'
IDENTIFIED BY 'SomePassW0rd'
```
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\$1skip\$1transaction\$1with\$1gtid (Aurora MySQL versions 2 et 3)](mysql-stored-proc-gtid.md#mysql_rds_skip_transaction_with_gtid). 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)](mysql-replication-gtid.md).
### 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\$1set\$1external\$1source\$1with\$1auto\$1position (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
);
```
### Parameters
*host\$1name*
Nom d’hôte ou adresse IP de l’instance MySQL s’exécutant à l’extérieur d’Aurora pour devenir la source de réplication.
*host\$1port*
Port utilisé par l’instance MySQL s’exécutant à l’extérieur d’Aurora et à configurer comme source de réplication. Si votre configuration réseau inclut une réplication de port Secure Shell (SSH) qui convertit le numéro de port, spécifiez le numéro de port qui est exposé par SSH.
*replication\$1user\$1name*
ID d’un utilisateur disposant des autorisations `REPLICATION CLIENT` et `REPLICATION SLAVE` sur l’instance MySQL s’exécutant à l’extérieur d’Aurora. Nous vous recommandons de fournir un compte qui soit utilisé uniquement pour la réplication avec l’instance externe.
*replication\$1user\$1password*
Mot de passe de l’ID utilisateur spécifié dans `replication_user_name`.
*ssl\$1encryption*
Cette option n’est pas actuellement implémentée. La valeur par défaut est 0.
Utilisez [mysql.rds\$1set\$1binlog\$1source\$1ssl (Aurora MySQL version 3)](#mysql_rds_set_binlog_source_ssl) pour activer SSL pour la réplication des journaux binaires.
### 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.
**Pour configurer une instance MySQL externe comme source de réplication**
1. À l’aide du client MySQL de votre choix, connectez-vous à l’instance MySQL externe et créez un compte utilisateur à utiliser pour la réplication. Voici un exemple de.
```
CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY 'SomePassW0rd'
```
1. Sur l’instance MySQL externe, attribuez les privilèges `REPLICATION CLIENT` et `REPLICATION SLAVE` à votre utilisateur de réplication. L’exemple suivant accorde les privilèges `REPLICATION CLIENT` et `REPLICATION SLAVE` sur toutes les bases de données pour l’utilisateur `'repl_user'` de votre domaine.
```
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com'
IDENTIFIED BY 'SomePassW0rd'
```
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\$1skip\$1transaction\$1with\$1gtid (Aurora MySQL versions 2 et 3)](mysql-stored-proc-gtid.md#mysql_rds_skip_transaction_with_gtid). 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)](mysql-replication-gtid.md).
### 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\$1set\$1master\$1auto\$1position 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
);
```
### Parameters
*auto\$1position\$1mode*
Valeur qui indique si la réplication à utiliser est la réplication basée sur la position de fichier ou la réplication basée sur les identifiants de transaction globaux :
+ `0` : utiliser la méthode de réplication basée sur la position du fichier journal binaire. La valeur par défaut est `0`.
+ `1` : utiliser la méthode de réplication basée sur les identifiants de transaction globaux.
### 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\$1set\$1read\$1only (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);
```
### Parameters
*mode*
Une valeur qui indique si le mode `read_only` est activé ou désactivé globalement pour l’instance de base de données :
+ `0` : `OFF`. La valeur par défaut est `0`.
+ `1` – `ON`
### 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\$1set\$1session\$1binlog\$1format (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);
```
### Parameters
*format*
Valeur qui indique le format de journal binaire pour la session en cours :
+ `STATEMENT` : la source de réplication écrit les événements dans le journal binaire sur la base d’instructions SQL.
+ `ROW` : la source de réplication écrit les événements dans le journal binaire qui indiquent les modifications apportées aux lignes individuelles des tables.
+ `MIXED` : la journalisation est généralement basée sur des instructions SQL, mais passe aux lignes sous certaines conditions. Pour plus d’informations, consultez [Format mixte de journalisation binaire](https://dev.mysql.com/doc/refman/8.0/en/binary-log-mixed.html) (langue française non garantie) dans la documentation MySQL.
### 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\$1set\$1source\$1auto\$1position (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);
```
### Parameters
*auto\$1position\$1mode*
Valeur qui indique si la réplication à utiliser est la réplication basée sur la position de fichier ou la réplication basée sur les identifiants de transaction globaux :
+ `0` : utiliser la méthode de réplication basée sur la position du fichier journal binaire. La valeur par défaut est `0`.
+ `1` : utiliser la méthode de réplication basée sur les identifiants de transaction globaux.
### 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\$1skip\$1repl\$1error
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](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.MySQL.CommonDBATasks.html#Appendix.MySQL.CommonDBATasks.SkipError).
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](https://dev.mysql.com/doc/refman/8.0/en/show-replica-status.html) 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'un échec de réplication en lecture MySQL ](CHAP_Troubleshooting.md#CHAP_Troubleshooting.MySQL.RR).
#### 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\$1set\$1configuration](mysql-stored-proc-configuring.md#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\$1start\$1replication
Lance la réplication à partir d’un cluster de bases de données Aurora MySQL.
**Note**
Vous pouvez utiliser la procédure stockée [mysql.rds\$1start\$1replication\$1until (Aurora MySQL version 3)](#mysql_rds_start_replication_until) ou [mysql.rds\$1start\$1replication\$1until\$1gtid (Aurora MySQL version 3)](mysql-stored-proc-gtid.md#mysql_rds_start_replication_until_gtid) pour lancer la réplication à partir d’une instance de base de données Aurora MySQL et arrêter la réplication à la position spécifiée dans le fichier journal binaire.
### 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\$1set\$1external\$1master (Aurora MySQL version 2)](#mysql_rds_set_external_master)ou [mysql.rds\$1set\$1external\$1source (Aurora MySQL version 3)](#mysql_rds_set_external_source) 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)](AuroraMySQL.Replication.MySQL.md).
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)](AuroraMySQL.Replication.MySQL.md).
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 de plus amples informations, veuillez consulter [Erreur d’arrêt de réplication](CHAP_Troubleshooting.md#CHAP_Troubleshooting.MySQL.ReplicationStopped).
## mysql.rds\$1start\$1replication\$1until (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
);
```
### Parameters
*replication\$1log\$1file*
Nom du journal binaire sur l’instance de base de données source qui contient les informations de réplication.
*replication\$1stop\$1point *
Position dans le journal binaire `replication_log_file` à laquelle la réplication s’arrêtera.
### 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 :
+ [Réplication de clusters de bases de données Amazon Aurora MySQL dans différentes Régions AWS](AuroraMySQL.Replication.CrossRegion.md)
+ [Migration des données d’une instance de base de données RDS for MySQL vers un cluster de bases de données Amazon Aurora MySQL à l’aide d’un réplica en lecture Aurora](AuroraMySQL.Migrating.RDSMySQL.Replica.md)
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\$1stop\$1replication
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)](AuroraMySQL.Replication.MySQL.md).
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)](AuroraMySQL.Replication.MySQL.md).
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 :
+ [Réplication de clusters de bases de données Amazon Aurora MySQL dans différentes Régions AWS](AuroraMySQL.Replication.CrossRegion.md)
+ [Migration des données d’une instance de base de données RDS for MySQL vers un cluster de bases de données Amazon Aurora MySQL à l’aide d’un réplica en lecture Aurora](AuroraMySQL.Migrating.RDSMySQL.Replica.md)