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.
# Référence des procédures stockées Aurora MySQL
Vous pouvez gérer votre cluster de bases de données Aurora MySQL en appelant des procédures stockées intégrées.
**Topics**
+ [Collecte et maintenance de l’historique global des statuts](mysql-stored-proc-gsh.md)
+ [Configuration, démarrage et arrêt de la réplication des journaux binaires (binlog)](mysql-stored-proc-replicating.md)
+ [Mettre fin à une session ou à une requête](mysql-stored-proc-ending.md)
+ [Répliquer des transactions à l'aide de GTIDs](mysql-stored-proc-gtid.md)
+ [Rotation des journaux de requêtes](mysql-stored-proc-logging.md)
+ [Configuration et affichage de la configuration du journal binaire](mysql-stored-proc-configuring.md)
# Collecte et maintenance de l’historique global des statuts
Amazon RDS fournit un ensemble de procédures qui prennent des instantanés des valeurs des variables d’état au fil du temps et les écrivent dans une table, ainsi que toutes les modifications intervenues depuis le dernier instantané. Cette infrastructure porte le nom d’historique global des statuts. Pour plus d’informations, consultez [Gestion de l’historique global des statuts](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.MySQL.CommonDBATasks.html#Appendix.MySQL.CommonDBATasks.GoSH).
Les procédures stockées suivantes gèrent la manière dont l’historique global des statuts est collecté et conservé.
**Topics**
+ [mysql.rds\$1collect\$1global\$1status\$1history](#mysql_rds_collect_global_status_history)
+ [mysql.rds\$1disable\$1gsh\$1collector](#mysql_rds_disable_gsh_collector)
+ [mysql.rds\$1disable\$1gsh\$1rotation](#mysql_rds_disable_gsh_rotation)
+ [mysql.rds\$1enable\$1gsh\$1collector](#mysql_rds_enable_gsh_collector)
+ [mysql.rds\$1enable\$1gsh\$1rotation](#mysql_rds_enable_gsh_rotation)
+ [mysql.rds\$1rotate\$1global\$1status\$1history](#mysql_rds_rotate_global_status_history)
+ [mysql.rds\$1set\$1gsh\$1collector](#mysql_rds_set_gsh_collector)
+ [mysql.rds\$1set\$1gsh\$1rotation](#mysql_rds_set_gsh_rotation)
## mysql.rds\$1collect\$1global\$1status\$1history
Prend un instantané sur demande pour l’historique global des statuts.
### Syntaxe
```
CALL mysql.rds_collect_global_status_history;
```
## mysql.rds\$1disable\$1gsh\$1collector
Désactive les instantanés pris par l’historique global des statuts.
### Syntaxe
```
CALL mysql.rds_disable_gsh_collector;
```
## mysql.rds\$1disable\$1gsh\$1rotation
Désactive la rotation de la table `mysql.global_status_history`.
### Syntaxe
```
CALL mysql.rds_disable_gsh_rotation;
```
## mysql.rds\$1enable\$1gsh\$1collector
Active l’historique global des statuts pour prendre des instantanés par défaut aux intervalles spécifiés par `rds_set_gsh_collector`.
### Syntaxe
```
CALL mysql.rds_enable_gsh_collector;
```
## mysql.rds\$1enable\$1gsh\$1rotation
Active la rotation du contenu de la table `mysql.global_status_history` en `mysql.global_status_history_old` aux intervalles spécifiés par `rds_set_gsh_rotation`.
### Syntaxe
```
CALL mysql.rds_enable_gsh_rotation;
```
## mysql.rds\$1rotate\$1global\$1status\$1history
Effectue une rotation du contenu de la table `mysql.global_status_history` en `mysql.global_status_history_old` à la demande.
### Syntaxe
```
CALL mysql.rds_rotate_global_status_history;
```
## mysql.rds\$1set\$1gsh\$1collector
Spécifie l’intervalle, en minutes, entre les instantanés pris par l’historique global des statuts.
### Syntaxe
```
CALL mysql.rds_set_gsh_collector(intervalPeriod);
```
### Paramètres
*intervalPeriod*
Intervalle, en minutes, entre les instantanés. La valeur par défaut est `5`.
## mysql.rds\$1set\$1gsh\$1rotation
Spécifie l’intervalle, en jours, entre deux rotations de la table `mysql.global_status_history`.
### Syntaxe
```
CALL mysql.rds_set_gsh_rotation(intervalPeriod);
```
### Paramètres
*intervalPeriod*
Intervalle, en jours, entre deux rotations de table. La valeur par défaut est `7`.
# 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)
# Mettre fin à une session ou à une requête
Les procédures stockées suivantes mettent fin à une session ou à une requête.
**Topics**
+ [mysql.rds\$1kill](#mysql_rds_kill)
+ [mysql.rds\$1kill\$1query](#mysql_rds_kill_query)
## mysql.rds\$1kill
Termine une connexion au serveur MySQL.
### Syntaxe
```
CALL mysql.rds_kill(processID);
```
### Paramètres
*processID*
Identité du thread de connexion à terminer.
### Notes d'utilisation
Chaque connexion au serveur MySQL s'exécute dans un thread distinct. Pour terminer une connexion, utilisez la procédure `mysql.rds_kill` et transmettez-lui l'ID de thread de cette connexion. Pour obtenir l'ID de thread, utilisez la commande MySQL [SHOW PROCESSLIST](https://dev.mysql.com/doc/refman/8.0/en/show-processlist.html).
### Exemples
L'exemple suivant termine une connexion avec l'ID de thread 4243 :
```
CALL mysql.rds_kill(4243);
```
## mysql.rds\$1kill\$1query
Termine une requête s'exécutant sur le serveur MySQL.
### Syntaxe
```
CALL mysql.rds_kill_query(processID);
```
### Paramètres
*processID*
Identité du processus ou du thread qui exécute la requête à terminer.
### Notes d’utilisation
Pour arrêter une requête en cours d'exécution sur le serveur MySQL, utilisez la procédure `mysql_rds_kill_query` et transmettez l'ID de connexion du thread qui exécute la requête. La procédure met alors fin à la connexion.
Pour obtenir l'ID, interrogez la table MySQL [INFORMATION\$1SCHEMA PROCESSLIST](https://dev.mysql.com/doc/refman/8.0/en/information-schema-processlist-table.html) ou utilisez la commande MySQL [SHOW PROCESSLIST](https://dev.mysql.com/doc/refman/8.0/en/show-processlist.html). La valeur figurant dans la colonne ID de `SHOW PROCESSLIST` ou `SELECT * FROM INFORMATION_SCHEMA.PROCESSLIST` est le *processID*.
### Exemples
L'exemple suivant arrête une requête dont l'ID de thread de requête est 230040 :
```
CALL mysql.rds_kill_query(230040);
```
# Répliquer des transactions à l'aide de GTIDs
Les procédures stockées suivantes contrôlent la manière dont les transactions sont répliquées à l'aide des identificateurs de transaction globaux (GTIDs) avec Aurora MySQL. Pour savoir comment utiliser la réplication basée sur GTIDs Aurora MySQL, consultez[Utilisation de la réplication basée sur des identifiants de transaction globaux (GTID)](mysql-replication-gtid.md).
**Topics**
+ [mysql.rds\$1assign\$1gtids\$1to\$1anonymous\$1transactions (Aurora MySQL version 3)](#mysql_assign_gtids_to_anonymous_transactions)
+ [mysql.rds\$1gtid\$1purged (Aurora MySQL version 3)](#mysql_rds_gtid_purged)
+ [mysql.rds\$1skip\$1transaction\$1with\$1gtid (Aurora MySQL versions 2 et 3)](#mysql_rds_skip_transaction_with_gtid)
+ [mysql.rds\$1start\$1replication\$1until\$1gtid (Aurora MySQL version 3)](#mysql_rds_start_replication_until_gtid)
## mysql.rds\$1assign\$1gtids\$1to\$1anonymous\$1transactions (Aurora MySQL version 3)
Configure l’option `ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS` de l’instruction `CHANGE REPLICATION SOURCE TO`. Elle force le canal de réplication à attribuer un GTID à des transactions répliquées qui n’en possèdent pas. Vous pouvez ainsi effectuer une réplication de journaux binaires à partir d’une source qui n’utilise pas la réplication GTID vers un réplica qui l’utilise. Pour plus d'informations, consultez les sections [CHANGE REPLICATION SOURCE TO Statement](https://dev.mysql.com/doc/refman/8.0/en/change-replication-source-to.html) et [Replication From a Source Without GTIDs to a Replica With GTIDs](https://dev.mysql.com/doc/refman/8.0/en/replication-gtids-assign-anon.html) dans le *manuel de référence MySQL*.
### Syntaxe
```
CALL mysql.rds_assign_gtids_to_anonymous_transactions(gtid_option);
```
### Parameters
*gtid\$1option*
Valeur de chaîne. Les valeurs autorisées sont : `OFF`, `LOCAL` ou un UUID spécifié.
### Notes d’utilisation
Cette procédure a le même effet que l’émission de l’instruction `CHANGE REPLICATION SOURCE TO ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS = gtid_option` dans Community MySQL.
Le GTID doit être converti en UUID `ON` *gtid\$1option* pour être défini sur un `LOCAL` UUID spécifique.
La valeur par défaut est `OFF`, ce qui signifie que la fonctionnalité n’est pas utilisée.
`LOCAL` attribue un GTID incluant le propre UUID du réplica (paramètre `server_uuid`).
La transmission d’un paramètre correspondant à un UUID attribue un GTID qui inclut l’UUID spécifié, tel que le paramètre `server_uuid` pour le serveur source de réplication.
### Exemples
Pour désactiver cette fonction :
```
mysql> call mysql.rds_assign_gtids_to_anonymous_transactions('OFF');
+-------------------------------------------------------------+
| Message |
+-------------------------------------------------------------+
| ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS has been set to: OFF |
+-------------------------------------------------------------+
1 row in set (0.07 sec)
```
Pour utiliser l’UUID du réplica :
```
mysql> call mysql.rds_assign_gtids_to_anonymous_transactions('LOCAL');
+---------------------------------------------------------------+
| Message |
+---------------------------------------------------------------+
| ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS has been set to: LOCAL |
+---------------------------------------------------------------+
1 row in set (0.07 sec)
```
Pour utiliser un UUID spécifié :
```
mysql> call mysql.rds_assign_gtids_to_anonymous_transactions('317a4760-f3dd-3b74-8e45-0615ed29de0e');
+----------------------------------------------------------------------------------------------+
| Message |
+----------------------------------------------------------------------------------------------+
| ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS has been set to: 317a4760-f3dd-3b74-8e45-0615ed29de0e |
+----------------------------------------------------------------------------------------------+
1 row in set (0.07 sec)
```
## mysql.rds\$1gtid\$1purged (Aurora MySQL version 3)
Définit la valeur globale de la variable système `gtid_purged` sur un ensemble d’identifiants de transaction globaux (GTID) donné. La variable `gtid_purged` système est un ensemble GTID qui comprend toutes les transactions qui ont été validées sur le serveur, mais qui n'existent dans aucun fichier journal binaire du serveur. GTIDs
Pour permettre la compatibilité avec MySQL 8.0, il existe deux manières de définir la valeur de `gtid_purged` :
+ Remplacez la valeur de `gtid_purged` par l’ensemble d’identifiants GTID que vous avez spécifié.
+ Ajoutez l’ensemble GTID que vous avez spécifié à l’ensemble d’identifiants GTID que `gtid_purged` contient déjà.
### Syntaxe
Pour remplacer la valeur de `gtid_purged` par l’ensemble d’identifiants GTID que vous avez spécifié :
```
CALL mysql.rds_gtid_purged (gtid_set);
```
Pour ajouter la valeur de `gtid_purged` à votre ensemble d’identifiants GTID que vous avez spécifié :
```
CALL mysql.rds_gtid_purged (+gtid_set);
```
### Parameters
*gtid\$1set*
La valeur de *gtid\$1set* doit être un sur-ensemble de la valeur actuelle de`gtid_purged`, et ne peut pas se croiser avec. `gtid_subtract(gtid_executed,gtid_purged)` En d'autres termes, le nouvel ensemble de GTID doit inclure ceux GTIDs qui y figuraient déjà`gtid_purged`, et ne peut pas inclure ceux `gtid_executed` qui n'ont pas encore été purgés. GTIDs Le *gtid\$1set* paramètre ne peut pas non plus inclure GTIDs celles figurant dans l'`gtid_owned`ensemble global, GTIDs pour les transactions en cours de traitement sur le serveur.
### Notes d’utilisation
L’utilisateur principal doit exécuter la procédure `mysql.rds_gtid_purged`.
Cette procédure est prise en charge pour Aurora MySQL versions 3.04 et ultérieures.
### Exemples
L’exemple suivant attribue le GTID `3E11FA47-71CA-11E1-9E33-C80AA9429562:23` à la variable globale `gtid_purged`.
```
CALL mysql.rds_gtid_purged('3E11FA47-71CA-11E1-9E33-C80AA9429562:23');
```
## mysql.rds\$1skip\$1transaction\$1with\$1gtid (Aurora MySQL versions 2 et 3)
Ignore la réplication d’une transaction avec l’identifiant de transaction global (GTID) spécifié sur une instance principale Aurora.
Vous pouvez utiliser cette procédure pour la reprise après sinistre lorsqu’il est avéré qu’une transaction GTID entraîne des problèmes. Utilisez cette procédure stockée pour ignorer la transaction problématique. Les transactions problématiques sont par exemple celles qui désactivent la réplication, suppriment des données importantes ou entraînent l’indisponibilité de l’instance de base de données.
### Syntaxe
```
CALL mysql.rds_skip_transaction_with_gtid (
gtid_to_skip
);
```
### Parameters
*gtid\$1to\$1skip*
GTID de la transaction de réplication à ignorer.
### Notes d’utilisation
L’utilisateur principal doit exécuter la procédure `mysql.rds_skip_transaction_with_gtid`.
Cette procédure est prise en charge pour Aurora MySQL versions 2 et 3.
### Exemples
L’exemple suivant ignore la réplication de la transaction avec le GTID `3E11FA47-71CA-11E1-9E33-C80AA9429562:23`.
```
CALL mysql.rds_skip_transaction_with_gtid('3E11FA47-71CA-11E1-9E33-C80AA9429562:23');
```
## mysql.rds\$1start\$1replication\$1until\$1gtid (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 immédiatement après l’identifiant de transaction global (GTID) spécifié.
### Syntaxe
```
CALL mysql.rds_start_replication_until_gtid(gtid);
```
### Parameters
*gtid*
Identifiant de transaction global (GTID) après lequel la réplication s’arrête.
### Notes d’utilisation
L’utilisateur principal doit exécuter la procédure `mysql.rds_start_replication_until_gtid`.
Cette procédure est prise en charge pour Aurora MySQL versions 3.04 et ultérieures.
La procédure `mysql.rds_start_replication_until_gtid` 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)
Lorsque le paramètre `gtid` spécifie une transaction ayant déjà été exécutée par le réplica, la réplication est immédiatement arrêtée.
### Exemples
L’exemple suivant lance la réplication et réplique les modifications jusqu’à ce que le GTID soit atteint `3E11FA47-71CA-11E1-9E33-C80AA9429562:23`.
```
call mysql.rds_start_replication_until_gtid('3E11FA47-71CA-11E1-9E33-C80AA9429562:23');
```
# Rotation des journaux de requêtes
Les procédures stockées suivantes effectuent la rotation des journaux MySQL vers des tables de sauvegarde. Pour plus d’informations, consultez [Fichiers journaux de base de données Aurora MySQL](USER_LogAccess.Concepts.MySQL.md).
**Topics**
+ [mysql.rds\$1rotate\$1general\$1log](#mysql_rds_rotate_general_log)
+ [mysql.rds\$1rotate\$1slow\$1log](#mysql_rds_rotate_slow_log)
## mysql.rds\$1rotate\$1general\$1log
Convertit la table `mysql.general_log` en table de sauvegarde.
### Syntaxe
```
CALL mysql.rds_rotate_general_log;
```
### Notes d’utilisation
Vous pouvez convertir la table `mysql.general_log` en table de sauvegarde en appelant la procédure `mysql.rds_rotate_general_log`. Lors de la rotation des tables de journaux, la table de journal actuelle est copiée vers une table de journal de sauvegarde et les entrées de la table de journal actuelle sont supprimées. Si la table du journal de sauvegarde existe déjà, elle est supprimée avant que la table du journal active ne soit copiée dans la sauvegarde. Si besoin, vous pouvez interroger la table de journal de sauvegarde. La table de journal de sauvegarde de la table `mysql.general_log` est nommée `mysql.general_log_backup`.
Vous ne pouvez exécuter cette procédure que lorsque le paramètre `log_output` est défini sur `TABLE`.
## mysql.rds\$1rotate\$1slow\$1log
Convertit la table `mysql.slow_log` en table de sauvegarde.
### Syntaxe
```
CALL mysql.rds_rotate_slow_log;
```
### Notes d’utilisation
Vous pouvez convertir la table `mysql.slow_log` en table de sauvegarde en appelant la procédure `mysql.rds_rotate_slow_log`. Lors de la rotation des tables de journaux, la table de journal actuelle est copiée vers une table de journal de sauvegarde et les entrées de la table de journal actuelle sont supprimées. Si la table du journal de sauvegarde existe déjà, elle est supprimée avant que la table du journal active ne soit copiée dans la sauvegarde.
Si besoin, vous pouvez interroger la table de journal de sauvegarde. La table de journal de sauvegarde de la table `mysql.slow_log` est nommée `mysql.slow_log_backup`.
# Configuration et affichage de la configuration du journal binaire
Les procédures stockées suivantes définissent et affichent les paramètres de configuration, tels que la conservation des fichiers journaux binaires.
**Topics**
+ [mysql.rds\$1set\$1configuration](#mysql_rds_set_configuration)
+ [mysql.rds\$1show\$1configuration](#mysql_rds_show_configuration)
## mysql.rds\$1set\$1configuration
Spécifie le nombre d’heures pendant lequel les journaux binaires doivent être conservés ou le nombre de secondes pendant lequel retarder la réplication.
### Syntaxe
```
CALL mysql.rds_set_configuration(name,value);
```
### Parameters
*name*
Nom du paramètre de configuration à définir.
*value*
Valeur du paramètre de configuration.
### Notes d’utilisation
La procédure `mysql.rds_set_configuration` prend en charge des paramètres de configuration suivants :
+ [nombre d’heures de conservation du journal binaire](#mysql_rds_set_configuration-usage-notes.binlog-retention-hours)
Les paramètres de configuration sont stockés de manière permanente et survivent à tout redémarrage ou basculement d’une instance de base de données.
#### nombre d’heures de conservation du journal binaire
Le paramètre `binlog retention hours` est utilisé pour spécifier le nombre d’heures de rétention des fichiers journaux binaires. Amazon Aurora purge normalement un journal binaire dès que possible, mais il se peut que le journal binaire soit encore requis pour la réplication avec une base de données MySQL extérieure à Aurora.
La valeur par défaut de `binlog retention hours` est `NULL`. Pour Aurora MySQL, `NULL` signifie que les journaux binaires sont nettoyés lentement. Les journaux binaires Aurora MySQL peuvent rester dans le système pendant un certain temps, qui ne dépasse généralement pas un jour.
Pour spécifier le nombre d’heures pendant lesquelles conserver les journaux binaires sur un cluster de bases de données, utilisez la procédure stockée `mysql.rds_set_configuration` et spécifiez une période suffisamment longue pour que la réplication se produise, comme illustré dans l’exemple suivant.
`call mysql.rds_set_configuration('binlog retention hours', 24);`
**Note**
Vous ne pouvez pas utiliser la valeur `0` pour `binlog retention hours`.
Pour des clusters de bases de données Aurora MySQL versions 2.11.0 et ultérieures et version 3, la valeur `binlog retention hours` maximale est 2 160 (90 jours).
Après avoir défini la période de rétention, surveillez l’utilisation du stockage de l’instance de base de données afin de garantir que les journaux binaires conservés n’utilisent pas un espace de stockage trop grand.
## mysql.rds\$1show\$1configuration
Nombre d’heures pendant lequel les journaux binaires sont conservés.
### Syntaxe
```
CALL mysql.rds_show_configuration;
```
### Notes d’utilisation
Pour vérifier le nombre d’heures pendant lequel Amazon RDS conserve les journaux binaires, utilisez la procédure stockée `mysql.rds_show_configuration`.
### Exemples
L’exemple suivant affiche la période de rétention :
```
call mysql.rds_show_configuration;
name value description
binlog retention hours 24 binlog retention hours specifies the duration in hours before binary logs are automatically deleted.
```