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.
# Amazon RDS for MariaDB
Amazon RDS prend en charge plusieurs versions de MariaDB pour les instances de base de données. Pour des informations complètes sur les versions prises en charge, consultez [Versions de MariaDB sur Amazon RDS](MariaDB.Concepts.VersionMgmt.md).
Pour créer une instance de base de données MariaDB, utilisez les interfaces ou les outils de gestion Amazon RDS. Vous pouvez ensuite utiliser les outils Amazon RDS pour effectuer des actions de gestion pour l'instance de base de données. Ces actions incluent :
+ Reconfiguration ou redimensionnement de l'instance de base de données
+ Autorisation des connexions à l'instance de base de données
+ Création et restauration à partir de sauvegardes ou d'instantanés
+ Création de secondaires Multi-AZ
+ Création de réplicas en lecture
+ Surveillance des performances de votre instance de base de données
Pour stocker les données de votre instance de base de données et y accéder, utilisez les applications et les utilitaires MariaDB standard.
MariaDB est disponible dans toutes les Régions AWS. Pour plus d’informations sur Régions AWS, consultez [Régions, zones de disponibilité et zones locales ](Concepts.RegionsAndAvailabilityZones.md).
Vous pouvez utiliser Amazon RDS for MariaDB afin de développer des applications conformes à la loi HIPAA. Vous pouvez stocker les informations relatives à la santé, y compris les données de santé protégées (PHI, Protected Health Information), selon les termes d'un accord de partenariat (BAA, Business Associate Agreement) avec AWS. Pour plus d'informations, consultez [Conformité à la loi HIPAA](https://aws.amazon.com/compliance/hipaa-compliance/). AWS Les services concernés par le programme de conformité ont été intégralement évalués par un auditeur tiers et donnent lieu à une certification, une attestation de conformité ou une autorisation d'opérer (ATO, Authorization to operate). Pour plus d’informations, consultez [Services AWS concernés par le programme de conformité](https://aws.amazon.com/compliance/services-in-scope/).
Avant de créer une instance de base de données, effectuez les étapes de la section [Configuration de votre environnement Amazon RDS](CHAP_SettingUp.md). Lorsque vous créez une instance de base de données, l'utilisateur principal RDS obtient des privilèges d'administrateur de base de données (avec certaines restrictions). Utilisez ce compte pour des tâches administratives telles que la création de comptes de base de données supplémentaires.
Vous pouvez créer ce qui suit :
+ Instances DB
+ Instantanés de base de données
+ Restaurations à un instant donné
+ Sauvegardes automatiques
+ Sauvegardes manuelles
Vous pouvez utiliser des instances de base de données exécutant MariaDB dans un cloud privé virtuel (VPC) basé sur Amazon VPC. Vous pouvez également ajouter des fonctionnalités à votre instance de base de données MariaDB en activant diverses options. Amazon RDS prend en charge les déploiements multi-AZ pour MariaDB comme solution de basculement haute disponibilité.
**Important**
Pour offrir une expérience de service géré, Amazon RDS ne fournit pas l’accès shell aux instances de base de données. Il restreint également l’accès à certaines procédures système et tables qui nécessitent des privilèges avancés. Vous pouvez accéder à votre base de données en utilisant des client SQL standard tels que le client mysql. Toutefois, vous ne pouvez pas accéder directement à l’hôte en utilisant Telnet ou Secure Shell (SSH).
**Topics**
+ [
# Prise en charge des fonctions MariaDB sur Amazon RDS
](MariaDB.Concepts.FeatureSupport.md)
+ [
# Versions de MariaDB sur Amazon RDS
](MariaDB.Concepts.VersionMgmt.md)
+ [
# Connexion à votre instance de base de données MariaDB
](USER_ConnectToMariaDBInstance.md)
+ [
# Sécurisation des connexions d'instance de base de données MariaDB
](securing-mariadb-connections.md)
+ [
# Amélioration des performances des requêtes pour RDS for MariaDB avec Lectures optimisées pour Amazon RDS
](rds-optimized-reads-mariadb.md)
+ [
# Amélioration des performances d'écriture avec Écritures optimisées pour Amazon RDS for MariaDB
](rds-optimized-writes-mariadb.md)
+ [
# Mises à niveau du moteur de base de données MariaDB
](USER_UpgradeDBInstance.MariaDB.md)
+ [
# Mise à niveau d’une version du moteur d’instantané de base de données MariaDB
](mariadb-upgrade-snapshot.md)
+ [
# Importation de données dans une instance de base de données Amazon RDS for MariaDB
](MariaDB.Procedural.Importing.md)
+ [
# Utilisation de la réplication MariaDB dans Amazon RDS
](USER_MariaDB.Replication.md)
+ [
# Options pour le moteur de base de données MariaDB
](Appendix.MariaDB.Options.md)
+ [
# Paramètres pour MariaDB
](Appendix.MariaDB.Parameters.md)
+ [
# Migration de données d’un instantané de base de données MySQL vers une instance de base de données MariaDB
](USER_Migrate_MariaDB.md)
+ [
# Référence MariaDB sur SQL Amazon RDS
](Appendix.MariaDB.SQLRef.md)
+ [
# Fuseau horaire local pour les instances de base de données MariaDB
](MariaDB.Concepts.LocalTimeZone.md)
+ [
# Limites et problèmes connus pour RDS for MariaDB
](CHAP_MariaDB.Limitations.md)
# Prise en charge des fonctions MariaDB sur Amazon RDS
RDS for MariaDB prend en charge la plupart des fonctionnalités et des capacités de MariaDB. Certaines fonctions peuvent avoir une prise en charge limitée ou des privilèges restreints.
Vous pouvez filtrer les nouvelles fonctions de Amazon RDS sur la page [Nouveautés en matière de base de données](https://aws.amazon.com/about-aws/whats-new/database/). Pour **Produits**, choisissez **Amazon RDS**. Ensuite, effectuez une recherche à l’aide de mots clés tels que **MariaDB 2023**.
**Note**
Les listes suivantes ne sont pas exhaustives.
Pour plus d’informations sur la prise en charge des fonctionnalités MariaDB sur Amazon RDS, consultez les rubriques suivantes.
**Rubriques**
+ [Moteurs de stockage pris en charge pour MariaDB sur Amazon RDS](MariaDB.Concepts.Storage.md)
+ [Préparation du cache pour MariaDB sur Amazon RDS](MariaDB.Concepts.XtraDBCacheWarming.md)
+ [Fonctions MariaDB non prises en charge par Amazon RDS](MariaDB.Concepts.FeatureNonSupport.md)
## Prise en charge des fonctionnalités d’Amazon RDS for MariaDB pour les versions majeures de MariaDB
Dans les sections suivantes, vous trouverez des informations sur les fonctions MariaDB prises en charge sur les versions majeures d'Amazon RDS for MariaDB :
**Topics**
+ [
### Prise en charge de MariaDB 11.8 sur Amazon RDS
](#MariaDB.Concepts.FeatureSupport.11-8)
+ [
### Prise en charge de MariaDB 11.4 sur Amazon RDS
](#MariaDB.Concepts.FeatureSupport.11-4)
+ [
### Prise en charge de MariaDB 10.11 sur Amazon RDS
](#MariaDB.Concepts.FeatureSupport.10-11)
+ [
### Prise en charge de MariaDB 10.6 sur Amazon RDS
](#MariaDB.Concepts.FeatureSupport.10-6)
+ [
### Prise en charge de MariaDB 10.5 sur Amazon RDS
](#MariaDB.Concepts.FeatureSupport.10-5)
+ [
### Prise en charge de MariaDB 10.4 sur Amazon RDS
](#MariaDB.Concepts.FeatureSupport.10-4)
Pour plus d’informations sur les versions mineures de Amazon RDS for MariaDB prises en charge, consultez [Versions de MariaDB sur Amazon RDS](MariaDB.Concepts.VersionMgmt.md).
### Prise en charge de MariaDB 11.8 sur Amazon RDS
Amazon RDS prend en charge les nouvelles fonctionnalités suivantes pour vos instances de base de données exécutant MariaDB version 11.8 ou versions ultérieures.
**Note**
Dans MariaDB 11.8, la valeur par défaut `require_secure_transport` pour est `1` now, ce qui nécessite des connexions sécurisées. SSL/TLS Défini sur `0` si des connexions non sécurisées sont nécessaires.
+ **Nouvelle valeur par défaut pour le paramètre** : la valeur par défaut du paramètre `require_secure_transport` est passée de `0` à `1`, ce qui renforce les connexions de transport sécurisées par défaut. Pour de plus amples informations, veuillez consulter [Exiger toutes SSL/TLS les connexions à une instance de base de données MariaDB sur Amazon RDS](mariadb-ssl-connections.require-ssl.md).
+ **Support vectoriel** : vous pouvez utiliser le vecteur MariaDB pour stocker et rechercher des vecteurs générés par l’IA directement dans MariaDB. Cette fonctionnalité introduit les variables système suivantes :
+ La variable [https://mariadb.com/docs/server/reference/sql-structure/vectors/vector-system-variables#mhnsw_default_distance](https://mariadb.com/docs/server/reference/sql-structure/vectors/vector-system-variables#mhnsw_default_distance) spécifie la métrique de distance par défaut pour l’indexation vectorielle MHNSW.
+ La variable [https://mariadb.com/docs/server/reference/sql-structure/vectors/vector-system-variables#mhnsw_default_m](https://mariadb.com/docs/server/reference/sql-structure/vectors/vector-system-variables#mhnsw_default_m) définit la valeur par défaut du paramètre `M` dans l’indexation vectorielle MHNSW.
+ La variable [https://mariadb.com/docs/server/reference/sql-structure/vectors/vector-system-variables#mhnsw_ef_search](https://mariadb.com/docs/server/reference/sql-structure/vectors/vector-system-variables#mhnsw_ef_search) définit le nombre minimal de résultats candidats pour les recherches par index vectoriel.
+ La variable [https://mariadb.com/docs/server/reference/sql-structure/vectors/vector-system-variables#mhnsw_max_cache_size](https://mariadb.com/docs/server/reference/sql-structure/vectors/vector-system-variables#mhnsw_max_cache_size) définit la limite supérieure pour un cache d’index vectoriel MHNSW.
+ **Limites de taille de fichiers temporaires** : vous pouvez désormais limiter la taille des tables et fichiers temporaires sur disque créés à l’aide de deux variables système disponibles dans le groupe de paramètres RDS MariaDB 11.8 :
+ La variable [https://mariadb.com/docs/server/security/limiting-size-of-created-disk-temporary-files-and-tables/max_tmp_session_space_usage-system-variable](https://mariadb.com/docs/server/security/limiting-size-of-created-disk-temporary-files-and-tables/max_tmp_session_space_usage-system-variable) limite l’espace temporaire alloué par utilisateur.
+ La variable [https://mariadb.com/docs/server/security/limiting-size-of-created-disk-temporary-files-and-tables/max_tmp_total_space_usage-system-variable](https://mariadb.com/docs/server/security/limiting-size-of-created-disk-temporary-files-and-tables/max_tmp_total_space_usage-system-variable) limite l’espace temporaire alloué pour tous les utilisateurs.
+ **Gestion de l’espace disque logique temporaire** : le tablespace temporaire stocke les tables temporaires et s’agrandit au fur et à mesure que des données sont ajoutées. Lorsque des tables temporaires sont supprimées, l’espace n’est pas automatiquement récupéré. Vous pouvez utiliser la procédure [mysql.rds\$1execute\$1operation](mysql_rds_execute_operation.md) pour réduire le tablespace temporaire et récupérer de l’espace disque.
Pour accéder à la liste complète des fonctionnalités de MariaDB 11.8 ainsi qu’à la documentation associée, consultez [Modifications et améliorations apportées à MariaDB 11.8](https://mariadb.com/kb/en/changes-improvements-in-mariadb-11-8/) et [Notes de mise à jour – Série MariaDB 11.8](https://mariadb.com/kb/en/release-notes-mariadb-11-8-series/) sur le site web de MariaDB.
Pour obtenir la liste des fonctions non prises en charge, consultez [Fonctions MariaDB non prises en charge par Amazon RDS](MariaDB.Concepts.FeatureNonSupport.md).
### Prise en charge de MariaDB 11.4 sur Amazon RDS
Amazon RDS prend en charge les nouvelles fonctionnalités suivantes pour vos instances de base de données exécutant MariaDB version 11.4 ou versions ultérieures.
+ **Bibliothèque cryptographique** — RDS pour MariaDB a remplacé AWS Libcrypto OpenSSL par (), qui est certifié FIPS 140-3.AWS-LC
+ **Plugin Simple Password Check** : vous pouvez utiliser le plugin MariaDB [Simple Password Check](https://mariadb.com/kb/en/simple-password-check-plugin/) pour vérifier si un mot de passe contient au moins un certain nombre de caractères d’un type spécifique. Pour de plus amples informations, veuillez consulter [Utilisation des plugins de validation de mot de passe pour RDS for MariaDB](MariaDB.Concepts.PasswordValidationPlugins.md).
+ **Plugin Cracklib Password Check** : vous pouvez utiliser le plugin MariaDB [Cracklib Password Check](https://mariadb.com/kb/en/cracklib-password-check-plugin/) pour vérifier la résistance des nouveaux mots de passe. Pour de plus amples informations, veuillez consulter [Utilisation des plugins de validation de mot de passe pour RDS for MariaDB](MariaDB.Concepts.PasswordValidationPlugins.md).
+ **Améliorations InnoDB** : ces améliorations incluent les éléments suivants :
+ La mémoire tampon des modifications a été supprimée. Pour plus d’informations, consultez [Mise en mémoire tampon des modifications InnoDB](https://mariadb.com/kb/en/innodb-change-buffering/).
+ La défragmentation InnoDB a été supprimée. Pour plus d’informations, consultez [Défragmentation InnoDB](https://mariadb.com/kb/en/defragmenting-innodb-tablespaces/#innodb-defragmentation).
+ **Nouveau privilège** : l’utilisateur administrateur dispose désormais également du privilège `SHOW CREATE ROUTINE`. Ce privilège permet au bénéficiaire de consulter l’instruction de définition `SHOW CREATE` d’une routine appartenant à un autre utilisateur. Pour plus d’informations, consultez [Privilèges de base de données](https://mariadb.com/kb/en/grant/#database-privileges).
+ **Amélioration de la réplication** : les instances de base de données MariaDB version 11.4 prennent en charge l’indexation des journaux binaires. Vous pouvez créer un index GTID pour chaque fichier binlog. Ces index améliorent les performances de réplication en réduisant le temps nécessaire pour localiser un GTID. Pour plus d’informations, consultez [Indexation binlog](https://mariadb.com/kb/en/gtid/#binlog-indexing).
+ **Paramètres déconseillés ou supprimés** : les paramètres suivants sont devenus obsolètes ou ont été supprimés pour les instances de base de données MariaDB version 11.4 :
+ `engine_condition_pushdown` est supprimé de [optimizer\$1switch](https://mariadb.com/kb/en/optimizer-switch/)
+ [innodb\$1change\$1buffer\$1max\$1size](https://mariadb.com/kb/en/innodb-system-variables/#innodb_change_buffer_max_size)
+ [innodb\$1defragment](https://mariadb.com/kb/en/innodb-system-variables/#innodb_defragment)
+ `TLSv1.0` et `TLSv1.1` sont supprimés de [tls\$1version](https://mariadb.com/kb/en/ssltls-system-variables/#tls_version)
+ **Nouvelles valeurs par défaut pour un paramètre** : la valeur par défaut du paramètre [innodb\$1undo\$1tablespaces](https://mariadb.com/kb/en/innodb-system-variables/#innodb_undo_tablespaces) est passée de `0` à `3`.
+ **Nouvelles valeurs valides pour les paramètres** : les paramètres suivants ont de nouvelles valeurs valides pour les instances de base de données MariaDB version 11.4 :
+ Les valeurs valides pour le paramètre [binlog\$1row\$1image](https://mariadb.com/kb/en/replication-and-binary-log-system-variables/#binlog_row_image) incluent désormais `FULL_NODUP`.
+ Les valeurs valides pour le paramètre [OLD\$1MODE](https://mariadb.com/kb/en/old-mode/) incluent désormais `NO_NULL_COLLATION_IDS`.
+ **Nouveaux paramètres** : les paramètres suivants sont nouveaux pour les instances de base de données MariaDB version 11.4 :
+ Le paramètre [transaction\$1isolation](https://mariadb.com/kb/en/server-system-variables/#transaction_isolation) remplace le paramètre [tx\$1isolation](https://mariadb.com/kb/en/server-system-variables/#tx_isolation).
+ Le paramètre [transaction\$1read\$1only](https://mariadb.com/kb/en/server-system-variables/#transaction_read_only) remplace le paramètre [tx\$1read\$1only](https://mariadb.com/kb/en/server-system-variables/#tx_read_only).
+ Le paramètre [block\$1encryption\$1mode définit le mode](https://mariadb.com/kb/en/server-system-variables/#block_encryption_mode) de chiffrement de bloc par défaut pour les fonctions [AES\$1ENCRYPT()](https://mariadb.com/kb/en/aes_encrypt/) et [AES\$1DECRYPT()](https://mariadb.com/kb/en/aes_decrypt/).
+ Le paramètre [character\$1set\$1collations](https://mariadb.com/kb/en/server-system-variables/#character_set_collations) définit les remplacements pour les classements par défaut des jeux de caractères.
+ Les paramètres [binlog\$1gtid\$1index](https://mariadb.com/kb/en/system-versioned-tables/#binlog_gtid_index), [binlog\$1gtid\$1index\$1page\$1size](https://mariadb.com/kb/en/system-versioned-tables/#binlog_gtid_index_page_size) et [binlog\$1gtid\$1index\$1span\$1min](https://mariadb.com/kb/en/system-versioned-tables/#binlog_gtid_index_span_min) définissent les propriétés de l’index GTID binlog. Pour plus d’informations, consultez [Indexation binlog](https://mariadb.com/kb/en/gtid/#binlog-indexing).
Pour accéder à la liste complète des fonctionnalités de MariaDB 11.4 ainsi qu’à la documentation associée, consultez [Modifications et améliorations apportées à MariaDB 11.4](https://mariadb.com/kb/en/changes-improvements-in-mariadb-11-4/) et [Notes de mise à jour – Série MariaDB 11.4](https://mariadb.com/kb/en/release-notes-mariadb-11-4-series/) sur le site web de MariaDB.
Pour obtenir la liste des fonctions non prises en charge, consultez [Fonctions MariaDB non prises en charge par Amazon RDS](MariaDB.Concepts.FeatureNonSupport.md).
### Prise en charge de MariaDB 10.11 sur Amazon RDS
Amazon RDS prend en charge les nouvelles fonctionnalités suivantes pour vos instances de base de données exécutant MariaDB version 10.11 ou versions ultérieures.
+ **Plug-in Password Reuse Check** : vous pouvez utiliser le plug-in MariaDB Password Reuse Check pour empêcher les utilisateurs de réutiliser les mots de passe et pour définir la période de conservation des mots de passe. Pour plus d'informations, consultez [Plug-in Password Reuse Check](https://mariadb.com/kb/en/password-reuse-check-plugin/) (langue française non garantie).
+ **Autorisation GRANT TO PUBLIC** : vous pouvez accorder des privilèges à tous les utilisateurs qui disposent d'un accès à votre serveur. Pour plus d'informations, consultez [GRANT TO PUBLIC](https://mariadb.com/kb/en/grant/#to-public) (langue française non garantie).
+ **Séparation des privilèges SUPER et READ ONLY ADMIN** : vous pouvez supprimer les privilèges READ ONLY ADMIN de tous les utilisateurs, même des utilisateurs qui bénéficiaient auparavant de privilèges SUPER.
+ **Sécurité** : vous pouvez maintenant définir l'option `--ssl` par défaut pour votre client MariaDB. MariaDB ne désactive plus silencieusement SSL si la configuration est incorrecte.
+ **Commandes et fonctions SQL** : vous pouvez désormais utiliser la commande `SHOW ANALYZE FORMAT=JSON` et les fonctions `ROW_NUMBER`, `SFORMAT` et `RANDOM_BYTES`. `SFORMAT` autorise le formatage de chaîne et est activé par défaut. Vous pouvez convertir une partition en table et une table en partition en une seule commande. Il existe également plusieurs améliorations concernant les fonctions `JSON_*()`. Les fonctions `DES_ENCRYPT` et `DES_DECRYPT` ont été déconseillées pour les versions 10.10 et ultérieures. Pour plus d'informations, consultez [SFORMAT](https://mariadb.com/kb/en/sformat/).
+ **Améliorations InnoDB** : ces améliorations incluent les éléments suivants :
+ Améliorations des performances dans le journal redo afin de réduire l'amplification d'écriture et améliorer la simultanéité.
+ Possibilité de modifier l'espace de table d'annulation sans réinitialiser le répertoire de données. Cette amélioration réduit le surcoût du plan de contrôle. Elle requiert un redémarrage, mais pas la réinitialisation après la modification de l'espace de table d'annulation.
+ Prise en charge de `CHECK TABLE … EXTENDED` et des index décroissants en interne.
+ Améliorations apportées à l'insertion en vrac.
+ **Modifications du journal binaire** : ces modifications incluent les éléments suivants :
+ Journalisation `ALTER` en deux phases pour réduire la latence de réplication. Le paramètre `binlog_alter_two_phase` est désactivé par défaut, mais peut être activé par le biais de groupes de paramètres.
+ Journalisation `explicit_defaults_for_timestamp`.
+ Plus de journalisation `INCIDENT_EVENT` si la transaction peut être annulée en toute sécurité.
+ **Amélioration**s de la **réplication** : les instances de base de données MariaDB version 10.11 utilisent la réplication GTID par défaut si le maître la prend en charge. De plus, `Seconds_Behind_Master` est plus précis.
+ **Clients** : vous pouvez utiliser de nouvelles options de ligne de commande pour `mysqlbinglog` et `mariadb-dump`. Vous pouvez utiliser `mariadb-dump` pour vider et restaurer les données d'historique.
+ **Gestion des versions du système** : vous pouvez modifier l'historique. MariaDB crée automatiquement de nouvelles partitions.
+ **DDL atomique** : `CREATE OR REPLACE` est désormais atomique. Soit l'instruction réussit, soit elle est complètement inversée.
+ **Écriture du journal redo** : le journal redo écrit de manière asynchrone.
+ **Fonctions stockées** : les fonctions stockées prennent désormais en charge les mêmes paramètres `IN`, `OUT` et `INOUT` que dans les procédures stockées.
+ **Paramètres déconseillés ou supprimés** : les paramètres suivants sont devenus obsolètes ou ont été supprimés pour les instances de base de données MariaDB version 10.11 :
+ [innodb\$1change\$1buffering](https://mariadb.com/kb/en/innodb-system-variables/#innodb_change_buffering)
+ [innodb\$1disallow\$1writes](https://mariadb.com/kb/en/innodb-system-variables/#innodb_disallow_writes)
+ [innodb\$1log\$1write\$1ahead\$1size](https://mariadb.com/kb/en/innodb-system-variables/#innodb_log_write_ahead_size)
+ [innodb\$1prefix\$1index\$1cluster\$1optimization](https://mariadb.com/kb/en/innodb-system-variables/#innodb_prefix_index_cluster_optimization)
+ [keep\$1files\$1on\$1create](https://mariadb.com/kb/en/server-system-variables/#keep_files_on_create)
+ [old](https://mariadb.com/kb/en/server-system-variables/#old)
+ **Paramètres dynamiques** : les paramètres suivants sont désormais dynamiques pour les instances de base de données MariaDB version 10.11 :
+ [innodb\$1log\$1file\$1size](https://mariadb.com/kb/en/innodb-system-variables/#innodb_log_file_size)
+ [innodb\$1write\$1io\$1threads](https://mariadb.com/kb/en/innodb-system-variables/#innodb_write_io_threads)
+ [innodb\$1read\$1io\$1threads](https://mariadb.com/kb/en/innodb-system-variables/#innodb_read_io_threads)
+ **Nouvelles valeurs par défaut pour les paramètres** : les paramètres suivants ont de nouvelles valeurs par défaut pour les instances de base de données MariaDB version 10.11 :
+ La valeur par défaut du paramètre [explicit\$1defaults\$1for\$1timestamp](https://mariadb.com/kb/en/server-system-variables/#explicit_defaults_for_timestamp) est passée de `OFF` à `ON`.
+ La valeur par défaut du paramètre [optimizer\$1prune\$1level](https://mariadb.com/kb/en/server-system-variables/#optimizer_prune_level) est passée de `1` à `2`.
+ **Nouvelles valeurs valides pour les paramètres** : les paramètres suivants ont de nouvelles valeurs valides pour les instances de base de données MariaDB version 10.11 :
+ Les valeurs valides pour le paramètre [old](https://mariadb.com/kb/en/server-system-variables/#old) ont été fusionnées à celles du paramètre [old\$1mode](https://mariadb.com/kb/en/server-system-variables/#old_mode).
+ Les valeurs valides pour le paramètre [histogram\$1type](https://mariadb.com/kb/en/server-system-variables/#histogram_type) incluent désormais `JSON_HB`.
+ La plage des valeurs valides pour le paramètre [innodb\$1log\$1buffer\$1size](https://mariadb.com/kb/en/innodb-system-variables/#innodb_log_buffer_size) est maintenant de `262144` à `4294967295` (de 256 Ko à 4 096 Mo).
+ La plage des valeurs valides pour le paramètre [innodb\$1log\$1file\$1size](https://mariadb.com/kb/en/innodb-system-variables/#innodb_log_file_size) est maintenant de `4194304` à `512GB` (de 4 Mo à 512 Go).
+ Les valeurs valides pour le paramètre [optimizer\$1prune\$1level](https://mariadb.com/kb/en/server-system-variables/#optimizer_prune_level) incluent désormais `2`.
+ **Nouveaux paramètres** : les paramètres suivants sont nouveaux pour les instances de base de données MariaDB version 10.11 :
+ Le paramètre [binlog\$1alter\$1two\$1phase](https://mariadb.com/kb/en/replication-and-binary-log-system-variables//#binlog_alter_two_phase) peut améliorer les performances de réplication.
+ Le paramètre [log\$1slow\$1min\$1examined\$1row\$1limit](https://mariadb.com/kb/en/server-system-variables/#log_slow_min_examined_row_limit) peut améliorer les performances.
+ Le paramètre [log\$1slow\$1query](https://mariadb.com/kb/en/server-system-variables/#log_slow_query) et le paramètre [log\$1slow\$1query\$1file](https://mariadb.com/kb/en/server-system-variables/#log_slow_query_file) sont des alias pour `slow_query_log` et `slow_query_log_file`, respectivement.
+ [optimizer\$1extra\$1pruning\$1depth](https://mariadb.com/kb/en/server-system-variables/#optimizer_extra_pruning_depth)
+ [system\$1versioning\$1insert\$1history](https://mariadb.com/kb/en/system-versioned-tables/#system_versioning_insert_history)
Pour accéder à la liste complète des fonctionnalités de MariaDB 10.11 ainsi qu’à la documentation associée, consultez [Modifications et améliorations apportées à MariaDB 10.11](https://mariadb.com/kb/en/changes-improvements-in-mariadb-1011/) et [Notes de mise à jour – Série MariaDB 10.11](https://mariadb.com/kb/en/release-notes-mariadb-1011-series/) sur le site web de MariaDB.
Pour obtenir la liste des fonctions non prises en charge, consultez [Fonctions MariaDB non prises en charge par Amazon RDS](MariaDB.Concepts.FeatureNonSupport.md).
### Prise en charge de MariaDB 10.6 sur Amazon RDS
Amazon RDS prend en charge les nouvelles fonctions suivantes pour vos instances de base de données exécutant MariaDB version 10.6 ou versions ultérieures :
+ **MyRocks moteur de stockage** : vous pouvez utiliser le moteur MyRocks de stockage avec RDS pour MariaDB afin d'optimiser la consommation de stockage de vos applications Web hautes performances et gourmandes en écriture. Pour plus d’informations, consultez [Moteurs de stockage pris en charge pour MariaDB sur Amazon RDS](MariaDB.Concepts.Storage.md) et [MyRocks](https://mariadb.com/kb/en/myrocks/).
+ **Gestion des identités et des accès AWS Authentification de base de données (IAM)** — Vous pouvez utiliser l'authentification de base de données IAM pour une meilleure sécurité et une gestion centralisée des connexions à vos instances de base de données MariaDB. Pour de plus amples informations, veuillez consulter [Authentification de base de données IAMpour MariaDB, MySQL et PostgreSQL](UsingWithRDS.IAMDBAuth.md).
+ **Options de surclassement** : vous pouvez désormais effectuer une mise à niveau vers RDS for MariaDB version 10.6 depuis n'importe quelle version majeure antérieure (10.3, 10.4 et 10.5). Vous pouvez également restaurer un instantané d'une instance de base de données MySQL 5.6 ou 5.7 existante sur une instance MariaDB 10.6. Pour de plus amples informations, veuillez consulter [Mises à niveau du moteur de base de données MariaDB](USER_UpgradeDBInstance.MariaDB.md).
+ **Réplication retardée**: vous pouvez désormais définir une période configurable pour laquelle un réplica en lecture est en retard par rapport à la base de données source. Dans une configuration de réplication MariaDB standard, le délai de réplication entre la source et le réplica est minime. Avec la réplication différée, vous pouvez définir un délai intentionnel comme stratégie de reprise après sinistre. Pour de plus amples informations, veuillez consulter [Configuration de la réplication différée avec MariaDB](USER_MariaDB.Replication.ReadReplicas.DelayReplication.md).
+ ** PL/SQL Compatibilité avec Oracle** : en utilisant RDS pour MariaDB version 10.6, vous pouvez migrer plus facilement vos anciennes applications Oracle vers Amazon RDS. Pour plus d’informations, consultez [SQL\$1MODE=ORACLE](https://mariadb.com/kb/en/sql_modeoracle/).
+ **DDL atomique** : vos instructions DDL (Dynamic Data Language) peuvent être relativement sécurisées avec RDS for MariaDB version 10.6. `CREATE TABLE`, `ALTER TABLE`, `RENAME TABLE`, `DROP TABLE`, `DROP DATABASE` et les instructions DDL associées sont désormais atomiques. Soit l'instruction réussit, soit elle est complètement inversée. Pour plus d’informations, consultez [DDL atomique](https://mariadb.com/kb/en/atomic-ddl/).
+ **Autres améliorations** : ces améliorations incluent une fonction `JSON_TABLE` pour transformer les données JSON au format relationnel dans SQL, et une charge plus rapide des données de table vides avec Innodb. Ils incluent également de nouveaux `sys_schema` à des fins d'analyse et de dépannage, d'amélioration de l'optimiseur pour ignorer les index inutilisés et d'amélioration des performances. Pour en savoir plus, consultez [JSON\$1TABLE](https://mariadb.com/kb/en/json_table/).
+ **Nouvelles valeurs par défaut pour les paramètres** : les paramètres suivants disposent de nouvelles valeurs par défaut pour les instances de base de données MariaDB version 10.6 :
+ La valeur par défaut des paramètres suivants est passée de `utf8` à `utf8mb3` :
+ [character\$1set\$1client](https://mariadb.com/kb/en/server-system-variables/#character_set_client)
+ [character\$1set\$1connection](https://mariadb.com/kb/en/server-system-variables/#character_set_connection)
+ [character\$1set\$1results](https://mariadb.com/kb/en/server-system-variables/#character_set_results)
+ [character\$1set\$1system](https://mariadb.com/kb/en/server-system-variables/#character_set_system)
Bien que les valeurs par défaut aient changé pour ces paramètres, il n'y a pas de changement fonctionnel. Pour plus d'informations, consultez [Supported Character Sets and Collations](https://mariadb.com/kb/en/supported-character-sets-and-collations/) (Jeux de caractères et classements pris en charge) dans la documentation MariaDB.
+ La valeur par défaut du paramètre [ collation\$1connection](https://mariadb.com/kb/en/server-system-variables/#collation_connection) est passée de `utf8_general_ci` à `utf8mb3_general_ci`. Bien que les valeurs par défaut aient changé pour ces paramètres, il n'y a pas de changement fonctionnel.
+ La valeur par défaut du paramètre [old\$1mode](https://mariadb.com/kb/en/server-system-variables/#old_mode) est passé de non défini à `UTF8_IS_UTF8MB3`. Bien que les valeurs par défaut aient changé pour ces paramètres, il n'y a pas de changement fonctionnel.
Pour accéder à la liste complète des fonctionnalités de MariaDB 10.6 ainsi qu’à la documentation associée, consultez [Modifications et améliorations apportées à MariaDB 10.6](https://mariadb.com/kb/en/changes-improvements-in-mariadb-106/) et [Notes de mise à jour – Série MariaDB 10.6](https://mariadb.com/kb/en/release-notes-mariadb-106-series/) sur le site web de MariaDB.
Pour obtenir la liste des fonctions non prises en charge, consultez [Fonctions MariaDB non prises en charge par Amazon RDS](MariaDB.Concepts.FeatureNonSupport.md).
### Prise en charge de MariaDB 10.5 sur Amazon RDS
Amazon RDS prend en charge les nouvelles fonctions suivantes pour vos instances de base de données exécutant MariaDB version 10.5 ou versions ultérieures :
+ **Améliorations d'InnoDB** – MariaDB version 10.5 inclut les améliorations d'InnoDB. Pour plus d'informations, consultez [InnoDB: Performance Improvements etc.](https://mariadb.com/kb/en/changes-improvements-in-mariadb-105/#innodb-performance-improvements-etc) (InnoDB : Améliorations liées aux performances, etc.) dans la documentation MariaDB.
+ **Mises à jour du schéma de performances** – MariaDB version 10.5 inclut les mises à jour du schéma de performances. Pour plus d'informations, consultez [Performance Schema Updates to Match MySQL 5.7 Instrumentation and Tables](https://mariadb.com/kb/en/changes-improvements-in-mariadb-105/#performance-schema-updates-to-match-mysql-57-instrumentation-and-tables) (Mises à jour du schéma de performances pour assurer la mise en correspondance avec l'instrumentation et les tables de MySQL 5.7) dans la documentation MariaDB.
+ **Un seul fichier dans le journal redo d'InnoDB** – Dans les versions de MariaDB antérieures à la version 10.5, la valeur du paramètre `innodb_log_files_in_group` était définie sur `2`. Dans MariaDB version 10.5, la valeur de ce paramètre est définie sur `1`.
Si vous procédez à une mise à niveau vers MariaDB version 10.5 et que vous ne modifiez pas les paramètres, la valeur du paramètre `innodb_log_file_size` reste inchangée. Mais elle s'applique à un seul fichier journal au lieu de deux. En conséquence, votre instance de base de données MariaDB version 10.5 mise à niveau utilise la moitié de la taille du journal redo qu'elle utilisait avant la mise à niveau. Ce changement peut avoir un impact notable sur les performances. Pour résoudre ce problème, vous pouvez doubler la valeur du paramètre `innodb_log_file_size`. 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 RDS](USER_WorkingWithParamGroups.Modifying.md).
+ **Commande SHOW SLAVE STATUS non prise en charge** – Dans les versions de MariaDB antérieures à la version 10.5, la commande `SHOW SLAVE STATUS` exigeait le privilège `REPLICATION SLAVE`. Dans MariaDB version 10.5, la commande `SHOW REPLICA STATUS` équivalente requiert le privilège `REPLICATION REPLICA ADMIN`. Ce nouveau privilège n'est pas accordé à l'utilisateur principal de RDS.
Au lieu d'utiliser la commande `SHOW REPLICA STATUS`, exécutez la nouvelle procédure stockée `mysql.rds_replica_status` pour renvoyer des informations similaires. Pour plus d'informations, consultez [mysql.rds\$1replica\$1status](mysql_rds_replica_status.md).
+ **Commande SHOW RELAYLOG EVENTS non prise en charge** – Dans les versions de MariaDB antérieures à la version 10.5, la commande `SHOW RELAYLOG EVENTS` exigeait le privilège `REPLICATION SLAVE`. Dans MariaDB version 10.5, cette commande requiert le privilège `REPLICATION REPLICA ADMIN`. Ce nouveau privilège n'est pas accordé à l'utilisateur principal de RDS.
+ **Nouvelles valeurs par défaut pour les paramètres** – Les paramètres suivants disposent de nouvelles valeurs par défaut pour les instances de base de données MariaDB version 10.5 :
+ La valeur par défaut du paramètre [max\$1connections](https://mariadb.com/kb/en/server-system-variables/#max_connections) a été remplacée par `LEAST({DBInstanceClassMemory/25165760},12000)`. Pour plus d'informations sur la fonction de paramètre `LEAST`, consultez [Fonctions de paramètre de bases de données](USER_ParamValuesRef.md#USER_ParamFunctions).
+ La valeur par défaut du paramètre [innodb\$1adaptive\$1hash\$1index](https://mariadb.com/kb/en/innodb-system-variables/#innodb_adaptive_hash_index) a été remplacée par `OFF` (`0`).
+ La valeur par défaut du paramètre [innodb\$1checksum\$1algorithm](https://mariadb.com/kb/en/innodb-system-variables/#innodb_checksum_algorithm) a été remplacée par `full_crc32`.
+ La valeur par défaut du paramètre [innodb\$1log\$1file\$1size](https://mariadb.com/kb/en/innodb-system-variables/#innodb_log_file_size) a été remplacée par 2 Go.
Pour accéder à la liste complète des fonctionnalités de MariaDB 10.5 ainsi qu’à la documentation associée, consultez [Modifications et améliorations apportées à MariaDB 10.5](https://mariadb.com/kb/en/changes-improvements-in-mariadb-105/) et [Notes de mise à jour - Série MariaDB 10.5](https://mariadb.com/kb/en/release-notes-mariadb-105-series/) sur le site web de MariaDB.
Pour obtenir la liste des fonctions non prises en charge, consultez [Fonctions MariaDB non prises en charge par Amazon RDS](MariaDB.Concepts.FeatureNonSupport.md).
### Prise en charge de MariaDB 10.4 sur Amazon RDS
Amazon RDS prend en charge les nouvelles fonctions suivantes pour vos instances de base de données exécutant MariaDB version 10.4 ou versions ultérieures :
+ **Améliorations de la sécurité des comptes utilisateur** – Améliorations de l'[expiration des mots de passe](https://mariadb.com/kb/en/user-password-expiry/) et du [verrouillage des comptes](https://mariadb.com/kb/en/account-locking/)
+ **Améliorations de l'optimiseur** – [Fonction Optimizer Trace](https://mariadb.com/kb/en/optimizer-trace-overview/)
+ **Améliorations InnoDB** – [Prise en charge de l'opération DROP COLUMN instantanée](https://mariadb.com/kb/en/alter-table/#drop-column) et extension `VARCHAR` instantanée pour `ROW_FORMAT=DYNAMIC` et `ROW_FORMAT=COMPACT`
+ **Nouveaux paramètres** – Notamment : [tcp\$1nodedelay](https://mariadb.com/kb/en/server-system-variables/#tcp_nodelay), [tls\$1version](https://mariadb.com/kb/en/ssltls-system-variables/#tls_version) et [gtid\$1cleanup\$1batch\$1size](https://mariadb.com/kb/en/gtid/#gtid_cleanup_batch_size)
Pour accéder à la liste complète des fonctionnalités de MariaDB 10.4 ainsi qu’à la documentation associée, consultez [Modifications et améliorations apportées à MariaDB 10.4](https://mariadb.com/kb/en/library/changes-improvements-in-mariadb-104/) et [Notes de mise à jour - Série MariaDB 10.4](https://mariadb.com/kb/en/library/release-notes-mariadb-104-series/) sur le site web de MariaDB.
Pour obtenir la liste des fonctions non prises en charge, consultez [Fonctions MariaDB non prises en charge par Amazon RDS](MariaDB.Concepts.FeatureNonSupport.md).
# Moteurs de stockage pris en charge pour MariaDB sur Amazon RDS
RDS for MariaDB prend en charge les moteurs de stockage suivants.
**Topics**
+ [
## Le moteur de stockage InnoDB
](#MariaDB.Concepts.Storage.InnoDB)
+ [
## Le moteur MyRocks de stockage
](#MariaDB.Concepts.Storage.MyRocks)
Les autres moteurs de stockage ne sont pas pris en charge actuellement par RDS for MariaDB.
## Le moteur de stockage InnoDB
Bien que MariaDB prenne en charge plusieurs moteurs de stockage avec diverses capacités, toutes ne sont pas optimisées pour la récupération sur incident et la durabilité des données. InnoDB est le moteur de stockage recommandé et pris en charge pour les instances de base de données MariaDB sur Amazon RDS. Les fonctionnalités Amazon RDS telles que la point-in-time restauration et la restauration de snapshots nécessitent un moteur de stockage récupérable et ne sont prises en charge que pour le moteur de stockage recommandé pour la version MariaDB.
Pour plus d’informations, consultez [InnoDB](https://mariadb.com/kb/en/innodb/).
## Le moteur MyRocks de stockage
Le moteur MyRocks de stockage est disponible dans RDS pour MariaDB version 10.6 et supérieure. Avant d'utiliser le moteur MyRocks de stockage dans une base de données de production, nous vous recommandons d'effectuer des analyses comparatives et des tests approfondis afin de vérifier les avantages potentiels par rapport à InnoDB pour votre cas d'utilisation.
Le groupe de paramètres par défaut pour MariaDB version 10.6 inclut des paramètres. MyRocks Pour plus d’informations, consultez [Paramètres pour MariaDB](Appendix.MariaDB.Parameters.md) et [Groupes de paramètres pour Amazon RDS](USER_WorkingWithParamGroups.md).
Pour créer une table utilisant le moteur de MyRocks stockage, spécifiez-le `ENGINE=RocksDB` dans l'`CREATE TABLE`instruction. L'exemple suivant crée une table qui utilise le moteur MyRocks de stockage.
```
CREATE TABLE test (a INT NOT NULL, b CHAR(10)) ENGINE=RocksDB;
```
Nous vous recommandons vivement de ne pas exécuter de transactions couvrant à la fois InnoDB et MyRocks des tables. MariaDB ne garantit pas ACID (atomicité, cohérence, isolement, durabilité) pour les transactions entre moteurs de stockage. Bien qu'il soit possible d'avoir à la fois InnoDB et MyRocks des tables dans une instance de base de données, nous ne recommandons pas cette approche, sauf lors d'une migration d'un moteur de stockage à l'autre. Lorsque InnoDB et des MyRocks tables existent dans une instance de base de données, chaque moteur de stockage possède son propre pool de mémoire tampon, ce qui peut entraîner une dégradation des performances.
MyRocks ne supporte pas `SERIALIZABLE` l'isolation ou les verrous interstitiels. Par conséquent, vous ne pouvez généralement pas l'utiliser MyRocks avec une réplication basée sur des instructions. Pour plus d'informations, reportez-vous à la section [ MyRocks et Réplication](https://mariadb.com/kb/en/myrocks-and-replication/).
À l'heure actuelle, vous ne pouvez modifier que les MyRocks paramètres suivants :
+ [https://mariadb.com/kb/en/myrocks-system-variables/#rocksdb_block_cache_size](https://mariadb.com/kb/en/myrocks-system-variables/#rocksdb_block_cache_size)
+ [https://mariadb.com/kb/en/myrocks-system-variables/#rocksdb_bulk_load](https://mariadb.com/kb/en/myrocks-system-variables/#rocksdb_bulk_load)
+ [https://mariadb.com/kb/en/myrocks-system-variables/#rocksdb_bulk_load_size](https://mariadb.com/kb/en/myrocks-system-variables/#rocksdb_bulk_load_size)
+ [https://mariadb.com/kb/en/myrocks-system-variables/#rocksdb_deadlock_detect](https://mariadb.com/kb/en/myrocks-system-variables/#rocksdb_deadlock_detect)
+ [https://mariadb.com/kb/en/myrocks-system-variables/#rocksdb_deadlock_detect_depth](https://mariadb.com/kb/en/myrocks-system-variables/#rocksdb_deadlock_detect_depth)
+ [https://mariadb.com/kb/en/myrocks-system-variables/#rocksdb_max_latest_deadlocks](https://mariadb.com/kb/en/myrocks-system-variables/#rocksdb_max_latest_deadlocks)
Le moteur MyRocks de stockage et le moteur de stockage InnoDB peuvent se disputer la mémoire en fonction des paramètres `rocksdb_block_cache_size` et`innodb_buffer_pool_size`. Dans certains cas, il se peut que vous ayez l'intention d'utiliser le moteur MyRocks de stockage uniquement sur une instance de base de données particulière. Dans l'affirmative, nous vous recommandons de définir le paramètre `innodb_buffer_pool_size minimal` à une valeur minimale et de définir le paramètre `rocksdb_block_cache_size` à une valeur aussi haute que possible.
Vous pouvez accéder aux fichiers MyRocks journaux à l'aide [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DownloadDBLogFilePortion.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DownloadDBLogFilePortion.html)des opérations [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBLogFiles.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBLogFiles.html)et.
Pour plus d'informations MyRocks, consultez [MyRocks](https://mariadb.com/kb/en/myrocks/)le site Web de MariaDB.
# Préparation du cache pour MariaDB sur Amazon RDS
La préparation du cache InnoDB peut fournir des gains de performances pour votre instance de base de données MariaDB en enregistrant l'état actuel du pool de mémoires tampons lorsque l'instance de base de données est arrêtée, puis en rechargeant le pool de mémoires tampons à partir des informations enregistrées au démarrage de l'instance de base de données. Cette approche contourne la nécessité de « préparer » le pool de tampons à partir d'une utilisation normale de la base de données et précharge à la place le pool de tampons avec les pages des requêtes courantes connues. Pour plus d'informations sur la préparation du cache, consultez [Vidage et restauration du pool de tampons](http://mariadb.com/kb/en/mariadb/xtradbinnodb-buffer-pool/#dumping-and-restoring-the-buffer-pool) dans la documentation MariaDB.
La préparation du cache est activée par défaut sur les instances de base de données MariaDB versions 10.3 et ultérieures. Pour l'activer, définissez les paramètres `innodb_buffer_pool_dump_at_shutdown` et `innodb_buffer_pool_load_at_startup` avec la valeur 1 dans le groupe de paramètres de votre instance de base de données. La modification de ces valeurs dans un groupe de paramètres affecte toutes les instances de base de données MariaDB qui utilisent ce groupe de paramètres. Pour activer la préparation du cache pour des instances de base de données MariaDB spécifiques, vous aurez peut-être à créer un groupe de paramètres pour ces instances de base de données. Pour plus d'informations sur les groupes de paramètres, consultez [Groupes de paramètres pour Amazon RDS](USER_WorkingWithParamGroups.md).
La préparation du cache fournit principalement une amélioration des performances pour les instances de bases de données qui utilisent le stockage standard. Si vous utilisez le stockage PIOPS, vous ne constatez généralement pas d'amélioration significative des performances.
**Important**
Si votre instance de base de données MariaDB ne se ferme pas normalement, comme lors d'un basculement, l'état du pool de tampons n'est pas enregistré sur le disque. Dans ce cas, MariaDB charge n'importe quel fichier du pool de tampons disponible au redémarrage de l'instance de base de données. Il n'en résulte aucun dommage, mais le pool de tampons restauré peut ne pas refléter l'état le plus récent du pool de tampons avant le redémarrage. Pour vous assurer d'avoir un état récent du pool de mémoires tampons disponible afin de préparer le cache au démarrage, il est recommandé que vous vidiez régulièrement le pool de mémoires tampons « à la demande ». Vous pouvez vider ou charger le pool de tampons à la demande.
Vous pouvez créer un événement pour vider le pool de tampons automatiquement et à intervalles réguliers. Par exemple, l'instruction suivante crée un événement nommé `periodic_buffer_pool_dump` qui vide le pool de mémoires tampons toutes les heures.
```
1. CREATE EVENT periodic_buffer_pool_dump
2. ON SCHEDULE EVERY 1 HOUR
3. DO CALL mysql.rds_innodb_buffer_pool_dump_now();
```
Pour plus d'informations, consultez [Événements](http://mariadb.com/kb/en/mariadb/stored-programs-and-views-events/) dans la documentation MariaDB.
## Vidage et chargement du pool de tampons à la demande
Vous pouvez enregistrer et charger le cache à la demande à l'aide des procédures stockées suivantes :
+ Pour vider l'état actuel du pool de mémoires tampons sur le disque, appelez la procédure stockée [mysql.rds\$1innodb\$1buffer\$1pool\$1dump\$1now](mysql-stored-proc-warming.md#mysql_rds_innodb_buffer_pool_dump_now).
+ Pour charger l'état enregistré du pool de mémoires tampons à partir du disque, appelez la procédure stockée [mysql.rds\$1innodb\$1buffer\$1pool\$1load\$1now](mysql-stored-proc-warming.md#mysql_rds_innodb_buffer_pool_load_now).
+ Pour annuler une opération de chargement en cours, appelez la procédure stockée [mysql.rds\$1innodb\$1buffer\$1pool\$1load\$1abort](mysql-stored-proc-warming.md#mysql_rds_innodb_buffer_pool_load_abort).
# Fonctions MariaDB non prises en charge par Amazon RDS
Les fonctionnalités de MariaDB suivantes ne sont pas prises en charge sur Amazon RDS :
+ Moteur de stockage S3
+ Plug-in d'authentification – GSSAPI
+ Plug-in d'authentification – Socket Unix
+ AWS Plugin de chiffrement pour la gestion des clés
+ Réplication différée pour les versions MariaDB inférieures à 10.6
+ Chiffrement au repos MariaDB natif pour InnoDB et Aria
Vous pouvez activer le chiffrement au repos pour une instance de base de données MariaDB en suivant les instructions de [Chiffrement des ressources Amazon RDS](Overview.Encryption.md).
+ HandlerSocket
+ Type de table JSON pour les versions MariaDB inférieures à 10.6
+ MariaDB ColumnStore
+ MariaDB Galera Cluster
+ Réplication multi-source
+ MyRocks moteur de stockage pour les versions de MariaDB inférieures à 10.6
+ Plugin de validation de mot de passe, `simple_password_check` et `cracklib_password_check` pour les versions de MariaDB antérieures à 11.4
+ Moteur de stockage Spider
+ Moteur de stockage Sphinx
+ Moteur de stockage TokuDB
+ Attributs d'objet spécifiques au moteur de stockage, tels que décrits dans la section [Nouveaux attributs définis par le moteur dans la documentation Table/Field/Index MariaDB](http://mariadb.com/kb/en/mariadb/engine-defined-new-tablefieldindex-attributes/)
+ Chiffrement de table et d'espace de tables
+ Plug-in Hashicorp Key Management
+ Exécution de deux mises à niveau en parallèle
Pour offrir une expérience de service géré, Amazon RDS ne fournit pas l'accès shell aux instances de base de données et limite l'accès à certaines tables et procédures système qui requièrent des privilèges avancés. Amazon RDS prend en charge l'accès aux bases de données sur une instance de base de données en utilisant toute application cliente SQL standard. Amazon RDS ne permet pas d’accès d’hôte direct à une instance de base de données via Telnet, Secure Shell (SSH) ou une connexion Bureau à distance Windows.
# Versions de MariaDB sur Amazon RDS
Dans MariaDB, les numéros de version sont organisés en versions X.Y.Z. Dans la terminologie Amazon RDS, X.Y indique la version majeure et Z le numéro de la version mineure. Pour les implémentations Amazon RDS, un changement de version sera considéré comme majeur si le numéro de la version majeure change, par exemple, en passant de la version 10.5 à la version 10.6. Un changement de version sera considéré comme mineur si seul le numéro de la version mineure change, par exemple, en passant de la version 10.6.14 à 10.6.16.
**Topics**
+ [
## Versions de MariaDB mineures prises en charge sur Amazon RDS
](#MariaDB.Concepts.VersionMgmt.Supported)
+ [
## Versions de MariaDB majeures prises en charge sur Amazon RDS
](#MariaDB.Concepts.VersionMgmt.ReleaseCalendar)
+ [
## Utilisation de l'environnement de prévisualisation de base de données
](#mariadb-working-with-the-database-preview-environment)
+ [
## MariaDB version 11.7 dans l’environnement de version préliminaire de base de données
](#mariadb-preview-environment-version-11-7)
+ [
## Versions rendues obsolètes pour Amazon RDS for MariaDB
](#MariaDB.Concepts.DeprecatedVersions)
## Versions de MariaDB mineures prises en charge sur Amazon RDS
Amazon RDS prend actuellement en charge les versions mineures suivantes de MariaDB.
**Note**
Les dates avec seulement un mois et une année sont approximatives et sont mises à jour avec une date exacte quand elles sont connues.
Le tableau suivant indique les versions mineures de MariaDB 11.8 actuellement prises en charge par Amazon RDS.
| Version du moteur MariaDB | Date de parution communautaire | Date de parution de RDS | Date de fin du support standard de RDS |
| --- | --- | --- | --- |
| 11,8.6 | 4 février 2026 | 10 février 2026 | février 2027 |
| 11,8.5 | 14 novembre 2025 | 20 novembre 2025 | Novembre 2026 |
| 11,8.3 | 6 août 2025 | 25 août 2025 | Septembre 2026 |
Le tableau suivant indique les versions mineures de MariaDB 11.4 actuellement prises en charge par Amazon RDS.
| Version du moteur MariaDB | Date de parution communautaire | Date de parution de RDS | Date de fin du support standard de RDS |
| --- | --- | --- | --- |
| 11,4,10 | 4 février 2026 | 10 février 2026 | février 2027 |
| 11.4.9 | 6 novembre 2025 | 18 novembre 2025 | Novembre 2026 |
| 11,4.8 | 6 août 2025 | 13 août 2025 | Septembre 2026 |
| 11,4.7 | 22 mai 2025 | 4 juin 2025 | Septembre 2026 |
| 11.4.5 | 4 février 2025 | 24 février 2025 | mai 2026 |
| 11,4.4 | 1er novembre 2024 | 20 décembre 2024 | mai 2026 |
| 11.4.3 | 8 août 2024 | 15 octobre 2024 | mai 2026 |
Le tableau suivant indique les versions mineures de MariaDB 10.11 actuellement prises en charge par Amazon RDS.
| Version du moteur MariaDB | Date de parution communautaire | Date de parution de RDS | Date de fin du support standard de RDS |
| --- | --- | --- | --- |
| 10,1,116 | 4 février 2026 | 10 février 2026 | février 2027 |
| 10,1,115 | 6 novembre 2025 | 18 novembre 2025 | Novembre 2026 |
| 10,1,114 | 6 août 2025 | 13 août 2025 | Septembre 2026 |
| 10,1,113 | 22 mai 2025 | 4 juin 2025 | Septembre 2026 |
| 10,11,11 | 4 février 2025 | 24 février 2025 | mai 2026 |
| 10,1,110 | 1er novembre 2024 | 20 décembre 2024 | mai 2026 |
| 10,11.9 | 8 août 2024 | 4 septembre 2024 | mai 2026 |
Le tableau suivant indique les versions mineures de MariaDB 10.6 actuellement prises en charge par Amazon RDS.
| Version du moteur MariaDB | Date de parution communautaire | Date de parution de RDS | Date de fin du support standard de RDS |
| --- | --- | --- | --- |
| 10,6,25 | 4 février 2026 | 10 février 2026 | Juillet 2026 |
| 10,6,24 | 6 novembre 2025 | 18 novembre 2025 | Juillet 2026 |
| 10,6,23 | 6 août 2025 | 13 août 2025 | Juillet 2026 |
| 10,6,22 | 6 mai 2025 | 20 mai 2025 | Juillet 2026 |
| 10,6,21 | 4 février 2025 | 24 février 2025 | mai 2026 |
| 10,6,20 | 1er novembre 2024 | 20 décembre 2024 | mai 2026 |
| 10,6,19 | 8 août 2024 | 4 septembre 2024 | mai 2026 |
Le tableau suivant indique les versions mineures de MariaDB 10.5 actuellement prises en charge par Amazon RDS.
| Version du moteur MariaDB | Date de parution communautaire | Date de parution de RDS | Date de fin du support standard de RDS |
| --- | --- | --- | --- |
| 10,5,29 | 6 mai 2025 | 20 mai 2025 | juin 2026 |
| 10,5,28 | 4 février 2025 | 24 février 2025 | juin 2026 |
| 10,5,27 | 1er novembre 2024 | 20 décembre 2024 | mai 2026 |
Vous pouvez spécifier n'importe quelle version MariaDB actuellement prise en charge lorsque vous créez une instance de base de données. Vous pouvez spécifier la version majeure (par exemple, MariaDB 10.5) et toute version mineure prise en charge pour la version majeure spécifiée. Si aucune version n'est spécifiée, Amazon RDS utilise par défaut une version prise en charge, généralement la plus récente. Si une version majeure est spécifiée, mais qu'une version mineure ne l'est pas, Amazon RDS utilise par défaut une version récente de la version majeure que vous avez spécifiée. Pour voir la liste des versions prises en charge, ainsi que les valeurs par défaut pour les instances de base de données nouvellement créées, utilisez la [https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-engine-versions.html](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-engine-versions.html) AWS CLI commande.
Par exemple, pour répertorier les versions de moteur prises en charge pour RDS for MariaDB, exécutez la commande CLI suivante :
```
aws rds describe-db-engine-versions --engine mariadb --query "*[].{Engine:Engine,EngineVersion:EngineVersion}" --output text
```
La version par défaut de MariaDB peut varier selon la Région AWS. Pour créer une instance de base de données avec une version mineure spécifique, spécifiez la version mineure lors de la création de l’instance de base de données. Vous pouvez déterminer la version mineure par défaut pour un Région AWS en exécutant la AWS CLI commande suivante :
```
aws rds describe-db-engine-versions --default-only --engine mariadb --engine-version major_engine_version --region region --query "*[].{Engine:Engine,EngineVersion:EngineVersion}" --output text
```
*major\$1engine\$1version*Remplacez-le par la version principale du moteur, puis remplacez *region* par le Région AWS. Par exemple, la AWS CLI commande suivante renvoie la version mineure du moteur MariaDB par défaut pour la version majeure 10.5 et pour l'ouest des États-Unis (Oregon) Région AWS (us-west-2) :
```
aws rds describe-db-engine-versions --default-only --engine mariadb --engine-version 10.5 --region us-west-2 --query "*[].{Engine:Engine,EngineVersion:EngineVersion}" --output text
```
### Versions mineures de MariaDB sur Amazon RDS
**Topics**
+ [
#### Version 11.8.6 de MariaDB
](#MariaDB.Concepts.VersionMgmt.Supported.Minor.11.8.6)
+ [
#### Version 11.8.5 de MariaDB
](#MariaDB.Concepts.VersionMgmt.Supported.Minor.11.8.5)
+ [
#### MariaDB version 11.8.3
](#MariaDB.Concepts.VersionMgmt.Supported.Minor.11.8.3)
+ [
#### Version 11.4.10 de MariaDB
](#MariaDB.Concepts.VersionMgmt.Supported.Minor.11.4.10)
+ [
#### Version 11.4.9 de MariaDB
](#MariaDB.Concepts.VersionMgmt.Supported.Minor.11.4.9)
+ [
#### MariaDB version 11.4.8
](#MariaDB.Concepts.VersionMgmt.Supported.Minor.11.4.8)
+ [
#### MariaDB version 11.4.7
](#MariaDB.Concepts.VersionMgmt.Supported.Minor.11.4.7)
+ [
#### MariaDB version 11.4.5
](#MariaDB.Concepts.VersionMgmt.Supported.Minor.11.4.5)
+ [
#### MariaDB version 11.4.4
](#MariaDB.Concepts.VersionMgmt.Supported.Minor.11.4.4)
+ [
#### Version 10.11.16 de MariaDB
](#MariaDB.Concepts.VersionMgmt.Supported.Minor.10.11.16)
+ [
#### Version 10.11.15 de MariaDB
](#MariaDB.Concepts.VersionMgmt.Supported.Minor.10.11.15)
+ [
#### MariaDB version 10.11.14
](#MariaDB.Concepts.VersionMgmt.Supported.Minor.10.11.14)
+ [
#### MariaDB version 10.11.13
](#MariaDB.Concepts.VersionMgmt.Supported.Minor.10.11.13)
+ [
#### MariaDB version 10.11.11
](#MariaDB.Concepts.VersionMgmt.Supported.Minor.10.11.11)
+ [
#### MariaDB version 10.11.10
](#MariaDB.Concepts.VersionMgmt.Supported.Minor.10.11.10)
+ [
#### Version 10.6.25 de MariaDB
](#MariaDB.Concepts.VersionMgmt.Supported.Minor.10.6.25)
+ [
#### Version 10.6.24 de MariaDB
](#MariaDB.Concepts.VersionMgmt.Supported.Minor.10.6.24)
+ [
#### MariaDB version 10.6.23
](#MariaDB.Concepts.VersionMgmt.Supported.Minor.10.6.23)
+ [
#### MariaDB version 10.6.22
](#MariaDB.Concepts.VersionMgmt.Supported.Minor.10.6.22)
+ [
#### MariaDB version 10.6.21
](#MariaDB.Concepts.VersionMgmt.Supported.Minor.10.6.21)
+ [
#### MariaDB version 10.6.20
](#MariaDB.Concepts.VersionMgmt.Supported.Minor.10.6.20)
+ [
#### MariaDB version 10.5.29
](#MariaDB.Concepts.VersionMgmt.Supported.Minor.10.5.29)
+ [
#### MariaDB version 10.5.28
](#MariaDB.Concepts.VersionMgmt.Supported.Minor.10.5.28)
+ [
#### MariaDB version 10.5.27
](#MariaDB.Concepts.VersionMgmt.Supported.Minor.10.5.27)
#### Version 11.8.6 de MariaDB
La version 11.8.6 de MariaDB est désormais disponible sur Amazon RDS. Cette version contient des correctifs et des améliorations ajoutés par la communauté MariaDB et Amazon RDS.
**Nouvelles fonctionnalités et améliorations**
+ Les informations de fuseau horaire ont été mises à jour pour les baser sur `tzdata2025c`.
+ Correction d'un problème qui empêchait certaines instructions SQL d'être enregistrées dans le journal d'audit.
#### Version 11.8.5 de MariaDB
La version 11.8.5 de MariaDB est désormais disponible sur Amazon RDS. Cette version contient des correctifs et des améliorations ajoutés par la communauté MariaDB et Amazon RDS.
#### MariaDB version 11.8.3
MariaDB version 11.8.3 est désormais disponible sur Amazon RDS. Cette version contient des correctifs et des améliorations ajoutés par la communauté MariaDB et Amazon RDS.
**Nouvelles fonctionnalités et améliorations**
+ **Nouvelle valeur par défaut pour le paramètre** : la valeur par défaut du paramètre `require_secure_transport` est passée de `0` à `1`, ce qui renforce les connexions de transport sécurisées par défaut. Pour de plus amples informations, veuillez consulter [Exiger toutes SSL/TLS les connexions à une instance de base de données MariaDB sur Amazon RDS](mariadb-ssl-connections.require-ssl.md).
#### Version 11.4.10 de MariaDB
La version 11.4.10 de MariaDB est désormais disponible sur Amazon RDS. Cette version contient des correctifs et des améliorations ajoutés par la communauté MariaDB et Amazon RDS.
**Nouvelles fonctionnalités et améliorations**
+ Les informations de fuseau horaire ont été mises à jour pour les baser sur `tzdata2025c`.
+ Correction d'un problème qui empêchait certaines instructions SQL d'être enregistrées dans le journal d'audit.
#### Version 11.4.9 de MariaDB
La version 11.4.9 de MariaDB est désormais disponible sur Amazon RDS. Cette version contient des correctifs et des améliorations ajoutés par la communauté MariaDB et Amazon RDS.
#### MariaDB version 11.4.8
MariaDB version 11.4.8 est désormais disponible sur Amazon RDS. Cette version contient des correctifs et des améliorations ajoutés par la communauté MariaDB et Amazon RDS.
#### MariaDB version 11.4.7
MariaDB version 11.4.7 est désormais disponible sur Amazon RDS. Cette version contient des correctifs et des améliorations ajoutés par la communauté MariaDB et Amazon RDS.
**Nouvelles fonctionnalités et améliorations**
+ Les informations de fuseau horaire ont été mises à jour pour les baser sur `tzdata2025b`.
#### MariaDB version 11.4.5
MariaDB version 11.4.5 est désormais disponible sur Amazon RDS. Cette version contient des correctifs et des améliorations ajoutés par la communauté MariaDB et Amazon RDS.
**Nouvelles fonctionnalités et améliorations**
+ Les informations de fuseau horaire ont été mises à jour pour les baser sur `tzdata2025a`.
#### MariaDB version 11.4.4
MariaDB version 11.4.4 est désormais disponible sur Amazon RDS. Cette version contient des correctifs et des améliorations ajoutés par la communauté MariaDB et Amazon RDS.
**Nouvelles fonctionnalités et améliorations**
+ Annulation de deux modifications apportées à la communauté MariaDB qui point-in-time entraînaient l'échec de la restauration (PITR). Pour plus d’informations, consultez [le problème Jira MariaDB Server MDEV-35528](https://jira.mariadb.org/browse/MDEV-35528).
#### Version 10.11.16 de MariaDB
La version 10.11.16 de MariaDB est désormais disponible sur Amazon RDS. Cette version contient des correctifs et des améliorations ajoutés par la communauté MariaDB et Amazon RDS.
**Nouvelles fonctionnalités et améliorations**
+ Les informations de fuseau horaire ont été mises à jour pour les baser sur `tzdata2025c`.
+ Correction d'un problème qui empêchait certaines instructions SQL d'être enregistrées dans le journal d'audit.
#### Version 10.11.15 de MariaDB
La version 10.11.15 de MariaDB est désormais disponible sur Amazon RDS. Cette version contient des correctifs et des améliorations ajoutés par la communauté MariaDB et Amazon RDS.
#### MariaDB version 10.11.14
MariaDB version 10.11.14 est désormais disponible sur Amazon RDS. Cette version contient des correctifs et des améliorations ajoutés par la communauté MariaDB et Amazon RDS.
#### MariaDB version 10.11.13
MariaDB version 10.11.13 est désormais disponible sur Amazon RDS. Cette version contient des correctifs et des améliorations ajoutés par la communauté MariaDB et Amazon RDS.
**Nouvelles fonctionnalités et améliorations**
+ Les informations de fuseau horaire ont été mises à jour pour les baser sur `tzdata2025b`.
#### MariaDB version 10.11.11
MariaDB version 10.11.11 est désormais disponible sur Amazon RDS. Cette version contient des correctifs et des améliorations ajoutés par la communauté MariaDB et Amazon RDS.
**Nouvelles fonctionnalités et améliorations**
+ Les informations de fuseau horaire ont été mises à jour pour les baser sur `tzdata2025a`.
#### MariaDB version 10.11.10
MariaDB version 10.11.10 est désormais disponible sur Amazon RDS. Cette version contient des correctifs et des améliorations ajoutés par la communauté MariaDB et Amazon RDS.
**Nouvelles fonctionnalités et améliorations**
+ Annulation de deux modifications apportées à la communauté MariaDB qui point-in-time entraînaient l'échec de la restauration (PITR). Pour plus d’informations, consultez [le problème Jira MariaDB Server MDEV-35528](https://jira.mariadb.org/browse/MDEV-35528).
#### Version 10.6.25 de MariaDB
La version 10.6.25 de MariaDB est désormais disponible sur Amazon RDS. Cette version contient des correctifs et des améliorations ajoutés par la communauté MariaDB et Amazon RDS.
**Nouvelles fonctionnalités et améliorations**
+ Les informations de fuseau horaire ont été mises à jour pour les baser sur `tzdata2025c`.
+ Correction d'un problème qui empêchait certaines instructions SQL d'être enregistrées dans le journal d'audit.
#### Version 10.6.24 de MariaDB
La version 10.6.24 de MariaDB est désormais disponible sur Amazon RDS. Cette version contient des correctifs et des améliorations ajoutés par la communauté MariaDB et Amazon RDS.
#### MariaDB version 10.6.23
MariaDB version 10.6.23 est désormais disponible sur Amazon RDS. Cette version contient des correctifs et des améliorations ajoutés par la communauté MariaDB et Amazon RDS.
#### MariaDB version 10.6.22
MariaDB version 10.6.22 est désormais disponible sur Amazon RDS. Cette version contient des correctifs et des améliorations ajoutés par la communauté MariaDB et Amazon RDS.
**Nouvelles fonctionnalités et améliorations**
+ Les informations de fuseau horaire ont été mises à jour pour les baser sur `tzdata2025b`.
#### MariaDB version 10.6.21
MariaDB version 10.6.21 est désormais disponible sur Amazon RDS. Cette version contient des correctifs et des améliorations ajoutés par la communauté MariaDB et Amazon RDS.
**Nouvelles fonctionnalités et améliorations**
+ Les informations de fuseau horaire ont été mises à jour pour les baser sur `tzdata2025a`.
#### MariaDB version 10.6.20
MariaDB version 10.6.20 est désormais disponible sur Amazon RDS. Cette version contient des correctifs et des améliorations ajoutés par la communauté MariaDB et Amazon RDS.
**Nouvelles fonctionnalités et améliorations**
+ Annulation de deux modifications apportées à la communauté MariaDB qui point-in-time entraînaient l'échec de la restauration (PITR). Pour plus d’informations, consultez [le problème Jira MariaDB Server MDEV-35528](https://jira.mariadb.org/browse/MDEV-35528).
#### MariaDB version 10.5.29
MariaDB version 10.5.29 est désormais disponible sur Amazon RDS. Cette version contient des correctifs et des améliorations ajoutés par la communauté MariaDB et Amazon RDS.
**Nouvelles fonctionnalités et améliorations**
+ Les informations de fuseau horaire ont été mises à jour pour les baser sur `tzdata2025b`.
#### MariaDB version 10.5.28
MariaDB version 10.5.28 est désormais disponible sur Amazon RDS. Cette version contient des correctifs et des améliorations ajoutés par la communauté MariaDB et Amazon RDS.
**Nouvelles fonctionnalités et améliorations**
+ Les informations de fuseau horaire ont été mises à jour pour les baser sur `tzdata2025a`.
#### MariaDB version 10.5.27
MariaDB version 10.5.27 est désormais disponible sur Amazon RDS. Cette version contient des correctifs et des améliorations ajoutés par la communauté MariaDB et Amazon RDS.
**Nouvelles fonctionnalités et améliorations**
+ Annulation de deux modifications apportées à la communauté MariaDB qui point-in-time entraînaient l'échec de la restauration (PITR). Pour plus d’informations, consultez [le problème Jira MariaDB Server MDEV-35528](https://jira.mariadb.org/browse/MDEV-35528).
## Versions de MariaDB majeures prises en charge sur Amazon RDS
Les versions majeures de RDS for MariaDB restent disponibles au moins jusqu'à la fin de vie de la version correspondante de la communauté. Vous pouvez utiliser les dates suivantes pour planifier vos cycles de test et de mise à niveau. Si Amazon étend le support d'une version de RDS for MariaDB au-delà de la date initialement prévue, ce tableau sera mis à jour pour refléter la nouvelle date.
**Note**
Les dates avec seulement un mois et une année sont approximatives et sont mises à jour avec une date exacte quand elles sont connues.
Vous pouvez également consulter les informations relatives aux dates de support des principales versions du moteur en exécutant la AWS CLI commande [describe-db-major-engine-versions](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-major-engine-versions.html) ou en utilisant l'opération d'API [DBMajorEngineVersionsDescribe](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBMajorEngineVersions.html) RDS.
| Version majeure de MariaDB | Date de parution communautaire | Date de parution de RDS | Date de fin de vie de la communauté | Date de fin de la prise en charge standard de RDS |
| --- | --- | --- | --- | --- |
| MariaDB 11.8 | 6 août 2025 | 25 août 2025 | Juin 2030 | Juin 2030 |
| MariaDB 11.4 | 8 août 2024 | 15 octobre 2024 | Mai 2029 | Mai 2029 |
| MariaDB 10.11 | 16 février 2023 | 21 août 2023 | 16 février 2028 | Février 2028 |
| MariaDB 10.6 | 6 juillet 2021 | 3 février 2022 | 6 juillet 2026 | Août 2026 |
| MariaDB 10.5 | 24 juin 2020 | 21 janvier 2021 | 24 juin 2025 | Août 2026 |
## Utilisation de l'environnement de prévisualisation de base de données
Les instances de base de données RDS for MariaDB dans l’environnement de version préliminaire de base de données sont similaires sur le plan fonctionnel à d’autres instances de base de données RDS for MariaDB. Cependant, vous ne pouvez pas utiliser l’environnement de version préliminaire de base de données pour les charges de travail de production.
Les environnements de prévisualisation présentent les limitations suivantes :
+ Amazon RDS supprime toutes les instances de base de données 60 jours après leur création, en même temps que leurs sauvegardes et leurs instantanés.
+ Vous ne pouvez utiliser que les stockages SSD à usage général et les stockages SSD à IOPS provisionnées.
+ Vous ne pouvez pas obtenir d'aide Support avec les instances de base de données. [Vous pouvez plutôt publier vos questions sur la communauté de AWS questions-réponses gérée,AWS Re:post.](https://repost.aws/tags/TAsibBK6ZeQYihN9as4S_psg/amazon-relational-database-service)
+ Vous ne pouvez pas copier un instantané d’instance de base de données dans un environnement de production.
Les options suivantes sont prises en charge par la prévisualisation.
+ Vous pouvez créer des instances de base de données à l'aide des classes d'instance de base de données db.m6i, db.r6i, db.m6g, db.m5, db.t3, db.r6g et db.r5. Pour plus d’informations sur les classes d’instance RDS, consultez [Classes d'instances de base de données ](Concepts.DBInstanceClass.md).
+ Vous pouvez utiliser à la fois des déploiements mono-AZ et multi-AZ.
+ Vous pouvez utiliser les fonctions de vidage et de chargement MariaDB standard pour exporter des bases de données depuis l’environnement de version préliminaire de base de données ou pour importer des bases de données dans cet environnement.
### Fonctions non prises en charge dans l’environnement de version préliminaire de base de données
Les fonctions suivantes ne sont pas disponibles dans l’environnement de version préliminaire de base de données :
+ Copie d’instantanés entre Régions
+ Réplicas en lecture entre Régions
+ RDS Proxy (Proxy RDS)
### Création d’une nouvelle instance de base de données dans l’environnement de version préliminaire de base de données
Vous pouvez créer une instance de base de données dans l'environnement Database Preview à l'aide de l'API AWS Management Console AWS CLI, ou RDS.
#### Console
**Pour créer une instance de base de données dans l’environnement de version préliminaire de base de données**
1. Connectez-vous à la console Amazon RDS AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)l'adresse.
1. Choisissez **Dashboard (Tableau de bord)** dans le panneau de navigation.
1. Sur la page **Tableau de bord**, recherchez la section **Environnement de version préliminaire de base de données**, comme illustré dans l’image suivante.
![\[La section Environnement de version préliminaire de base de données avec lien dans la console Amazon RDS.\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/preview-environment-dashboard.png)
Vous pouvez accéder directement à l’[environnement de version préliminaire de base de données](https://us-east-2.console.aws.amazon.com/rds-preview/home?region=us-east-2#). Avant de poursuivre, vous devez reconnaître et accepter les limites.
![\[La boîte de dialogue Accord de service pour l’environnement de version préliminaire de base de données pour confirmer les limites.\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/preview-environment-console.png)
1. Pour créer l’instance de base de données RDS for MariaDB, suivez le même processus que pour créer n’importe quelle instance de base de données Amazon RDS. Pour plus d’informations, consultez la procédure [Console](USER_CreateDBInstance.md#USER_CreateDBInstance.CON) dans [Création d’une instance de base de données](USER_CreateDBInstance.md#USER_CreateDBInstance.Creating).
#### AWS CLI
Pour créer une instance de base de données dans l'environnement Database Preview à l'aide du AWS CLI, utilisez le point de terminaison suivant.
```
rds-preview.us-east-2.amazonaws.com
```
Pour créer l’instance de base de données RDS for MariaDB, suivez le même processus que pour créer n’importe quelle instance de base de données Amazon RDS. Pour plus d’informations, consultez la procédure [AWS CLI](USER_CreateDBInstance.md#USER_CreateDBInstance.CLI) dans [Création d’une instance de base de données](USER_CreateDBInstance.md#USER_CreateDBInstance.Creating).
#### API RDS
Pour créer une instance de base de données dans l’environnement de version préliminaire de base de données à l’aide de l’API RDS, utilisez le point de terminaison suivant.
```
rds-preview.us-east-2.amazonaws.com
```
Pour créer l’instance de base de données RDS for MariaDB, suivez le même processus que pour créer n’importe quelle instance de base de données Amazon RDS. Pour plus d’informations, consultez la procédure [API RDS](USER_CreateDBInstance.md#USER_CreateDBInstance.API) dans [Création d’une instance de base de données](USER_CreateDBInstance.md#USER_CreateDBInstance.Creating).
## MariaDB version 11.7 dans l’environnement de version préliminaire de base de données
MariaDB version 11.7 est maintenant disponible dans l’environnement de version préliminaire de base de données Amazon RDS. MariaDB version 11.7 contient plusieurs améliorations qui sont décrites dans [Modifications et améliorations apportées à MariaDB 11.7](https://mariadb.com/kb/en/changes-improvements-in-mariadb-11-7/). Cette version inclut également la prise en charge du type de données vectorielles, l’indexation et la recherche. Pour plus d’informations, consultez [Présentation vectorielle](https://mariadb.com/kb/en/vector-overview/) dans la documentation MariaDB.
Vous pouvez utiliser l'environnement Database Preview pour tester vos charges de travail par rapport à cette version avant qu'elle ne soit entièrement disponible Régions AWS pour les charges de travail de production. Pour plus d’informations sur l’environnement de version préliminaire de base de données, consultez [Utilisation de l'environnement de prévisualisation de base de données](#mariadb-working-with-the-database-preview-environment). Pour accéder à l'environnement en préversion à partir de la console, sélectionnez [rds-preview/](https://console.aws.amazon.com/rds-preview/).
## Versions rendues obsolètes pour Amazon RDS for MariaDB
Amazon RDS for MariaDB versions 10.0, 10.1, 10.2 et 10.3 sont obsolètes.
[Pour plus d'informations sur la politique d'obsolescence d'Amazon RDS pour MariaDB, consultez Amazon RDS. FAQs](https://aws.amazon.com/rds/faqs/)
# Connexion à votre instance de base de données MariaDB
Une fois qu'Amazon RDS a provisionné votre instance de base de données, vous pouvez utiliser n'importe quelle application cliente MariaDB standard pour vous connecter à l'instance. Dans la chaîne de connexion, vous spécifiez l'adresse DNS (système de noms de domaine) du point de terminaison de l'instance de base de données en tant que paramètre hôte. Vous spécifiez également le numéro de port du point de terminaison de l'instance de base de données en tant que paramètre de port.
Vous pouvez vous connecter à une instance de base de données Amazon RDS for MariaDB à l’aide d’outils tels que le client de ligne de commande MySQL. Pour plus d'informations sur l'utilisation du client de ligne de commande MySQL, consultez [Client de ligne de commande mysql](http://mariadb.com/kb/en/mariadb/mysql-command-line-client/) dans la documentation MariaDB. Heidi est une application basée sur l'interface utilisateur graphique que vous pouvez utiliser pour la connexion. Pour en savoir plus, consultez la page [Télécharger HeidiSQL](http://www.heidisql.com/download.php). Pour plus d'informations sur l'installation de MySQL (y compris le client de ligne de commande MySQL), consultez [Installation et mise à niveau de MySQL](https://dev.mysql.com/doc/refman/8.0/en/installing.html).
La plupart des distributions Linux incluent le client MariaDB au lieu du client MySQL Oracle. Pour installer le client de ligne de commande MySQL sur Amazon Linux 2023, exécutez la commande suivante :
```
sudo dnf install mariadb105
```
Pour installer le client de ligne de commande MySQL sur Amazon Linux 2, exécutez la commande suivante :
```
sudo yum install mariadb
```
Pour installer le client de ligne de commande MySQL sur la plupart des distributions Linux basées sur DEB, exécutez la commande suivante.
```
apt-get install mariadb-client
```
Pour vérifier la version de votre client de ligne de commande MySQL, exécutez la commande suivante.
```
mysql --version
```
Pour lire la documentation MySQL pour votre version de client actuelle, exécutez la commande suivante.
```
man mysql
```
Pour se connecter à une instance de base de données depuis l’extérieur d’un cloud privé virtuel (VPC) basé sur Amazon VPC, l’instance de base de données doit être accessible publiquement. En outre, l'accès doit être accordé en utilisant les règles entrantes du groupe de sécurité de l'instance de base de données, et d'autres exigences doivent être satisfaites. Pour plus d'informations, consultez [Impossible de se connecter à l’instance de base de données Amazon RDS](CHAP_Troubleshooting.md#CHAP_Troubleshooting.Connecting).
Vous pouvez utiliser le chiffrement SSL sur les connexions à une instance de base de données MariaDB. Pour plus d’informations, consultez [Prise en charge de SSL/TLS pour les instances de base de données MariaDB sur Amazon RDS](MariaDB.Concepts.SSLSupport.md).
Pour rechercher et vous connecter à une instance de base de données RDS for MariaDB, consultez les rubriques suivantes.
**Topics**
+ [
# Recherche des informations de connexion pour une instance de base de données MariaDB
](USER_ConnectToMariaDBInstance.EndpointAndPort.md)
+ [
# Connexion à partir du client de ligne de commande MySQL (non chiffrée) pour RDS for MariaDB
](USER_ConnectToMariaDBInstance.CLI.md)
+ [
# Connexion à RDS pour MariaDB avec le pilote AWS JDBC et le pilote Python ; AWS
](MariaDB.Connecting.Drivers.md)
+ [
# Dépannage des connexions à votre instance de base de données MariaDB
](USER_ConnectToMariaDBInstance.Troubleshooting.md)
# Recherche des informations de connexion pour une instance de base de données MariaDB
Les informations de connexion d'une instance de base de données incluent son point de terminaison, son port et un utilisateur de base de données valide, tel que l'utilisateur principal. Par exemple, supposons qu'une valeur de point de terminaison soit `mydb.123456789012.us-east-1.rds.amazonaws.com`. Dans ce cas, la valeur du port est `3306`, et l'utilisateur de base de données est `admin`. Compte tenu de ces informations, vous spécifiez les valeurs suivantes dans une chaîne de connexion :
+ Pour un hôte, un nom d'hôte ou un nom DNS, spécifiez `mydb.123456789012.us-east-1.rds.amazonaws.com`.
+ Pour un port, spécifiez `3306`.
+ Pour l'utilisateur, spécifiez `admin`.
Pour vous connecter à une instance de base de données, utilisez n'importe quel client pour le moteur de base de données MariaDB. Par exemple, vous pourriez utiliser le client de ligne de commande MySQL ou MySQL Workbench.
Pour rechercher les informations de connexion d'une instance de base de données, vous pouvez utiliser l'AWS Management Console, la commande de l'AWS Command Line Interface (AWS CLI) [describe-db-instances](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html) ou l'opération de l'API Amazon RDS [DescribedBInstances](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBInstances.html) pour répertorier ses détails.
## Console
**Pour rechercher les informations de connexion d’une instance de base de données dans la AWS Management Console**
1. Connectez-vous à la AWS Management Console et ouvrez la console Amazon RDS à l'adresse [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Dans le panneau de navigation, choisissez **Bases de données** pour afficher la liste de vos instances de base de données.
1. Choisissez le nom de l'instance de base de données MariaDB pour afficher ses détails.
1. Dans l'onglet **Connectivity & security (Connectivité et sécurité)**, copiez le point de terminaison. Notez également le numéro du port. Vous avez besoin du point de terminaison et du numéro de port pour vous connecter à l’instance de base de données.
![\[Point de terminaison et port d’une instance de base de données dans la console Amazon RDS.\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/endpoint-port.png)
1. Si vous devez rechercher le nom d’utilisateur principal, choisissez l’onglet **Configuration** et affichez la valeur **Master username (Identifiant principal**.
## AWS CLI
Pour rechercher les informations de connexion d’une instance de base de données MariaDB à l’aide de l’AWS CLI, exécutez la commande [describe-db-instances](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html). Dans l’appel, recherchez l’ID d’instance de base de données, le point de terminaison, le port et l’identifiant principal.
Pour Linux, macOS ou Unix :
```
aws rds describe-db-instances \
--filters "Name=engine,Values=mariadb" \
--query "*[].[DBInstanceIdentifier,Endpoint.Address,Endpoint.Port,MasterUsername]"
```
Pour Windows :
```
aws rds describe-db-instances ^
--filters "Name=engine,Values=mariadb" ^
--query "*[].[DBInstanceIdentifier,Endpoint.Address,Endpoint.Port,MasterUsername]"
```
Votre sortie doit ressembler à ce qui suit.
```
[
[
"mydb1",
"mydb1.123456789012.us-east-1.rds.amazonaws.com",
3306,
"admin"
],
[
"mydb2",
"mydb2.123456789012.us-east-1.rds.amazonaws.com",
3306,
"admin"
]
]
```
## API RDS
Pour rechercher les informations de connexion d'une instance de base de données à l'aide de l'API Amazon RDS, appelez l'opération [DescribedBInstances](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBInstances.html). Dans la sortie, recherchez les valeurs de l’adresse du point de terminaison, du port du point de terminaison et du nom d’utilisateur principal.
# Connexion à partir du client de ligne de commande MySQL (non chiffrée) pour RDS for MariaDB
**Important**
N’utilisez une connexion MySQL non chiffrée que quand le client et le serveur sont dans le même VPC et que le réseau est approuvé. Pour plus d'informations sur l'utilisation de connexions chiffrées, consultez [Connexion à votre instance de base de données MariaDB sur Amazon RDS depuis le client de ligne SSL/TLS de commande MySQL (crypté)](USER_ConnectToMariaDBInstanceSSL.CLI.md).
Pour vous connecter à une instance de base de données à l'aide du client de ligne de commande MySQL, entrez la commande suivante à l'invite de commandes d'un ordinateur client. Vous êtes alors connecté à une base de données sur une instance de base de données MariaDB. Remplacez *``* par le nom DNS (point de terminaison) de votre instance de base de données et *``* par le nom d'utilisateur principal que vous avez utilisé. Indiquez le mot de passe principal que vous avez utilisé lorsque vous êtes invité à entrer un mot de passe.
```
mysql -h -P 3306 -u -p
```
Après avoir entré le mot de passe pour l'utilisateur, le résultat suivant doit normalement s'afficher.
```
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 31
Server version: 10.6.10-MariaDB-log Source distribution
Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
MariaDB [(none)]>
```
# Connexion à RDS pour MariaDB avec le pilote AWS JDBC et le pilote Python ; AWS
Connectez-vous à RDS pour les instances de base de données MariaDB à l'aide du pilote JDBC et AWS du pilote Python. AWS Pour plus d’informations, consultez les rubriques suivantes.
**Topics**
+ [
## Connexion à RDS for MariaDB avec le pilote JDBC Amazon Web Services (AWS)
](#MariaDB.Connecting.JDBCDriver)
+ [
## Connexion à RDS for MariaDB avec le pilote Python Amazon Web Services (AWS)
](#MariaDB.Connecting.PythonDriver)
## Connexion à RDS for MariaDB avec le pilote JDBC Amazon Web Services (AWS)
Le pilote JDBC Amazon Web Services (AWS) est conçu comme un wrapper JDBC avancé. Ce wrapper complète et étend les fonctionnalités d’un pilote JDBC existant. Le pilote est compatible directement avec le Connector/J pilote MySQL communautaire et le pilote communautaire MariaDB Connector/J .
Pour installer le pilote AWS JDBC, ajoutez le fichier .jar du pilote AWS JDBC (situé dans l'application`CLASSPATH`) et conservez les références au pilote communautaire correspondant. Mettez à jour le préfixe d’URL de connexion correspondant comme suit :
+ `jdbc:mysql://` sur `jdbc:aws-wrapper:mysql://`
+ `jdbc:mariadb://` sur `jdbc:aws-wrapper:mariadb://`
Pour plus d'informations sur le pilote AWS JDBC et des instructions complètes pour son utilisation, consultez le référentiel de pilotes [JDBC Amazon Web Services (AWS)](https://github.com/awslabs/aws-advanced-jdbc-wrapper). GitHub
## Connexion à RDS for MariaDB avec le pilote Python Amazon Web Services (AWS)
Le pilote Python Amazon Web Services (AWS) est conçu comme un wrapper Python avancé. Ce wrapper complète et étend les fonctionnalités du pilote open source Psycopg. Le pilote AWS Python prend en charge les versions 3.8 et ultérieures de Python. Vous pouvez installer le package `aws-advanced-python-wrapper` à l’aide de la commande `pip`, en même temps que les packages `psycopg` open source.
Pour plus d'informations sur le pilote AWS Python et des instructions complètes pour son utilisation, consultez le [ GitHub référentiel de pilotes Python Amazon Web Services (AWS)](https://github.com/awslabs/aws-advanced-python-wrapper).
# Dépannage des connexions à votre instance de base de données MariaDB
Les deux causes les plus courantes d'échec de connexion à une nouvelle instance de base de données sont :
+ L'instance de base de données a été créée grâce à un groupe de sécurité qui interdit les connexions depuis l'appareil ou l'instance Amazon EC2 où l'application ou l'utilitaire MariaDB s'exécute. L'instance de base de données doit avoir un groupe de sécurité VPC qui autorise les connexions. Pour de plus amples informations, veuillez consulter [Amazon VPC et Amazon RDS](USER_VPC.md).
Vous pouvez ajouter ou modifier une règle entrante dans le groupe de sécurité. Pour **Source**, choisissez **Mon IP**. Cela autorise à accéder à l'instance de base de données à partir de l'adresse IP détectée dans votre navigateur.
+ L'instance de base de données a été créée à l'aide du port par défaut 3306, et votre entreprise dispose de règles de pare-feu bloquant les connexions à ce port depuis les appareils de votre réseau d'entreprise. Pour corriger le problème, recréez l'instance avec un port différent.
Pour plus d’informations sur les problèmes de connexion, consultez [Impossible de se connecter à l’instance de base de données Amazon RDS](CHAP_Troubleshooting.md#CHAP_Troubleshooting.Connecting).
# Sécurisation des connexions d'instance de base de données MariaDB
Vous pouvez gérer la sécurité de vos instances de base de données MariaDB.
**Topics**
+ [
# Sécurité MariaDB sur Amazon RDS
](MariaDB.Concepts.UsersAndPrivileges.md)
+ [
# Utilisation des plugins de validation de mot de passe pour RDS for MariaDB
](MariaDB.Concepts.PasswordValidationPlugins.md)
+ [
# Chiffrement des connexions client avec les instances SSL/TLS de base de données MariaDB sur Amazon RDS
](mariadb-ssl-connections.md)
+ [
# Mise à jour des applications pour se connecter aux instances MariaDB à l'aide de nouveaux certificats SSL/TLS
](ssl-certificate-rotation-mariadb.md)
# Sécurité MariaDB sur Amazon RDS
La sécurité des instances de base de données MariaDB est gérée à trois niveaux :
+ Gestion des identités et des accès AWS contrôle les personnes autorisées à exécuter des actions de gestion Amazon RDS sur des instances de base de données. Lorsque vous vous connectez à AWS en utilisant les informations d'identification IAM, votre compte IAM doit disposer des stratégies IAM qui accordent les autorisations requises pour exécuter les opérations de gestion d'Amazon RDS. Pour plus d’informations, consultez [Identity and Access Management pour Amazon RDS](UsingWithRDS.IAM.md).
+ Lorsque vous créez une instance de base de données, vous utilisez un groupe de sécurité VPC pour contrôler les appareils et les instances Amazon EC2 qui peuvent ouvrir des connexions au point de terminaison et au port de l'instance de base de données. Ces connexions peuvent être établies en utilisant le protocole SSL (Secure Socket Layer) et le protocole TLS (Transport Layer Security). En outre, les règles de pare-feu de votre entreprise peuvent contrôler si les appareils en cours d’exécution dans votre entreprise peuvent ouvrir des connexions à l’instance de base de données.
+ Une fois qu'une connexion a été ouverte sur une instance de base de données MariaDB, l'authentification de la connexion et les autorisations sont appliquées de la même manière que dans une instance autonome de MariaDB. Les commandes telles que `CREATE USER`, `RENAME USER`, `GRANT`, `REVOKE` et `SET PASSWORD` fonctionnent de la même façon que dans les bases de données autonomes, comme le fait la modification directe des tables du schéma de base de données.
Lorsque vous créez une instance de base de données Amazon RDS, l'utilisateur principal a les privilèges par défaut suivants :
+ `alter`
+ `alter routine`
+ `create`
+ `create routine`
+ `create temporary tables`
+ `create user`
+ `create view`
+ `delete`
+ `drop`
+ `event`
+ `execute`
+ `grant option`
+ `index`
+ `insert`
+ `lock tables`
+ `process`
+ `references`
+ `reload`
Ce privilège est limité sur les instances de base de données MariaDB. Il n’autorise pas l’accès aux opérations `FLUSH LOGS` ou `FLUSH TABLES WITH READ LOCK`.
+ `replication client`
+ `replication slave`
+ `select`
+ `show create routine`
Ce privilège s’applique uniquement aux instances de base de données MariaDB exécutant la version 11.4 et supérieure.
+ `show databases`
+ `show view`
+ `trigger`
+ `update`
Pour plus d'informations sur ces privilèges, consultez [Gestion des comptes d'utilisateur](http://mariadb.com/kb/en/mariadb/grant/) dans la documentation MariaDB.
**Note**
Bien que vous puissiez supprimer l'utilisateur principal sur une instance de base de données, il est déconseillé d'agir ainsi. Pour recréer l'utilisateur maître, utilisez l'API `ModifyDBInstance` ou l'outil de ligne de commande `modify-db-instance` AWS CLI et spécifiez un nouveau mot de passe utilisateur maître avec le paramètre approprié. Si l'utilisateur maître n'existe pas dans l'instance, il est créé avec le mot de passe spécifié.
Pour fournir des services de gestion à chaque instance de base de données, l'utilisateur `rdsadmin` est créé lors de la création de l'instance de base de données. Les tentatives de supprimer, renommer et modifier le mot de passe du compte `rdsadmin`, ou d'en modifier les privilèges, génèrent une erreur.
Pour autoriser la gestion de l'instance de base de données, les commandes standard `kill` et `kill_query` ont fait l'objet de restrictions. Les commandes Amazon RDS `mysql.rds_kill`, `mysql.rds_kill_query` et `mysql.rds_kill_query_id` sont fournies pour être utilisées dans MariaDB et dans MySQL également, de telle sorte que vous puissiez mettre fin aux sessions utilisateur ou aux requêtes sur les instances de base de données.
# Utilisation des plugins de validation de mot de passe pour RDS for MariaDB
À partir de la version 11.4 de RDS for MariaDB, vous pouvez utiliser les plugins de validation de mot de passe suivants pour améliorer la sécurité de vos connexions à la base de données :
+ [simple\$1password\$1check](https://mariadb.com/kb/en/simple-password-check-plugin/) : vérifie si un mot de passe contient au moins un certain nombre de caractères d’un type spécifique.
+ [cracklib\$1password\$1check](https://mariadb.com/kb/en/cracklib_password_check/) — vérifie si un mot de passe apparaît dans un fichier de dictionnaire de la bibliothèque. [CrackLib](https://github.com/cracklib/cracklib)
Pour activer ces plugins, définissez la valeur du paramètre `simple_password_check` ou `cracklib_password_check` sur `FORCE_PLUS_PERMANENT` dans le groupe de paramètres de base de données associé à l’instance de base de données. Lorsque cette valeur est définie, le plugin ne peut pas être désinstallé à l’aide de l’instruction `UNINSTALL PLUGIN` au moment de l’exécution.
Pour désactiver ces plugins, définissez la valeur du paramètre `simple_password_check` ou `cracklib_password_check` sur `OFF` dans le groupe de paramètres de base de données associé à l’instance de base de données. Lorsque cette valeur est définie, les règles de validation du plugin ne s’appliquent plus aux nouveaux mots de passe.
Pour plus d’informations sur la définition des valeurs de paramètres dans les groupes de paramètres, consultez [Modification de paramètres dans un groupe de paramètres de base de données dans Amazon RDS](USER_WorkingWithParamGroups.Modifying.md).
# Chiffrement des connexions client avec les instances SSL/TLS de base de données MariaDB sur Amazon RDS
Secure Sockets Layer (SSL) est un protocole de norme industrielle utilisé pour sécuriser les connexions réseau entre client et serveur. Après la version 3.0 de SSL, le nom du protocole est devenu Transport Layer Security (TLS). Amazon RDS prend en charge le SSL/TLS chiffrement pour les instances de base de données MariaDB. L'utilisation SSL/TLS, you can encrypt a connection between your application client and your MariaDB DB instance. SSL/TLS du support est disponible dans tous les pays Régions AWS.
Avec Amazon RDS, vous pouvez sécuriser les données en transit en chiffrant les connexions client aux instances de base de données MariaDB avec le chiffrement SSL/TLS, requiring SSL/TLS for all connections to a MariaDB DB instance, and connecting from the MySQL command-line client with SSL/TLS (encrypted). The following sections provide guidance on configuring and utilizing SSL/TLS pour les instances de base de données MariaDB sur Amazon RDS.
**Topics**
+ [
# Prise en charge de SSL/TLS pour les instances de base de données MariaDB sur Amazon RDS
](MariaDB.Concepts.SSLSupport.md)
+ [
# Exiger des comptes utilisateur spécifiques SSL/TLS pour une instance de base de données MariaDB sur Amazon RDS
](MariaDB-ssl-connections.require-ssl-users.md)
+ [
# Exiger toutes SSL/TLS les connexions à une instance de base de données MariaDB sur Amazon RDS
](mariadb-ssl-connections.require-ssl.md)
+ [
# Connexion à votre instance de base de données MariaDB sur Amazon RDS depuis le client de ligne SSL/TLS de commande MySQL (crypté)
](USER_ConnectToMariaDBInstanceSSL.CLI.md)
# Prise en charge de SSL/TLS pour les instances de base de données MariaDB sur Amazon RDS
Amazon RDS crée un SSL/TLS certificat et l'installe sur l'instance de base de données lorsqu'Amazon RDS approvisionne l'instance. Ces certificats sont signés par une autorité de certification. Le SSL/TLS certificat inclut le point de terminaison de l'instance de base de données comme nom commun (CN) du SSL/TLS certificat afin de se prémunir contre les attaques par usurpation d'identité.
Un SSL/TLS certificat créé par Amazon RDS est l'entité racine fiable et devrait fonctionner dans la plupart des cas, mais il peut échouer si votre application n'accepte pas les chaînes de certificats. Si votre application ne les accepte pas, vous devrez peut-être utiliser un certificat intermédiaire pour vous connecter à votre Région AWS. Par exemple, vous devez utiliser un certificat intermédiaire pour vous connecter aux AWS GovCloud (US) régions avec SSL/TLS.
Pour plus d’informations sur le téléchargement de certificats, consultez [](UsingWithRDS.SSL.md). Pour plus d'informations sur l'utilisation SSL/TLS de MySQL, consultez[Mise à jour des applications pour se connecter aux instances MariaDB à l'aide de nouveaux certificats SSL/TLS](ssl-certificate-rotation-mariadb.md).
Amazon RDS for MariaDB prend en charge les versions 1.3, 1.2, 1.1 et 1.0 du protocole TLS (Transport Layer Security). La prise en charge du protocole TLS dépend de la version mineure de MariaDB. Le tableau suivant affiche la prise en charge du protocole TLS pour les versions mineures de MariaDB.
| Version de TLS | MariaDB 11.8 | MariaDB 11.4 | MariaDB 10.11 | MariaDB 10.6 | MariaDB 10.5 | MariaDB 10.4 |
| --- | --- | --- | --- | --- | --- | --- |
| TLS 1.3 | Toutes les versions mineures | Toutes les versions mineures | Toutes les versions mineures | Toutes les versions mineures | Toutes les versions mineures | Toutes les versions mineures |
| TLS 1.2 | Toutes les versions mineures | Toutes les versions mineures | Toutes les versions mineures | Toutes les versions mineures | Toutes les versions mineures | Toutes les versions mineures |
| TLS 1.1 | Non pris en charge | Non pris en charge | Non pris en charge | 10.6.16 et versions antérieures | 10.5.23 et versions antérieures | 10.4.32 et versions antérieures |
| TLS 1.0 | Non pris en charge | Non pris en charge | Non pris en charge | 10.6.16 et versions antérieures | 10.5.23 et versions antérieures | 10.4.32 et versions antérieures |
# Exiger des comptes utilisateur spécifiques SSL/TLS pour une instance de base de données MariaDB sur Amazon RDS
Vous pouvez exiger SSL/TLS le chiffrement pour les connexions de compte utilisateur spécifiées à vos instances de base de données MariaDB sur Amazon RDS. La protection des informations sensibles contre tout accès non autorisé ou toute interception est essentielle pour appliquer les politiques de sécurité, lorsque la confidentialité des données est une préoccupation.
Pour exiger des SSL/TLS connexions pour des comptes d'utilisateurs spécifiques, utilisez l'une des instructions suivantes, en fonction de votre version de MySQL, pour exiger SSL/TLS des connexions sur le compte utilisateur`encrypted_user`.
Pour cela, utilisez l’instruction suivante.
```
ALTER USER 'encrypted_user'@'%' REQUIRE SSL;
```
Pour plus d'informations sur SSL/TLS les connexions avec MariaDB, [consultez la section Sécurisation des connexions pour le client et](https://mariadb.com/kb/en/securing-connections-for-client-and-server/) le serveur dans la documentation de MariaDB.
# Exiger toutes SSL/TLS les connexions à une instance de base de données MariaDB sur Amazon RDS
Utilisez le paramètre `require_secure_transport` pour exiger que toutes les connexions des utilisateurs à votre instance de base de données MariaDB utilisent SSL/TLS. Pour les versions 11.4 et antérieures, le paramètre `require_secure_transport` est défini sur `OFF` par défaut. Pour les versions 11.8 et ultérieures, la valeur par défaut est définie sur`ON`, ce qui s'applique SSL/TLS aux connexions à votre instance de base de données. Vous pouvez modifier le paramètre `require_secure_transport` sur `OFF` pour indiquer si des connexions non sécurisées sont nécessaires.
**Note**
Le paramètre `require_secure_transport` est uniquement prise en charge pour MariaDB versions 10.5 et ultérieures.
Vous pouvez définir la valeur du paramètre `require_secure_transport` en mettant à jour le groupe de paramètres de base de données pour votre instance de base de données. Vous n'avez pas besoin de redémarrer votre instance de base de données pour que la modification prenne effet.
Lorsque le paramètre `require_secure_transport` est défini sur `ON` pour une instance de base de données, un client de base de données peut s'y connecter s'il peut établir une connexion chiffrée. Sinon, un message d’erreur similaire au suivant est renvoyé au client :
```
ERROR 1045 (28000): Access denied for user 'USER'@'localhost' (using password: YES | NO)
```
Pour plus d’informations sur la définition des paramètres, consultez [Modification de paramètres dans un groupe de paramètres de base de données dans Amazon RDS](USER_WorkingWithParamGroups.Modifying.md).
Pour plus d'informations sur le paramètre `require_secure_transport`, consultez la [documentation MariaDB](https://mariadb.com/docs/ent/ref/mdb/system-variables/require_secure_transport/).
# Connexion à votre instance de base de données MariaDB sur Amazon RDS depuis le client de ligne SSL/TLS de commande MySQL (crypté)
Les paramètres du programme client `mysql` sont légèrement différents selon que vous utilisez la version MySQL 5.7, la version MySQL 8.0 ou la version MariaDB.
Pour savoir quelle version vous avez, exécutez la commande `mysql` avec l'option `--version`. Dans l'exemple suivant, la sortie indique que le programme client provient de MariaDB.
```
$ mysql --version
mysql Ver 15.1 Distrib 10.5.15-MariaDB, for osx10.15 (x86_64) using readline 5.1
```
La plupart des distributions Linux, telles qu'Amazon Linux, CentOS, SUSE et Debian, ont remplacé MySQL par MariaDB, et la version de `mysql` qu'elles contiennent provient de MariaDB.
Pour vous connecter à votre instance de base de données en utilisant SSL/TLS, procédez comme suit :
**Pour vous connecter à une instance de base de données à SSL/TLS l'aide du client de ligne de commande MySQL**
1. Téléchargez un certificat racine qui fonctionne pour tous Régions AWS.
Pour plus d’informations sur le téléchargement de certificats, consultez [](UsingWithRDS.SSL.md).
1. Utilisez un client de ligne de commande MySQL pour vous connecter à une instance de base de données avec chiffrement SSL/TLS. Pour le paramètre `-h`, remplacez le nom DNS (point de terminaison) de votre instance de base de données. Remplacez le `--ssl-ca` paramètre par le nom du fichier de SSL/TLS certificat. Pour le paramètre `-P`, remplacez le port pour votre instance de base de données. Pour le paramètre `-u`, remplacez le nom d'utilisateur d'un utilisateur de base de données valide, par exemple l'utilisateur principal. Entrez le mot de passe de l'utilisateur principal quand vous y êtes invité.
L'exemple suivant montre comment lancer le client à l'aide du paramètre `--ssl-ca` en utilisant le client MariaDB.
```
mysql -h mysql–instance1.123456789012.us-east-1.rds.amazonaws.com --ssl-ca=global-bundle.pem --ssl -P 3306 -u myadmin -p
```
Pour exiger que la SSL/TLS connexion vérifie le point de terminaison de l'instance de base de données par rapport au point de terminaison indiqué dans le SSL/TLS certificat, entrez la commande suivante :
```
mysql -h mysql–instance1.123456789012.us-east-1.rds.amazonaws.com --ssl-ca=global-bundle.pem --ssl-verify-server-cert -P 3306 -u myadmin -p
```
L'exemple suivant montre comment lancer le client à l'aide du paramètre `--ssl-ca` en utilisant le client MySQL 5.7 ou version ultérieure.
```
mysql -h mysql–instance1.123456789012.us-east-1.rds.amazonaws.com --ssl-ca=global-bundle.pem --ssl-mode=REQUIRED -P 3306 -u myadmin -p
```
1. Entrez le mot de passe de l'utilisateur principal quand vous y êtes invité.
Vous devez visualiser des résultats similaires à ce qui suit.
```
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 31
Server version: 10.6.10-MariaDB-log Source distribution
Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
MariaDB [(none)]>
```
# Mise à jour des applications pour se connecter aux instances MariaDB à l'aide de nouveaux certificats SSL/TLS
Le 13 janvier 2023, Amazon RDS a publié de nouveaux certificats d'autorité de certification (CA) pour la connexion à vos instances de base de données RDS à l'aide du protocole Secure Socket Layer ou Transport Layer Security (SSL/TLS). Vous trouverez ci-après des informations sur la mise à jour de vos applications afin d’utiliser les nouveaux certificats.
Cette rubrique peut vous aider à déterminer si vos applications nécessitent une vérification du certificat pour se connecter à vos instances de bases de données.
**Note**
Certaines applications sont configurées pour se connecter à MariaDB uniquement si la vérification du certificat sur le serveur s'effectue avec succès. Pour ces applications, vous devez mettre à jour les magasins d'approbations des applications clientes afin d'inclure les nouveaux certificats de l'autorité de certification.
Vous pouvez spécifier les modes SSL suivants : `disabled`, `preferred` et `required`. Lorsque vous utilisez le mode `preferred` SSL et que le certificat de l'autorité de certification n'existe pas ou n'est pas à jour, la connexion n'utilise plus SSL et s'établit toujours avec succès.
Nous recommandons d'éviter le mode `preferred`. En mode `preferred`, si la connexion rencontre un certificat non valide, elle cesse d'utiliser le chiffrement et continue sans chiffrement.
Une fois que vous avez mis à jour les certificats de l'autorité de certification dans les magasins d'approbations des applications clientes, vous pouvez soumettre les certificats de vos instances de bases de données à une rotation. Nous vous recommandons vivement de tester ces procédures dans un environnement de développement ou intermédiaire avant de les implémenter dans vos environnements de production.
Pour plus d’informations sur la rotation de certificats, consultez [Rotation de votre SSL/TLS certificat](UsingWithRDS.SSL-certificate-rotation.md). Pour en savoir plus sur le téléchargement de certificats, consultez [](UsingWithRDS.SSL.md). Pour plus d'informations sur l'utilisation SSL/TLS avec les instances de base de données MariaDB, consultez. [Prise en charge de SSL/TLS pour les instances de base de données MariaDB sur Amazon RDS](MariaDB.Concepts.SSLSupport.md)
**Topics**
+ [
## Contrôle de la nécessité d’une vérification du certificat du client pour qu’il puisse se connecter
](#ssl-certificate-rotation-mariadb.determining)
+ [
## Mise à jour du magasin d'approbations de votre application
](#ssl-certificate-rotation-mariadb.updating-trust-store)
+ [
## Exemple de code Java pour l'établissement de connexions SSL
](#ssl-certificate-rotation-mariadb.java-example)
## Contrôle de la nécessité d’une vérification du certificat du client pour qu’il puisse se connecter
Vous pouvez vérifier si les clients JDBC et les clients MySQL requièrent une vérification du certificat pour pouvoir se connecter.
### JDBC
L'exemple suivant avec MySQL Connector/J 8.0 montre une façon de vérifier les propriétés de connexion JDBC d'une application afin de déterminer si les connexions réussies nécessitent un certificat valide. Pour plus d’informations sur l’ensemble des options de connexion JDBC pour MySQL, consultez [Configuration Properties](https://dev.mysql.com/doc/connector-j/en/connector-j-reference-configuration-properties.html) dans la documentation MySQL.
Lorsque vous utilisez MySQL Connector/J 8.0, une connexion SSL doit être vérifiée par rapport au certificat CA du serveur si les propriétés de votre connexion sont `sslMode` définies sur `VERIFY_CA` ou`VERIFY_IDENTITY`, comme dans l'exemple suivant.
```
Properties properties = new Properties();
properties.setProperty("sslMode", "VERIFY_IDENTITY");
properties.put("user", DB_USER);
properties.put("password", DB_PASSWORD);
```
**Note**
Si vous utilisez le MySQL Java Connector v5.1.38 ou version ultérieure, ou le MySQL Java Connector v8.0.9 ou version ultérieure pour vous connecter à vos bases de données, même si vous n'avez pas explicitement configuré vos applications pour vous connecter à vos bases de données, ces pilotes clients sont utilisés SSL/TLS par défautSSL/TLS. In addition, when using SSL/TLS, ils effectuent une vérification partielle du certificat et ne se connectent pas si le certificat du serveur de base de données est expiré.
Spécifiez un mot de passe autre que celui indiqué ici, en tant que bonne pratique de sécurité.
### MySQL
Les exemples suivants avec le client MySQL montrent deux façons de vérifier la connexion MySQL d'un script pour déterminer si les connexions nécessitent un certificat valide pour réussir. Pour de plus amples informations sur l'ensemble des options de connexion avec le client MySQL, veuillez consulter [Client-Side Configuration for Encrypted Connections](https://dev.mysql.com/doc/refman/en/using-encrypted-connections.html#using-encrypted-connections-client-side-configuration) dans la documentation MySQL.
Lorsque vous utilisez MySQL 5.7 or MySQL 8.0, une connexion SSL nécessite la vérification du certificat de l'autorité de certification sur le serveur si pour l'option `--ssl-mode`, vous spécifiez `VERIFY_CA` ou `VERIFY_IDENTITY`, comme illustré dans l'exemple suivant.
```
mysql -h mysql-database.rds.amazonaws.com -uadmin -ppassword --ssl-ca=/tmp/ssl-cert.pem --ssl-mode=VERIFY_CA
```
Lorsque vous utilisez le client MySQL 5.6, une connexion SSL nécessite la vérification du certificat de l'autorité de certification sur le serveur si vous spécifiez l'option `--ssl-verify-server-cert`, comme illustré dans l'exemple suivant.
```
mysql -h mysql-database.rds.amazonaws.com -uadmin -ppassword --ssl-ca=/tmp/ssl-cert.pem --ssl-verify-server-cert
```
## Mise à jour du magasin d'approbations de votre application
Pour plus d'informations sur la mise à jour du trust store pour les applications MySQL, consultez la section [Utilisation TLS/SSL avec MariaDB Connector/J dans la documentation de MariaDB](https://mariadb.com/kb/en/library/using-tls-ssl-with-mariadb-java-connector/).
Pour plus d’informations sur le téléchargement du certificat racine, consultez [](UsingWithRDS.SSL.md).
Pour obtenir des exemples de scripts qui importent des certificats, consultez [Exemple de script pour importer les certificats dans votre magasin d’approbations](UsingWithRDS.SSL-certificate-rotation.md#UsingWithRDS.SSL-certificate-rotation-sample-script).
**Note**
Lors de la mise à jour du magasin d’approbations, vous pouvez conserver les certificats plus anciens en complément de l’ajout des nouveaux certificats.
Si vous utilisez le pilote JDBC Connector/J MariaDB dans une application, définissez les propriétés suivantes dans l'application.
```
System.setProperty("javax.net.ssl.trustStore", certs);
System.setProperty("javax.net.ssl.trustStorePassword", "password");
```
Lorsque vous démarrez l'application, définissez les propriétés suivantes.
```
java -Djavax.net.ssl.trustStore=/path_to_truststore/MyTruststore.jks -Djavax.net.ssl.trustStorePassword=my_truststore_password com.companyName.MyApplication
```
**Note**
Spécifiez des mots de passe autres que ceux indiqués ici, en tant que bonne pratique de sécurité.
## Exemple de code Java pour l'établissement de connexions SSL
L’exemple de code suivant montre comment configurer la connexion SSL à l’aide de JDBC.
```
private static final String DB_USER = "admin";
private static final String DB_USER = "user name";
private static final String DB_PASSWORD = "password";
// This key store has only the prod root ca.
private static final String KEY_STORE_FILE_PATH = "file-path-to-keystore";
private static final String KEY_STORE_PASS = "keystore-password";
public static void main(String[] args) throws Exception {
Class.forName("org.mariadb.jdbc.Driver");
System.setProperty("javax.net.ssl.trustStore", KEY_STORE_FILE_PATH);
System.setProperty("javax.net.ssl.trustStorePassword", KEY_STORE_PASS);
Properties properties = new Properties();
properties.put("user", DB_USER);
properties.put("password", DB_PASSWORD);
Connection connection = DriverManager.getConnection("jdbc:mysql://ssl-mariadb-public.cni62e2e7kwh.us-east-1.rds.amazonaws.com:3306?useSSL=true",properties);
Statement stmt=connection.createStatement();
ResultSet rs=stmt.executeQuery("SELECT 1 from dual");
return;
}
```
**Important**
Une fois que vous avez déterminé que vos connexions à la base de données utilisent SSL/TLS et que vous avez mis à jour votre magasin de confiance d'applications, vous pouvez mettre à jour votre base de données pour utiliser les certificats rds-ca-rsa 2048-g1. Pour obtenir des instructions, consultez l’étape 3 dans [Mise à jour de votre certificat CA en modifiant votre instance de base de données ou votre cluster](UsingWithRDS.SSL-certificate-rotation.md#UsingWithRDS.SSL-certificate-rotation-updating).
Spécifiez un mot de passe autre que celui indiqué ici, en tant que bonne pratique de sécurité.
# Amélioration des performances des requêtes pour RDS for MariaDB avec Lectures optimisées pour Amazon RDS
Vous pouvez accélérer le traitement des requêtes pour RDS for MariaDB avec Amazon RDS Optimized Reads. Une instance de base de données RDS for MariaDB qui utilise RDS Optimized Reads peut traiter les requêtes jusqu'à 2 fois plus rapidement qu'une instance de base de données qui ne l'utilise pas.
**Topics**
+ [
## Présentation de RDS Optimized Reads
](#rds-optimized-reads-mariadb-overview)
+ [
## Cas d'utilisation pour RDS Optimized Reads
](#rds-optimized-reads-mariadb-use-cases)
+ [
## Bonnes pratiques relatives à RDS Optimized Reads
](#rds-optimized-reads-mariadb-best-practices)
+ [
## Utilisation de RDS Optimized Reads
](#rds-optimized-reads-mariadb-using)
+ [
## Surveillance des instances de base de données qui utilisent RDS Optimized Reads
](#rds-optimized-reads-mariadb-monitoring)
+ [
## Limites pour RDS Optimized Reads
](#rds-optimized-reads-mariadb-limitations)
## Présentation de RDS Optimized Reads
Lorsque vous utilisez une instance de base de données RDS for MariaDB sur laquelle RDS Optimized Reads est activé, votre instance de base de données présente des performances de requête plus rapides grâce à l'utilisation d'un stockage d'instances. Un *stockage d'instance* fournit un stockage temporaire de niveau bloc pour votre instance de base de données. Le stockage est situé sur des disques SSD Non-Volatile Memory Express (NVMeSSDs) connectés physiquement au serveur hôte. Ce stockage est optimisé pour une faible latence, des I/O performances aléatoires élevées et un débit de lecture séquentiel élevé.
RDS Optimized Reads est activé par défaut lorsqu'une instance de base de données utilise une classe d'instances de base de données avec un stockage d'instances, tel que db.m5d ou db.m6gd. Avec RDS Optimized Reads, certains objets temporaires sont stockés dans le stockage d'instances. Ces objets temporaires incluent des fichiers temporaires internes, des tables temporaires internes sur disque, des fichiers de mappage de mémoire et des fichiers de cache de journal binaire (binlog). Pour plus d'informations sur le magasin d'instances, consultez le [magasin d' EC2instances Amazon](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/InstanceStorage.html) dans le *guide de l'utilisateur Amazon Elastic Compute Cloud pour les instances Linux*.
Les charges de travail qui génèrent des objets temporaires dans MariaDB pour le traitement des requêtes peuvent tirer parti du stockage d'instances pour accélérer le traitement des requêtes. Ce type de charge de travail inclut les requêtes impliquant des tris, des agrégations de hachage, des jointures à charge élevée, des expressions de table communes (CTEs) et des requêtes sur des colonnes non indexées. Ces volumes de stockage d'instances fournissent des IOPS et des performances supérieures, quelles que soient les configurations de stockage utilisées pour le stockage Amazon EBS persistant. Étant donné que RDS Optimized Reads transfère les opérations sur les objets temporaires vers le magasin d'instance, les input/output opérations par seconde (IOPS) ou le débit du stockage persistant (Amazon EBS) peuvent désormais être utilisés pour les opérations sur des objets persistants. Ces opérations incluent des lectures et des écritures régulières de fichiers de données, ainsi que des opérations de moteur en arrière-plan, telles que le vidage et la fusion de mémoires tampon par insertion.
**Note**
Les instantanés RDS manuels et automatisés ne contiennent que des fichiers de moteur pour les objets persistants. Les objets temporaires créés dans le stockage d'instances ne sont pas inclus dans les instantanés RDS.
## Cas d'utilisation pour RDS Optimized Reads
Si vous avez des charges de travail qui dépendent fortement d'objets temporaires, tels que des tables ou des fichiers internes, pour l'exécution de leurs requêtes, vous pouvez tirer parti de l'activation de RDS Optimized Reads. Les cas d'utilisation suivants sont propices à RDS Optimized Reads :
+ Applications qui exécutent des requêtes analytiques avec des expressions de table communes complexes (CTEs), des tables dérivées et des opérations de regroupement
+ Réplicas en lecture qui traitent un trafic de lecture important avec des requêtes non optimisées
+ Applications exécutant des requêtes de création de rapport à la demande ou dynamiques impliquant des opérations complexes, telles que des requêtes avec des clauses `GROUP BY` et `ORDER BY`
+ Charges de travail utilisant des tables temporaires internes pour le traitement des requêtes
Vous pouvez surveiller la variable de statut du moteur `created_tmp_disk_tables` pour déterminer le nombre de tables temporaires sur disque créées sur votre instance de base de données.
+ Applications qui créent de grandes tables temporaires, directement ou dans le cadre de procédures, pour stocker des résultats intermédiaires
+ Requêtes de base de données qui regroupent ou trient des colonnes non indexées
## Bonnes pratiques relatives à RDS Optimized Reads
Utilisez les bonnes pratiques suivantes pour RDS Optimized Reads :
+ Ajoutez une logique de nouvelle tentative pour les requêtes en lecture seule au cas où elles échoueraient en raison d'un stockage d'instances complet pendant l'exécution.
+ Surveillez l'espace de stockage disponible sur le magasin d'instances à l'aide de la CloudWatch métrique`FreeLocalStorage`. Si le stockage d'instances atteint sa limite en raison de la charge de travail sur l'instance de base de données, modifiez l'instance de base de données pour utiliser une classe d'instances de base de données plus grande.
+ Lorsque votre instance de base de données dispose de suffisamment de mémoire mais atteint toujours la limite de stockage sur le stockage d'instances, augmentez la valeur `binlog_cache_size` pour conserver en mémoire les entrées binlog spécifiques à la session. Cette configuration empêche l'écriture des entrées binlog dans les fichiers de cache binlog temporaires sur le disque.
Le paramètre `binlog_cache_size` est spécifique à la session. Vous pouvez modifier cette valeur pour chaque nouvelle session. Le réglage de ce paramètre peut augmenter l'utilisation de la mémoire sur l'instance de base de données pendant les pics de charge de travail. Par conséquent, envisagez d'augmenter la valeur du paramètre en fonction du modèle de charge de travail de votre application et de la mémoire disponible sur l'instance de base de données.
+ Utilisez la valeur par défaut `MIXED` pour `binlog_format`. En fonction de la taille des transactions, le réglage de `binlog_format` sur `ROW` peut entraîner la création de fichiers de cache binlog volumineux sur le stockage d'instances.
+ Évitez d'effectuer des modifications en bloc dans une transaction unique. Ces types de transactions peuvent générer de gros fichiers de cache binlog sur le stockage d'instances et peuvent provoquer des problèmes lorsque le stockage d'instances est plein. Envisagez de diviser les écritures en plusieurs petites transactions afin de réduire au maximum l'utilisation de l'espace de stockage pour les fichiers de cache binlog.
## Utilisation de RDS Optimized Reads
Lorsque vous provisionnez une instance de base de données RDS for MariaDB avec l'une des classes d'instances de base de données suivantes dans le cadre d'un déploiement d'instance de base de données mono-AZ ou multi-AZ, l'instance de base de données utilise automatiquement les lectures optimisées pour RDS.
Pour activer RDS Optimized Reads, effectuez l'une des actions suivantes :
+ Créez une instance de base de données RDS for MariaDB en utilisant l'une de ces classes d'instances de base de données. Pour de plus amples informations, veuillez consulter [Création d'une instance de base de données Amazon RDS](USER_CreateDBInstance.md).
+ Modifiez une instance de base de données RDS for MariaDB afin d'utiliser l'une de ces classes d'instances de base de données. Pour de plus amples informations, veuillez consulter [Modification d'une instance de base de données Amazon RDS](Overview.DBInstance.Modifying.md).
Les lectures optimisées RDS sont disponibles partout Régions AWS où une ou plusieurs classes d'instances de base de données avec stockage NVMe SSD local sont prises en charge. Pour plus d’informations sur les classes d’instance de base de données, consultez [Classes d'instances de base de données ](Concepts.DBInstanceClass.md).
La disponibilité des classes d'instances de base de données diffère pour Régions AWS. Pour déterminer si une classe d'instance de base de données est prise en charge dans une classe spécifique Région AWS, consultez[Déterminer le support des classes d'instance de base de données dans Régions AWS](Concepts.DBInstanceClass.RegionSupport.md).
Si vous ne souhaitez pas utiliser RDS Optimized Reads, modifiez votre instance de base de données afin qu'elle n'utilise pas une classe d'instances de base de données prenant en charge cette fonctionnalité.
## Surveillance des instances de base de données qui utilisent RDS Optimized Reads
Vous pouvez surveiller les instances de base de données qui utilisent des lectures optimisées RDS à l'aide des CloudWatch métriques suivantes :
+ `FreeLocalStorage`
+ `ReadIOPSLocalStorage`
+ `ReadLatencyLocalStorage`
+ `ReadThroughputLocalStorage`
+ `WriteIOPSLocalStorage`
+ `WriteLatencyLocalStorage`
+ `WriteThroughputLocalStorage`
Ces métriques fournissent des données sur le stockage disponible dans le stockage d’instances, les IOPS et le débit. Pour plus d’informations sur ces métriques, consultez [Mesures au CloudWatch niveau de l'instance Amazon pour Amazon RDS](rds-metrics.md#rds-cw-metrics-instance).
## Limites pour RDS Optimized Reads
Les limites suivantes s'appliquent à RDS Optimized Reads :
+ RDS Optimized Reads est pris en charge pour les versions RDS for MariaDB suivantes :
+ Toutes les versions mineures disponibles de 11.4 et versions majeures ultérieures
+ 10.11.4 et versions 10.11 ultérieures
+ 10.6.7 et versions 10.6 ultérieures
+ 10.5.16 et versions 10.5 ultérieures
+ 10.4.25 et versions 10.4 ultérieures
Pour obtenir des informations sur les versions de RDS for MariaDB, consultez [Versions de MariaDB sur Amazon RDS](MariaDB.Concepts.VersionMgmt.md).
+ Vous ne pouvez pas remplacer l'emplacement des objets temporaires par un stockage persistant (Amazon EBS) dans les classes d'instances de base de données qui prennent en charge RDS Optimized Reads.
+ Lorsque la journalisation binaire est activée sur une instance de base de données, la taille maximale des transactions est limitée par la taille du stockage d'instances. Pour MariaDB, toute session qui nécessite plus de stockage que la valeur de `binlog_cache_size` écrit les modifications des transactions dans les fichiers de cache de journaux binaires temporaires, qui sont créés dans le stockage d'instances.
+ Les transactions peuvent échouer lorsque le stockage d'instances est plein.
# Amélioration des performances d'écriture avec Écritures optimisées pour Amazon RDS for MariaDB
Vous pouvez améliorer les performances des transactions d'écriture avec l'option Écritures optimisées pour RDS for MariaDB. Lorsque votre base de données RDS for MariaDB utilise Écritures optimisées pour RDS, elle peut atteindre un débit de transactions d'écriture jusqu'à deux fois supérieur.
**Topics**
+ [
## Présentation de l'option Écritures optimisées pour RDS
](#rds-optimized-writes-overview)
+ [
## Utilisation de l'option Écritures optimisées pour RDS
](#rds-optimized-writes-using-mariadb)
+ [
## Activation de l'option Écritures optimisées pour RDS sur une base de données existante
](#rds-optimized-writes-modify-enable-mariadb)
+ [
## Limites pour l'option Écritures optimisées pour RDS
](#rds-optimized-writes-limitations-mariadb)
## Présentation de l'option Écritures optimisées pour RDS
Lorsque vous activez l'option Écritures optimisées pour RDS, vos bases de données RDS for MariaDB n'écrivent qu'une seule fois lors du vidage des données dans un stockage durable sans avoir besoin du tampon à double écriture. Les bases de données continuent de protéger les propriétés ACID pour les transactions de base de données fiables, ainsi que des performances améliorées.
Les bases de données relationnelles, comme MariaDB, fournissent les *propriétés ACID* d’atomicité, de cohérence, d’isolement et de durabilité pour des transactions de base de données fiables. Pour fournir ces propriétés, MariaDB utilise une zone de stockage de données appelée *tampon à double écriture* qui empêche les erreurs d'écriture de page partielles. Ces erreurs se produisent en cas de panne matérielle alors que la base de données met à jour une page, par exemple en cas de panne de courant. Une base de données MariaDB peut détecter les écritures de page partielles et récupérer une copie de la page dans le tampon à double écriture. Cette technique offre une protection, mais elle entraîne également des opérations d'écriture supplémentaires. Pour plus d'informations sur le tampon à double écriture MariaDB, consultez [Doublewrite Buffer](https://mariadb.com/kb/en/innodb-doublewrite-buffer/) (Tampon à double écriture) dans la documentation MariaDB.
Quand Écritures optimisées pour RDS est activé, les bases de données RDS for MariaDB n'écrivent qu'une seule fois lors du vidage des données dans un stockage durable sans utiliser le tampon à double écriture. Écritures optimisées pour RDS est utile si vous exécutez des charges de travail lourdes en écriture sur vos bases de données RDS for MariaDB. Parmi les bases de données soumises à de lourdes charges de travail en écriture, citons celles qui prennent en charge les paiements numériques, les transactions financières et les applications de jeu.
Ces bases de données s'exécutent sur des classes d'instances de base de données qui utilisent le système AWS Nitro. En raison de la configuration matérielle dans ces systèmes, la base de données peut écrire des pages de 16 Kio directement dans des fichiers de données de manière fiable et durable, en une seule étape. Le système AWS Nitro permet des écritures optimisées RDS.
Vous pouvez définir le nouveau paramètre de base de données `rds.optimized_writes` pour contrôler la fonction Écritures optimisées pour RDS pour les bases de données RDS for MariaDB. Accédez à ce paramètre dans les groupes de paramètres de base de données de RDS for MariaDB pour les versions suivantes :
+ Toutes les versions mineures disponibles de 11.8 et versions majeures ultérieures
+ 11.4.3 et versions 11.4 ultérieures
+ 10.11.4 et versions 10.11 ultérieures
+ 10.6.10 et versions 10.6 ultérieures
Définissez ce paramètre sur l'une des valeurs suivantes :
+ `AUTO` : activer RDS Optimized Writes si la base de données le prend en charge. Désactiver RDS Optimized Writes si la base de données ne le prend pas en charge. Il s’agit de la valeur par défaut.
+ `OFF` : désactiver l'option Écritures optimisées pour RDS même si la base de données le prend en charge.
Si vous migrez une base de données RDS for MariaDB configurée pour utiliser Écritures optimisées pour RDS dans une classe d'instances de base de données qui ne prend pas en charge cette fonctionnalité, RDS désactive automatiquement Écritures optimisées pour RDS pour la base de données.
Lorsque Écritures optimisées pour RDS est désactivé, la base de données utilise le tampon à double écriture MariaDB.
Pour déterminer si une base de données RDS for MariaDB utilise Écritures optimisées pour RDS, consultez la valeur actuelle du paramètre `innodb_doublewrite` pour la base de données. Si la base de données utilise des écritures optimisées RDS, ce paramètre est défini sur `FALSE` (`0`).
## Utilisation de l'option Écritures optimisées pour RDS
Vous pouvez activer les écritures optimisées RDS lorsque vous créez une base de données RDS pour MariaDB à l'aide de la console RDS, de l'API RDS ou de l'API RDS. AWS CLI L'option Écritures optimisées pour RDS est automatiquement activé lorsque les deux conditions suivantes s'appliquent dans le cadre de la création de la base de données :
+ Vous spécifiez une version du moteur de base de données et une classe d'instances de base de données qui prennent en charge l'option Écritures optimisées pour RDS.
+ La fonctionnalité Écritures optimisées pour RDS est prise en charge pour les versions RDS for MariaDB suivantes :
+ Toutes les versions mineures disponibles de 11.8 et versions majeures ultérieures
+ 11.4.3 et versions 11.4 ultérieures
+ 10.11.4 et versions 10.11 ultérieures
+ 10.6.10 et versions 10.6 ultérieures
Pour obtenir des informations sur les versions de RDS for MariaDB, consultez [Versions de MariaDB sur Amazon RDS](MariaDB.Concepts.VersionMgmt.md).
+ Écritures optimisées pour RDS est pris en charge pour les bases de données RDS for MariaDB qui utilisent les classes d'instances de base de données suivantes :
+ db.m7i
+ db.m7g
+ db.m6g
+ db.m6gd
+ db.m6i
+ db.m5
+ db.m5d
+ db.r7i
+ db.r7g
+ db.r6g
+ db.r6gd
+ db.r6i
+ db.r5
+ db.r5b
+ db.r5d
+ db.x2idn
+ db.x2iedn
Pour plus d’informations sur les classes d’instance de base de données, consultez [Classes d'instances de base de données ](Concepts.DBInstanceClass.md).
La disponibilité des classes d'instances de base de données diffère pour Régions AWS. Pour déterminer si une classe d'instance de base de données est prise en charge dans une classe spécifique Région AWS, consultez[Déterminer le support des classes d'instance de base de données dans Régions AWS](Concepts.DBInstanceClass.RegionSupport.md).
+ Dans le groupe de paramètres associé à la base de données, le paramètre `rds.optimized_writes` est défini sur `AUTO`. Dans les groupes de paramètres par défaut, ce paramètre est toujours défini sur `AUTO`.
Si vous voulez utiliser une version du moteur de base de données et une classe d'instances de base de données qui prennent en charge Écritures optimisées pour RDS, mais que vous ne voulez pas utiliser cette fonction, spécifiez alors un groupe de paramètres personnalisé quand vous créez la base de données. Dans le groupe de paramètres, définissez le paramètre `rds.optimized_writes` sur `OFF`. Si vous souhaitez que la base de données utilise l'option Écritures optimisées pour RDS ultérieurement, vous pouvez définir ce paramètre sur `AUTO` pour l'activer. Pour obtenir des informations sur la création des groupes de paramètres personnalisés et sur la définition des paramètres, consultez [Groupes de paramètres pour Amazon RDS](USER_WorkingWithParamGroups.md).
Pour plus d’informations sur la création d’une instance de base de données, consultez [Création d'une instance de base de données Amazon RDS](USER_CreateDBInstance.md).
### Console
Lorsque vous utilisez la console RDS pour créer une base de données RDS for MariaDB, vous pouvez filtrer les versions du moteur de base de données et les classes d'instances de base de données qui prennent en charge Écritures optimisées pour RDS. Après avoir activé les filtres, vous pouvez choisir parmi les versions du moteur de base de données et les classes d'instances de base de données disponibles.
Pour choisir une version du moteur de base de données prenant en charge RDS Optimized Writes, filtrez les versions du moteur de base de données RDS for MariaDB qui le prennent en charge dans **Engine version** (Version du moteur), puis choisissez une version.
![\[La section des Options de moteur avec le filtre Écritures optimisées pour Amazon RDS activé pour la Version du moteur.\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/rds-optimized-writes-version-filter-mariadb.png)
Dans la section **Instance configuration** (Configuration de l'instance), filtrez les classes d'instances de base de données qui prennent en charge l'option Écritures optimisées pour RDS, puis choisissez une classe d'instances de base de données.
![\[La section Configuration de l’instance avec le filtre Écritures optimisées pour Amazon RDS activé pour la classe d’instance de base de données.\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/rds-optimized-writes-class-filter.png)
Après avoir effectué ces sélections, vous pouvez choisir d'autres paramètres qui répondent à vos besoins et terminer la création de la base de données RDS for MariaDB à l'aide de la console.
### AWS CLI
Pour créer une instance de base de données à l'aide de AWS CLI, exécutez la [create-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html)commande. Veillez à ce que les valeurs `--engine-version` et `--db-instance-class` prennent en charge RDS Optimized Writes. De plus, veillez à ce que le paramètre `rds.optimized_writes` du groupe de paramètres associé à l'instance de base de données soit défini sur `AUTO`. Cet exemple associe le groupe de paramètres par défaut à l'instance de base de données.
**Example Création d'une instance de base de données qui utilise RDS Optimized Writes**
Pour Linux, macOS ou Unix :
```
1. aws rds create-db-instance \
2. --db-instance-identifier mydbinstance \
3. --engine mariadb \
4. --engine-version 10.6.10 \
5. --db-instance-class db.r5b.large \
6. --manage-master-user-password \
7. --master-username admin \
8. --allocated-storage 200
```
Pour Windows :
```
1. aws rds create-db-instance ^
2. --db-instance-identifier mydbinstance ^
3. --engine mariadb ^
4. --engine-version 10.6.10 ^
5. --db-instance-class db.r5b.large ^
6. --manage-master-user-password ^
7. --master-username admin ^
8. --allocated-storage 200
```
### API RDS
Vous pouvez créer une instance de base de données à l'aide de l'DBInstanceopération [Create](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html). Quand vous utilisez cette opération, veillez à ce que les valeurs `EngineVersion` et `DBInstanceClass` prennent en charge RDS Optimized Writes. De plus, veillez à ce que le paramètre `rds.optimized_writes` du groupe de paramètres associé à l'instance de base de données soit défini sur `AUTO`.
## Activation de l'option Écritures optimisées pour RDS sur une base de données existante
Pour modifier une base de données RDS for MariaDB existante afin d'activer l'option Écritures optimisées pour RDS, la base de données doit avoir été créée avec une version du moteur de base de données et une classe d'instance de base de données prises en charge. En outre, la base de données doit avoir été créée *après* la publication de l'option Écritures optimisées pour RDS le 7 mars 2023, car la configuration requise du système de fichiers sous-jacent est incompatible avec celle des bases de données créées avant sa publication. Si ces conditions sont remplies, vous pouvez activer l'option Écritures optimisées pour RDS en définissant le paramètre `rds.optimized_writes` sur `AUTO`.
Si votre base de données *n'a pas* été créée avec une version de moteur, une classe d'instance ou une configuration de système de fichiers prise en charge, vous pouvez utiliser les Blue/Green déploiements RDS pour migrer vers une configuration prise en charge. Lors de la création du blue/green déploiement, procédez comme suit :
+ Sélectionnez **Activer l'option Écritures optimisées pour RDS sur une base de données verte**, puis spécifiez une version du moteur et une classe d'instance de base de données qui prennent en charge l'option Écritures optimisées pour RDS. Pour obtenir la liste des versions de moteur et des classes d'instance prises en charge, consultez [Utilisation de l'option Écritures optimisées pour RDS](#rds-optimized-writes-using-mariadb).
+ Sous **Stockage**, choisissez **Mettre à niveau la configuration du système de fichiers de stockage**. Cette option met à niveau la base de données vers une configuration de système de fichiers sous-jacent compatible.
Lorsque vous créez le blue/green déploiement, si le `rds.optimized_writes` paramètre est défini sur`AUTO`, les écritures optimisées RDS seront automatiquement activées dans l'environnement vert. Vous pouvez ensuite passer au blue/green déploiement, ce qui fait de l'environnement vert le nouvel environnement de production.
Pour de plus amples informations, veuillez consulter [Création d'un blue/green déploiement dans Amazon RDS ( Aurora)](blue-green-deployments-creating.md).
## Limites pour l'option Écritures optimisées pour RDS
Lorsque vous restaurez une base de données RDS for MariaDB à partir d'un instantané, vous pouvez activer l'option Écritures optimisées pour RDS pour cette base de données seulement si toutes les conditions suivantes s'appliquent :
+ L'instantané a été créé à partir d'une base de données qui prend en charge RDS Optimized Writes.
+ L'instantané a été créé à partir d'une base de données qui a été créée *après* le lancement d'Écritures optimisées pour RDS.
+ L'instantané est restauré en une base de données qui prend en charge RDS Optimized Writes.
+ La base de données restaurée est associée à un groupe de paramètres où le paramètre `rds.optimized_writes` est défini sur `AUTO`.
# Mises à niveau du moteur de base de données MariaDB
Lorsque Amazon RDS prend en charge une nouvelle version d'un moteur de base de données, vous pouvez mettre à niveau vos instances de base de données vers cette nouvelle version. Il existe deux types de mises à niveau pour les instances de base de données MariaDB : les mises à niveau de version majeure et les mises à niveau de version mineure.
Les *mises à niveau de version majeure* peuvent contenir des modifications de base de données qui ne sont pas rétrocompatibles avec les applications existantes. En conséquence, vous devez effectuer manuellement les mises à niveau des versions majeures de vos instances de base de données. Vous pouvez lancer une mise à niveau de version majeure en modifiant votre instance de base de données. Cependant, avant d’effectuer une mise à niveau de version majeure, nous vous recommandons de suivre les instructions décrites dans [Mises à niveau des versions majeures pour RDS for MariaDB](USER_UpgradeDBInstance.MariaDB.Major.md).
En revanche, une *mise à niveau de version mineure* contient uniquement des modifications rétrocompatibles avec les applications existantes. Vous pouvez lancer manuellement une mise à niveau de version mineure en modifiant votre instance de base de données. Vous pouvez également activer l’option **Mise à niveau automatique des versions mineures** lorsque vous créez ou modifiez une instance de base de données. Dans ce cas, votre instance de base de données est automatiquement mise à niveau une fois que Amazon RDS a testé et approuvé la nouvelle version. Pour de plus amples informations sur la mise à niveau, veuillez consulter [Mise à niveau d'une version du moteur d'une instance de base de données](USER_UpgradeDBInstance.Upgrading.md).
Si votre instance de base de données MariaDB utilise des réplicas en lecture, vous devez mettre à niveau tous les réplicas en lecture avant de mettre à niveau l’instance source. Si votre instance de base de données se trouve dans un déploiement Multi-AZ, les deux réplicas, enregistreur et de secours, sont mis à niveau. Votre instance de base de données peut ne pas être disponible tant que la mise à niveau n’est pas terminée.
Pour plus d’informations sur les versions MariaDB prises en charge et la gestion des versions, consultez [Versions de MariaDB sur Amazon RDS](MariaDB.Concepts.VersionMgmt.md).
Les mises à niveau du moteur de base de données nécessitent un temps d'arrêt. La durée du temps d'arrêt varie en fonction de la taille de votre instance de base de données.
Amazon RDS prend également en charge la politique de déploiement des mises à niveau afin de gérer les mises à niveau automatiques des versions mineures sur plusieurs ressources de base de données et. Comptes AWS Pour de plus amples informations, veuillez consulter [Utilisation de la politique de déploiement des mises à AWS Organizations niveau pour les mises à niveau automatiques des versions mineures](RDS.Maintenance.AMVU.UpgradeRollout.md).
**Astuce**
Vous pouvez minimiser le temps d'arrêt requis pour la mise à niveau d'une instance de base de données en utilisant un blue/green déploiement. Pour de plus amples informations, veuillez consulter [Utilisation d'Amazon RDS ( Blue/Green Deployments) pour les mises à jour de bases de données](blue-green-deployments.md).
**Topics**
+ [
## Considérations relatives aux mises à niveau de MariaDB
](#USER_UpgradeDBInstance.MariaDB.Considerations)
+ [
## Recherche de cibles de mise à niveau valides
](#USER_UpgradeDBInstance.MariaDB.FindingTargets)
+ [
# Numéros de version MariaDB
](USER_UpgradeDBInstance.MariaDB.VersionID.md)
+ [
# Numéros de version de RDS dans RDS for MariaDB
](USER_UpgradeDBInstance.MariaDB.rds.version.md)
+ [
# Mises à niveau des versions majeures pour RDS for MariaDB
](USER_UpgradeDBInstance.MariaDB.Major.md)
+ [
## Mise à niveau d'une instance de base de données MariaDB
](#USER_UpgradeDBInstance.MariaDB.Upgrading)
+ [
# Mises à niveau automatiques des versions mineures pour RDS for MariaDB
](USER_UpgradeDBInstance.MariaDB.Minor.md)
+ [
# Utilisation d’un réplica en lecture pour réduire la durée d’indisponibilité lors de la mise à niveau d’une base de données RDS for MariaDB
](USER_UpgradeDBInstance.MariaDB.ReducedDowntime.md)
+ [
# Surveillance des mises à niveau du moteur de base de données RDS pour MariaDB à l'aide d'événements
](USER_UpgradeDBInstance.MariaDB.Monitoring.md)
## Considérations relatives aux mises à niveau de MariaDB
Amazon RDS prend deux instantanés de base de données ou plus au cours du processus de mise à niveau. Amazon RDS prend jusqu'à deux instantanés de l'instance de base de données *avant* d'apporter des modifications à la mise à niveau. Si la mise à niveau ne fonctionne pas pour vos bases de données, vous pouvez restaurer l'un de ces instantanés pour créer une instance de base de données exécutant l'ancienne version. Amazon RDS prend un autre instantané de l'instance de base de données une fois la mise à niveau terminée. Amazon RDS prend ces instantanés, qu'il AWS Backup gère ou non les sauvegardes de l'instance de base de données.
**Note**
Amazon RDS ne prend des instantanés de base de données que si vous avez défini la période de rétention des sauvegardes de votre instance de base de données sur un nombre supérieur à 0. Pour modifier la période de rétention des sauvegardes, consultez [Modification d'une instance de base de données Amazon RDS](Overview.DBInstance.Modifying.md).
Une fois la mise à niveau terminée, vous ne pouvez pas rétablir la version précédente du moteur de base de données. Si vous souhaitez revenir à la version précédente, restaurez le premier instantané de base de données pris pour créer une nouvelle instance de base de données.
Vous contrôlez à quel moment vous mettez à niveau votre instance de base de données vers une nouvelle version prise en charge par Amazon RDS. Ce niveau de contrôle vous aide à maintenir la compatibilité avec des versions de base de données spécifiques et à tester les nouvelles versions avec votre application avant un déploiement en production. Lorsque vous êtes prêt, vous pouvez effectuer des mises à niveau de version aux moments qui conviennent le mieux à votre planning.
Si votre instance DB utilise la réplication en lecture, vous devez mettre à niveau tous les réplicas en lecture avant de mettre à niveau l’instance source.
Si votre instance de base de données se trouve dans un déploiement multi-AZ, les deux instances de base de données principale et de secours sont mises à niveau. Les instances de base de données principales et de secours sont mises à niveau en même temps, et vous êtes confronté à une panne jusqu’à ce que la mise à niveau soit terminée. La durée de la panne varie selon votre moteur de base de données, la version du moteur et la taille de votre instance de base de données.
## Recherche de cibles de mise à niveau valides
Lorsque vous utilisez le AWS Management Console pour mettre à niveau une instance de base de données, il affiche les cibles de mise à niveau valides pour l'instance de base de données. Vous pouvez également exécuter la AWS CLI commande suivante pour identifier les cibles de mise à niveau valides pour une instance de base de données :
Pour Linux, macOS ou Unix :
```
aws rds describe-db-engine-versions \
--engine mariadb \
--engine-version version_number \
--query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" --output text
```
Pour Windows :
```
aws rds describe-db-engine-versions ^
--engine mariadb ^
--engine-version version_number ^
--query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" --output text
```
Par exemple, pour identifier les cibles de mise à niveau valides pour une instance de base de données MariaDB version 10.5.17, exécutez la commande suivante : AWS CLI
Pour Linux, macOS ou Unix :
```
aws rds describe-db-engine-versions \
--engine mariadb \
--engine-version 10.5.17 \
--query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" --output text
```
Pour Windows :
```
aws rds describe-db-engine-versions ^
--engine mariadb ^
--engine-version 10.5.17 ^
--query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" --output text
```
# Numéros de version MariaDB
La séquence de numérotation des versions du moteur de base de données RDS for MariaDB se présente sous la forme *major.minor.patch.YYYYMMDD* ou *major.minor.patch*, par exemple 10.11.5.R2.20231201 ou 10.4.30. Le format utilisé dépend de la version du moteur MariaDB.
**major**
Le numéro de version majeure est à la fois l’entier et la première partie fractionnaire du numéro de version, par exemple 10.11. Une mise à niveau majeure augmente la partie majeure du numéro de version. Par exemple, une mise à niveau de la version *10.5*.20 vers la version 10.6.12 est une mise à niveau de version majeure, *10.5* et *10.6* étant les numéros des versions majeures.
**mineure**
Le numéro de version mineure est la troisième partie du numéro de version, par exemple le 5 dans 10.11.5.
**patch**
Le correctif est la quatrième partie du numéro de version, par exemple R2 dans 10.11.5.R2. Une version de correctif RDS inclut des corrections de bogues importantes apportées à une version mineure après sa publication.
**YYYYMMDD**
La date est la cinquième partie du numéro de version, par exemple 20231201 dans 10.11.5.R2.20231201. Une version avec date RDS inclut des corrections de bogues importantes apportées à une version mineure après sa publication. Elle n’inclut aucun correctif susceptible de modifier le comportement d’un moteur.
Le tableau suivant explique le schéma de dénomination pour RDS for MariaDB version 10.11.
| Version mineure 10.11 | Schéma de dénomination |
| --- | --- |
| ≥ 5 | Les nouvelles instances de base de données utilisent *major.minor.patch.YYMMDD*, par exemple 10.11.5.R2.20231201. Les instances de base de données existantes peuvent utiliser *major.minor.patch*, par exemple 10.11.5.R2, jusqu’à votre prochaine mise à niveau de version majeure ou mineure. |
| < 5 | Les instances de base de données existantes utilisent *major.minor.patch*, par exemple 10.11.4.R2. |
Le tableau suivant explique le schéma de dénomination pour RDS for MariaDB version 10.6.
| Version mineure 10.6 | Schéma de dénomination |
| --- | --- |
| ≥ 14 | Les nouvelles instances de base de données utilisent *major.minor.patch.YYMMDD*, par exemple 10.6.14.R2.20231201. Les instances de base de données existantes peuvent utiliser *major.minor.patch*, par exemple 10.6.14.R2, jusqu’à votre prochaine mise à niveau de version majeure ou mineure. |
| < 14 | Les instances de base de données existantes utilisent *major.minor.patch*, par exemple 10.6.13.R2. |
Le tableau suivant explique le schéma de dénomination pour RDS for MariaDB version 10.5.
| Version mineure 10.5 | Schéma de dénomination |
| --- | --- |
| ≥ 21 | Les nouvelles instances de base de données utilisent *major.minor.patch.YYMMDD*, par exemple 10.5.21.R2.20231201. Les instances de base de données existantes peuvent utiliser *major.minor.patch*, par exemple 10.5.21.R2, jusqu’à votre prochaine mise à niveau de version majeure ou mineure. |
| < 21 | Les instances de base de données existantes utilisent *major.minor.patch*, par exemple 10.5.20.R2. |
Le tableau suivant explique le schéma de dénomination pour RDS for MariaDB version 10.4.
| Version mineure 10.4 | Schéma de dénomination |
| --- | --- |
| ≥ 30 | Les nouvelles instances de base de données utilisent *major.minor.patch.YYMMDD*, par exemple 10.4.30.R2.20231201. Les instances de base de données existantes peuvent utiliser *major.minor.patch*, par exemple 10.4.30.R2, jusqu’à votre prochaine mise à niveau de version majeure ou mineure. |
| < 30 | Les instances de base de données existantes utilisent *major.minor.patch*, par exemple 10.4.29.R2. |
# Numéros de version de RDS dans RDS for MariaDB
Les numéros de version de RDS utilisent le schéma de dénomination `major.minor.patch` ou `major.minor.patch.YYYYMMDD`. Une version de correctif RDS inclut des corrections de bogues importantes apportées à une version mineure après sa publication. Une version avec date RDS (*YYMMDD*) est un correctif de sécurité. Un correctif de sécurité n’inclut aucun correctif susceptible de modifier le comportement du moteur.
Pour identifier le numéro de version Amazon RDS de votre base de données, vous devez d’abord créer l’extension `rds_tools` à l’aide de la commande suivante :
```
CREATE EXTENSION rds_tools;
```
Vous pouvez connaître le numéro de version RDS de votre base de données RDS for MariaDB avec la requête SQL suivante :
```
mysql> select mysql.rds_version();
```
Par exemple, l’interrogation d’une base de données RDS for MariaDB 10.6.14 renvoie ce qui suit :
```
+---------------------+
| mysql.rds_version() |
+---------------------+
| 10.6.14.R2.20231201 |
+---------------------+
1 row in set (0.01 sec)
```
# Mises à niveau des versions majeures pour RDS for MariaDB
Les mises à niveau de version majeure peuvent contenir des modifications de base de données qui ne sont pas rétrocompatibles avec les applications existantes. En conséquence, Amazon RDS n'applique pas les mise à niveau de version majeure automatiquement. Vous devez modifier manuellement votre instance de base de données. Nous vous recommandons de tester soigneusement toute mise à niveau avant de l'appliquer à vos instances de production.
**Note**
Dans MariaDB 11.8, la valeur par défaut `require_secure_transport` pour est `1` now, ce qui nécessite des connexions sécurisées. SSL/TLS Défini sur `0` si des connexions non sécurisées sont nécessaires.
Amazon RDS prend en charge les mises à niveau sur place suivantes des versions majeures du moteur de base de données MariaDB :
+ De toute version de MariaDB vers MariaDB 11.8
+ De toute version de MariaDB vers MariaDB 11.4
+ De toute version de MariaDB vers MariaDB 10.11
+ De toute version de MariaDB vers MariaDB 10.6
+ MariaDB 10.4 vers MariaDB 10.5
Si vous utilisez un groupe de paramètres personnalisé et que vous effectuez une mise à niveau de version majeure, vous devez spécifier un groupe de paramètres par défaut pour la nouvelle version du moteur de base de données ou créer votre propre groupe de paramètres personnalisé pour la nouvelle version du moteur de base de données. L'association du nouveau groupe de paramètres avec l'instance de base de données exige un redémarrage de la base de données initié par le client après la mise à niveau. Le statut du groupe de paramètres de l'instance indique `pending-reboot` si l'instance doit être redémarrée pour que les modifications du groupe de paramètres soient appliquées. Il est possible d’afficher le statut du groupe de paramètres d’une instance dans la AWS Management Console ou en effectuant un appel « describe » tel que `describe-db-instances`.
## Mise à niveau d'une instance de base de données MariaDB
Pour plus d’informations sur la mise à niveau manuelle ou automatique d’une instance de base de données MariaDB, consultez [Mise à niveau d'une version du moteur d'une instance de base de données](USER_UpgradeDBInstance.Upgrading.md).
# Mises à niveau automatiques des versions mineures pour RDS for MariaDB
Si vous spécifiez les paramètres suivants lors de la création ou de la modification d’une instance de base de données, celle-ci peut être mise à niveau automatiquement.
+ Le paramètre **Mise à niveau automatique des versions mineures** est activé.
+ Le paramètre **Période de conservation des sauvegardes** est supérieur à 0.
Dans AWS Management Console, ces paramètres se trouvent sous **Additional configuration** (Configuration supplémentaire). L’image suivante illustre le réglage **Auto minor version upgrade** (Mise à niveau automatique de versions mineures).
![\[Paramètre de mise à jour automatique des versions mineures\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/amvu.png)
Pour plus d’informations sur ces paramètres, consultez la page [Paramètres des instances de base de données](USER_ModifyInstance.Settings.md).
Pour certaines versions majeures de RDS for MariaDB dans certaines Régions AWS, RDS désigne une version mineure comme version de mise à niveau automatique. Une fois qu’une version mineure a été testée et approuvée par Amazon RDS, la mise à niveau de version mineure se produit automatiquement pendant votre fenêtre de maintenance. RDS ne définit pas automatiquement les dernières versions mineures publiées comme version de mise à niveau automatique. Avant de désigner une publication de version récente comme version de mise à niveau automatique, RDS prend en compte plusieurs critères, à savoir :
+ Problèmes de sécurité connus
+ Bogues dans MariaDB Community
+ Stabilité globale de la flotte depuis la publication de la version mineure
**Note**
La prise en charge de l’utilisation des versions 1.0 et 1.1 de TLS a été supprimée à partir de versions mineures spécifiques de MariaDB. Pour en savoir plus sur les versions mineures de MariaDB prises en charge, consultez [Prise en charge de SSL/TLS pour les instances de base de données MariaDB sur Amazon RDS](MariaDB.Concepts.SSLSupport.md).
Vous pouvez exécuter la commande d’AWS CLI suivante pour déterminer la version cible de mise à niveau automatique mineure actuelle pour une version mineure spécifiée de MariaDB dans une Région AWS spécifique.
Pour Linux, macOS ou Unix :
```
aws rds describe-db-engine-versions \
--engine mariadb \
--engine-version minor_version \
--region region \
--query "DBEngineVersions[*].ValidUpgradeTarget[*].{AutoUpgrade:AutoUpgrade,EngineVersion:EngineVersion}" \
--output text
```
Pour Windows :
```
aws rds describe-db-engine-versions ^
--engine mariadb ^
--engine-version minor_version ^
--region region ^
--query "DBEngineVersions[*].ValidUpgradeTarget[*].{AutoUpgrade:AutoUpgrade,EngineVersion:EngineVersion}" ^
--output text
```
Par exemple, la commande AWS CLI suivante détermine la cible de mise à niveau mineure automatique pour la version mineure 10.5.16 de MariaDB dans la Région AWS USA Est (Ohio) (us-east-2).
Pour Linux, macOS ou Unix :
```
aws rds describe-db-engine-versions \
--engine mariadb \
--engine-version 10.5.16 \
--region us-east-2 \
--query "DBEngineVersions[*].ValidUpgradeTarget[*].{AutoUpgrade:AutoUpgrade,EngineVersion:EngineVersion}" \
--output table
```
Pour Windows :
```
aws rds describe-db-engine-versions ^
--engine mariadb ^
--engine-version 10.5.16 ^
--region us-east-2 ^
--query "DBEngineVersions[*].ValidUpgradeTarget[*].{AutoUpgrade:AutoUpgrade,EngineVersion:EngineVersion}" ^
--output table
```
Votre sortie est similaire à ce qui suit.
```
----------------------------------
| DescribeDBEngineVersions |
+--------------+-----------------+
| AutoUpgrade | EngineVersion |
+--------------+-----------------+
| True | 10.5.17 |
| False | 10.5.18 |
| False | 10.5.19 |
| False | 10.6.5 |
| False | 10.6.7 |
| False | 10.6.8 |
| False | 10.6.10 |
| False | 10.6.11 |
| False | 10.6.12 |
+--------------+-----------------+
```
Dans cet exemple, la valeur de `AutoUpgrade` est `True` pour MariaDB version 10.5.17. Ainsi, la cible de mise à niveau mineure automatique est MariaDB version 10.5.17, comme mis en évidence dans la sortie.
Une instance de base de données MariaDB est automatiquement mise à niveau pendant votre fenêtre de maintenance si les critères suivants sont réunis :
+ Le paramètre **Mise à niveau automatique des versions mineures** est activé.
+ Le paramètre **Période de conservation des sauvegardes** est supérieur à 0.
+ L’instance de base de données exécute une version mineure du moteur de base de données qui est inférieure à la version mineure de la mise à niveau automatique actuelle.
Pour plus d’informations, consultez [Mise à niveau automatique de la version mineure du moteur](USER_UpgradeDBInstance.Upgrading.md#USER_UpgradeDBInstance.Upgrading.AutoMinorVersionUpgrades).
# Utilisation d’un réplica en lecture pour réduire la durée d’indisponibilité lors de la mise à niveau d’une base de données RDS for MariaDB
Dans la plupart des cas, un déploiement bleu/vert est la meilleure option pour réduire la durée d’indisponibilité lors de la mise à niveau d’une instance de base de données MariaDB. Pour plus d’informations, consultez [Utilisation d'Amazon RDS ( Blue/Green Deployments) pour les mises à jour de bases de données](blue-green-deployments.md).
Si vous ne pouvez pas utiliser un déploiement bleu/vert et que votre instance de base de données MariaDB est en cours d’utilisation avec une application de production, vous pouvez utiliser la procédure suivante pour mettre à niveau la version de la base de données pour votre instance de base de données. Cette procédure peut réduire la durée d’indisponibilité de votre application.
En utilisant un réplica en lecture, vous pouvez effectuer la plupart des étapes de maintenance à l’avance et ainsi réduire les modifications nécessaires lors d’une panne réelle. Cette technique vous permet de tester et de préparer la nouvelle instance de base de données sans apporter de modifications à votre instance de base de données existante.
La procédure suivante illustre un exemple de mise à niveau de MariaDB version 10.5 vers MariaDB version 10.6. Vous pouvez utiliser les mêmes étapes générales pour des mises à niveau vers d’autres versions majeures.
**Pour mettre à niveau une base de données MariaDB alors qu’une instance de base de données est en cours d’utilisation**
1. Connectez-vous à la AWS Management Console et ouvrez la console Amazon RDS à l’adresse [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Créez un réplica en lecture de votre instance de base de données MariaDB 10.5. Ce processus crée une copie pouvant être mise à niveau de votre base de données. D’autres réplicas en lecture de l’instance de base de données peuvent également exister.
1. Sur la console, choisissez **Bases de données**, puis sélectionnez l’instance de base de données que vous souhaitez mettre à niveau.
1. Sous **Actions**, choisissez **Créer des réplicas en lecture**.
1. Spécifiez une valeur pour **DB instance identifier** (Identifiant de l’instance DB) pour votre réplica en lecture et assurez-vous que la **DB instance class** (Classe d’instance DB) et les autres paramètres correspondent à votre instance de base de données MariaDB 10.5.
1. Choisissez **Créer un réplica en lecture**.
1. (Facultatif) Lorsque le réplica en lecture a été créé et que le champ **État** indique **Disponible**, convertissez le réplica en lecture en déploiement multi-AZ et activez les sauvegardes.
Par défaut, un réplica en lecture est créé en tant que déploiement mono-AZ et les sauvegardes sont désactivées. Dans la mesure où le réplica en lecture finira par devenir l’instance de base de données de production, nous vous recommandons de configurer un déploiement multi-AZ et d’activer les sauvegardes dès maintenant.
1. Sur la console, choisissez **Bases de données**, puis sélectionnez le réplica en lecture que vous venez de créer.
1. Sélectionnez **Modifier**.
1. Dans le champ **Déploiement multi-AZ**, choisissez **Créer une instance de secours**.
1. Dans le champ **Backup Retention Period** (Période de rétention des sauvegardes), choisissez une valeur positive différente de zéro (par exemple, 3 jours), puis sélectionnez **Continue** (Continuer).
1. Pour **Planification des modifications**, choisissez **Appliquer immédiatement**.
1. Choisissez **Modifier l’instance DB**.
1. Lorsque le champ **Status** (Statut) du réplica en lecture indique **Available** (Disponible), procédez à sa mise à niveau vers MySQL 10.6.
1. Sur la console, choisissez **Bases de données**, puis sélectionnez le réplica en lecture que vous venez de créer.
1. Sélectionnez **Modifier**.
1. Pour **DB engine version** (Version du moteur de base de données), choisissez la version MariaDB 10.6 vers laquelle effectuer la mise à niveau, puis **Continue** (Continuer).
1. Pour **Planification des modifications**, choisissez **Appliquer immédiatement**.
1. Choisissez **Modifier l’instance de base de données** pour démarrer la mise à niveau.
1. Lorsque la mise à niveau est terminée et que le champ **Status** (Statut) indique **Available** (Disponible), vérifiez que le réplica en lecture mis à niveau est à jour avec l’instance de base de données MariaDB 10.5 source. Pour vérifier, connectez-vous au réplica en lecture et exécutez la commande `SHOW REPLICA STATUS`. Si le champ `Seconds_Behind_Master` a pour valeur `0`, la réplication est à jour.
**Note**
Les versions précédentes de MariaDB utilisaient `SHOW SLAVE STATUS` à la place de `SHOW REPLICA STATUS`. Si vous utilisez une version de MariaDB antérieure à la version 10.6, utilisez `SHOW SLAVE STATUS`.
1. (Facultatif) Créez un réplica en lecture de votre réplica en lecture.
Si vous souhaitez que l’instance de base de données dispose d’un réplica en lecture une fois celle-ci promue en tant qu’instance de base de données autonome, vous pouvez créer le réplica en lecture dès maintenant.
1. Sur la console, choisissez **Bases de données**, puis sélectionnez le réplica en lecture que vous venez de mettre à niveau.
1. Sous **Actions**, choisissez **Créer des réplicas en lecture**.
1. Spécifiez une valeur pour **DB instance identifier** (Identifiant de l’instance DB) pour votre réplica en lecture et assurez-vous que la **DB instance class** (Classe d’instance DB) et les autres paramètres correspondent à votre instance de base de données MariaDB 10.5.
1. Choisissez **Créer un réplica en lecture**.
1. (Facultatif) Configurez un groupe de paramètres de base de données personnalisé pour le réplica en lecture.
Si vous souhaitez que l’instance de base de données utilise un groupe de paramètres personnalisé une fois celle-ci promue en tant qu’instance de base de données autonome, vous pouvez créer le groupe de paramètres de base de données dès maintenant et l’associer au réplica en lecture.
1. Créez un groupe de paramètres de base de données personnalisé pour MariaDB 10.6. Pour obtenir des instructions, consultez [Création d’un groupe de paramètres de base de données dans Amazon RDS](USER_WorkingWithParamGroups.Creating.md).
1. Modifiez les paramètres que vous souhaitez modifier dans le groupe de paramètres de base de données fraîchement créé. Pour obtenir des instructions, consultez [Modification de paramètres dans un groupe de paramètres de base de données dans Amazon RDS](USER_WorkingWithParamGroups.Modifying.md).
1. Sur la console, choisissez **Bases de données**, puis sélectionnez le réplica en lecture.
1. Sélectionnez **Modifier**.
1. Pour **DB parameter group** (Groupe de paramètres DB), choisissez le groupe de paramètres de base de données MariaDB 10.6 que vous venez de créer, puis sélectionnez **Continue** (Continuer).
1. Pour **Planification des modifications**, choisissez **Appliquer immédiatement**.
1. Choisissez **Modifier l’instance de base de données** pour démarrer la mise à niveau.
1. Faites de votre réplica en lecture MariaDB 10.6 une instance de base de données autonome.
**Important**
Une fois promu en tant qu’instance de base de données autonome, votre réplica en lecture MariaDB 10.6 cesse d’être un réplica de votre instance de base de données MariaDB 10.5. Nous vous conseillons d’effectuer la promotion de votre réplica en lecture MariaDB 10.6 au cours d’une fenêtre de maintenance lorsque votre instance de base de données MariaDB 10.5 source est en mode lecture seule et que toutes les opérations d’écriture sont suspendues. Une fois la promotion terminée, vous pouvez diriger vos opérations d’écriture vers l’instance de base de données MariaDB 10.6 mise à niveau pour garantir qu’aucune opération d’écriture ne se perde.
En outre, avant la promotion de votre réplica en lecture MariaDB 10.6, nous vous conseillons d’effectuer toutes les opérations DDL (Data Definition Language) nécessaires sur votre réplica en lecture MariaDB 10.6. Par exemple, la création d’index. Cette approche permet d’éviter tout effet négatif sur les performances du réplica en lecture MariaDB 10.6 après sa promotion. Pour promouvoir un réplica en lecture.
1. Sur la console, choisissez **Bases de données**, puis sélectionnez le réplica en lecture que vous venez de mettre à niveau.
1. Pour **Actions**, choisissez **Promote (Promouvoir)**.
1. Choisissez **Oui** pour activer les sauvegardes automatiques pour l’instance du réplica en lecture. Pour plus d’informations, consultez [Présentation des sauvegardes](USER_WorkingWithAutomatedBackups.md).
1. Choisissez **Continuer**.
1. Choisissez **Promouvoir le réplica en lecture**.
1. Vous disposez à présent d’une version mise à niveau de votre base de données MariaDB. À ce stade, vous pouvez diriger vos applications vers la nouvelle instance de base de données MariaDB 10.6.
# Surveillance des mises à niveau du moteur de base de données RDS pour MariaDB à l'aide d'événements
Lorsque vous mettez à niveau la version du moteur d'une base de données RDS pour MariaDB, Amazon RDS émet un événement spécifique à chaque phase du processus. Pour suivre la progression d'une mise à niveau, vous pouvez consulter ces événements ou vous y abonner.
Pour plus d'informations sur les événements RDS, consultez[Surveillance des événements Amazon RDS](working-with-events.md).
Pour obtenir des informations détaillées sur un événement Amazon RDS spécifique qui se produit lors de la mise à niveau de votre moteur, consultez[Catégories d'événements Amazon RDS et messages d'événements ](USER_Events.Messages.md).
# Mise à niveau d’une version du moteur d’instantané de base de données MariaDB
Amazon RDS vous permet de créer un instantané de base de données de volume de stockage de votre instance de base de données MariaDB. Lorsque vous créez un instantané de base de données, l’instantané est basé sur la version du moteur utilisée par votre instance de base de données. Vous pouvez mettre à niveau la version du moteur pour vos instantanés de base de données.
Pour RDS for MariaDB, vous pouvez effectuer une mise à niveau vers toutes les versions de moteur disponibles. Vous pouvez mettre à niveau des instantanés de base de données chiffrés ou non chiffrés.
Pour afficher les versions de moteur disponibles pour votre instantané de base de données RDS for MariaDB, utilisez l’exemple DB’ AWS CLI suivant.
```
aws rds describe-db-engine-versions --engine mariadb --include-all --engine-version example-engine-version --query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" --output text
```
Si vous ne voyez aucun résultat pour votre instantané, la version de votre moteur est peut-être obsolète. Si la version de votre moteur est obsolète, nous vous recommandons d’effectuer une mise à niveau vers la cible de mise à niveau de la version majeure la plus récente ou vers l’une des autres cibles de mise à niveau disponibles pour cette version. Pour plus d’informations, consultez [Mise à niveau des options pour les instantanés de base de données avec des versions de moteur non prises en charge pour RDS for MariaDB](mariadb-upgrade-snapshot.upgrade-options.md).
Après avoir restauré un instantané de base de données mis à niveau vers une nouvelle version de moteur, veillez à vérifier que la mise à jour est réussie. Pour plus d’informations sur une mise à niveau des versions majeures, consultez [Mises à niveau du moteur de base de données MariaDB](USER_UpgradeDBInstance.MariaDB.md). Pour savoir comment restaurer un instantané de base de données, consultez [Restauration d’une instance de base de données](USER_RestoreFromSnapshot.md).
**Note**
Vous ne pouvez pas mettre à niveau des instantanés de base de données automatisés qui ont été créés lors du processus de sauvegarde automatique.
Vous pouvez mettre à niveau un instantané de base de données à l'aide de l'API AWS Management Console AWS CLI, ou RDS.
------
#### [ Console ]
Pour mettre à niveau une version du moteur de snapshots de base de données à l'aide de AWS Management Console, procédez comme suit.
**Pour mettre à niveau un instantané de base de données**
1. Connectez-vous à la console Amazon RDS AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)l'adresse.
1. Dans le panneau de navigation, choisissez **Snapshots**.
1. Choisissez l’instantané que vous souhaitez mettre à niveau.
1. Pour **Actions**, choisissez **Upgrade Snapshot (Mettre à niveau l’instantané)**. La page **Upgrade Snapshot (Mettre à niveau l’instantané)** s’affiche.
1. Choisissez la **New engine version (Version du nouveau moteur)** vers laquelle mettre à niveau.
1. Choisissez **Save changes (Enregistrer les changements)** pour mettre à niveau l’instantané.
Pendant le processus de mise à niveau, toutes les actions d’instantané sont désactivées pour l’instantané de base de données. De même, le statut de l’instantané de base de données passe de **Disponible** à **Mise à niveau**, puis passe à **Actif** une fois la mise à niveau terminée. Si l’instantané de base de données ne peut pas être mis à jour en raison d’un problème d’instantané endommagé, le statut devient **Indisponible**. Vous ne pouvez pas récupérer l’instantané lorsqu’il a ce statut.
**Note**
Si la mise à niveau de l’instantané de base de données échoue, l’instantané revient à l’état d’origine avec la version originale.
------
#### [ AWS CLI ]
Pour mettre à niveau un instantané de base de données vers une nouvelle version du moteur de base de données, exécutez la AWS CLI [modify-db-snapshot](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-snapshot.html)commande.
**Options**
+ `--db-snapshot-identifier` : l’identifiant de l’instantané de base de données à mettre à niveau. L’identifiant doit être unique pour un Amazon Resource Name (ARN). Pour plus d'informations, consultez [Amazon Resource Names (ARN) dans Amazon RDS](USER_Tagging.ARN.md).
+ `--engine-version` : la version du moteur vers laquelle la mise à niveau de l’instantané de base de données doit être effectuée.
**Example**
Pour Linux, macOS ou Unix :
```
1. aws rds modify-db-snapshot \
2.
3. --db-snapshot-identifier my_db_snapshot \
4. --engine-version new_version
```
Pour Windows :
```
1. aws rds modify-db-snapshot ^
2. --db-snapshot-identifier my_db_snapshot ^
3. --engine-version new_version
```
------
#### [ Amazon RDS API ]
Pour mettre à niveau un instantané de base de données vers une nouvelle version du moteur de base de données, appelez l'DBSnapshotopération RDS API [Modify](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBSnapshot.html).
**Parameters**
+ `DBSnapshotIdentifier` : l’identifiant de l’instantané de base de données à mettre à niveau. L’identifiant doit être unique pour un Amazon Resource Name (ARN). Pour plus d'informations, consultez [Amazon Resource Names (ARN) dans Amazon RDS](USER_Tagging.ARN.md).
+ `EngineVersion` : la version du moteur vers laquelle la mise à niveau de l’instantané de base de données doit être effectuée.
------
# Mise à niveau des options pour les instantanés de base de données avec des versions de moteur non prises en charge pour RDS for MariaDB
Le tableau suivant indique les versions de moteur vers lesquelles vous pouvez effectuer une mise à niveau à partir d’une version de moteur non prise en charge pour les instantanés de base de données RDS for MariaDB.
**Note**
Il se peut que vous deviez mettre à niveau votre instantané de base de données plusieurs fois pour passer à la version du moteur que vous avez choisie.
| Version du moteur d’instantané de base de données | Versions du moteur disponibles pour la mise à niveau |
| --- | --- |
| 10.0.17, 10.0.24, 10.0.28, 10.0.31, 10.0.32, 10.0.34, 10.0.35 | 10.0.38, 10.1.48, 10.6.19, 10.6.20, 10.11.9, 10.11.10, 11.4.3, 11.4.4, 11.8.3 |
| 10.1.14, 10.1.16, 10.1.19, 10.1.23, 10.1.26, 10.1.31, 10.1.34 | 10.1.48, 10.2.44, 10.6.19, 10.6.20, 10.11.9, 10.11.10, 11.4.3, 11.4.4, 11.8.3 |
| 10.2.11, 10.2.12, 10.2.15, 10.2.21, 10.2.32, 10.2.37, 10.2.39, 10.2.40, 10.2.41, 10.2.43 | 10.2.44, 10.3.39, 10.6.19, 10.6.20, 10.6.21, 10.11.9, 10.11.10, 10.11.11, 11.4.3, 11.4.4, 11.8.3 |
| 10.3.8, 10.3.13, 10.3.20, 10.3.23, 10.3.28, 10.3.31, 10.3.32 | 10.3.39, 10.4.34, 10.6.19, 10.6.20 10.6.21, 10.11.9, 10.11.10, 10.11.11, 11.4.3, 11.4.4, 11.8.3 |
| 10.4.8 | 10.4.34, 10.5.16, 10.5.17, 10.5.18, 10.5.20, 10.5.21, 10.5.22, 10.5.23, 10.5.24, 10.5.25, 10.5.26, 10.5.27, 10.5.28, 10.6.8, 10.6.10, 10.6.11, 10.6.13, 10.6.14, 10.6.15, 10.6.16, 10.6.18, 10.6.19, 10.6.20, 10.6.21, 10.11.4, 10.6.17, 10.11.5, 10.11.6, 10.11.7, 10.11.8, 10.11.9, 10.11.10, 10.11.11 |
# Importation de données dans une instance de base de données Amazon RDS for MariaDB
Vous pouvez utiliser plusieurs techniques différentes pour importer des données dans une instance de base de données RDS for MariaDB. La meilleure approche dépend d’un certain nombre de facteurs :
+ Source des données
+ Quantité de données
+ Importation en une seule fois ou en continu
+ Durée d’indisponibilité
Si vous migrez également une application avec les données, tenez également compte de la durée d’indisponibilité que vous êtes prêt à accepter.
Le tableau suivant répertorie les techniques d’importation de données dans une instance de base de données RDS for MariaDB :
**Note**
Amazon RDS ne prend pas en charge `mariadb-backup` ni l’importation depuis Amazon S3 for MariaDB.
| Source | Quantité de données | Une seule fois ou en continu | Interruption de l'application | Technique | En savoir plus |
| --- | --- | --- | --- | --- | --- |
| Base de données MariaDB existante sur site ou sur Amazon EC2 | N’importe quel compte | En continu | Minimale | Configurez la réplication avec une base de données MariaDB existante comme source de réplication. Vous pouvez configurer la réplication dans une instance de base de données MariaDB à l'aide des identificateurs de transaction globaux de MariaDB (GTIDs) lorsque l'instance externe est MariaDB version 10.0.24 ou supérieure, ou en utilisant les coordonnées du journal binaire pour les instances de MariaDB sur les versions antérieures à 10.0.24. MariaDB est GTIDs implémenté différemment de GTIDs MySQL, qui n'est pas pris en charge par Amazon RDS. | [Configuration d’une réplication de position de fichier journal binaire avec une instance source externe](MySQL.Procedural.Importing.External.ReplMariaDB.md) [Importation de données vers une instance de base de données Amazon RDS for MariaDB avec une durée d’indisponibilité réduite](mariadb-importing-data-reduced-downtime.md) |
| Toute base de données existante | N'importe quel compte | Une seule fois ou en continu | Minimale | AWS Database Migration Service À utiliser pour migrer la base de données avec un temps d'arrêt minimal et, pour de nombreux moteurs de base de données, poursuivre la réplication continue. | [Présentation d’ AWS Database Migration Service](https://docs.aws.amazon.com/dms/latest/userguide/Welcome.html) et [Utilisation d’une base de données compatible MySQL comme cible pour AWS DMS](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Target.MySQL.html) dans le *Guide de l’utilisateur AWS Database Migration Service * |
| Instance de base de données MariaDB existante | N’importe quel compte | Une seule fois ou en continu | Minimale | Créez un réplica en lecture pour la réplication continue. Promouvez le réplica en lecture pour la création unique d’une nouvelle instance de base de données. | [Utilisation des réplicas en lecture d'instance de base de données](USER_ReadRepl.md) |
| Base de données MariaDB existante | Petite | Une seule fois | Momentanée | Copiez les données directement dans votre instance de base de données MariaDB à l’aide d’un utilitaire de ligne de commande. | [Importation de données à partir d’une base de données MariaDB externe vers une instance de base de données Amazon RDS for MariaDB](mariadb-importing-data-external-database.md) |
| Données non stockées dans une base de données existante | Medium | Une seule fois | Momentanée | Créez des fichiers plats et importez-les à l’aide des instructions MariaDB `LOAD DATA LOCAL INFILE`. | [Importation de données depuis n’importe quelle source vers une instance de base de données Amazon RDS for MariaDB](mariadb-importing-data-any-source.md) |
**Note**
La base de données système `mysql` contient les informations d’authentification et d’autorisation requises pour se connecter à l’instance de base de données et accéder aux données. La suppression, la modification, le renommage ou la troncation de tables, de données ou d’autres contenus de la base de données `mysql` de votre instance de base de données peut produire des erreurs et rendre inaccessibles l’instance de base de données et vos données. Dans ce cas, vous pouvez restaurer l'instance de base de données à partir d'un instantané à l'aide de la AWS CLI [https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-db-snapshot.html](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-db-snapshot.html)commande. Vous pouvez récupérer l’instance de base de données à l’aide de la commande [https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-to-point-in-time.html](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-to-point-in-time.html).
# Considérations sur l’importation de données pour MariaDB
Le contenu suivant présente des informations techniques sur le chargement de données dans MariaDB. Ce contenu est destiné aux utilisateurs qui connaissent bien l’architecture de serveur MariaDB.
## Journalisation binaire
L’activation de la journalisation binaire réduit les performances de chargement des données et nécessite jusqu’à quatre fois plus d’espace disque que la journalisation désactivée. La taille des transactions utilisées pour charger les données influe directement sur les performances du système et les besoins en espace disque. Les transactions plus importantes nécessitent davantage de ressources.
## Taille de la transaction
La taille des transactions influence les aspects suivants du chargement de données MariaDB :
+ Consommation des ressources
+ Utilisation de l’espace disque
+ Reprendre le processus
+ Délai de récupération
+ Format d’entrée (fichiers plats ou SQL)
Cette section décrit comment la taille de la transaction influe sur la journalisation binaire. En outre, elle plaide en faveur de la désactivation de cette même journalisation lors de chargements de données volumineux. Vous pouvez activer et désactiver la journalisation binaire en définissant la période de rétention des sauvegardes automatiques Amazon RDS. Les valeurs différentes de zéro activent la journalisation binaire, tandis que la valeur zéro la désactive. Pour plus d’informations, consultez [Période de rétention des sauvegardes](USER_WorkingWithAutomatedBackups.BackupRetention.md).
Cette section décrit également l’impact des transactions volumineuses sur InnoDB et pourquoi il est important que les transactions conservent une petite taille.
### Petites transactions
Pour les petites transactions, la journalisation binaire multiplie par deux le nombre d'écritures sur disque requises pour charger les données. Elle peut ainsi affecter gravement les performances des autres sessions de base de données et accroître le temps requis pour charger les données. La dégradation subie dépend en partie des facteurs suivants :
+ Vitesse de chargement
+ Autres activités de base de données ayant lieu pendant le chargement
+ Capacité de votre instance de base de données Amazon RDS
Les journaux binaires consomment aussi un espace disque approximativement égal à la quantité de données chargées jusqu’à ce que les journaux soient sauvegardés et supprimés. Amazon RDS réduit cette consommation en sauvegardant et en supprimant fréquemment les journaux binaires.
### Transactions volumineuses
Pour les transactions importantes, la journalisation binaire triple les IOPS et l’utilisation du disque pour les raisons suivantes :
+ Le cache du journal binaire stocke temporairement les données de transaction sur le disque.
+ Ce cache augmente avec la taille de la transaction, ce qui consomme de l’espace disque.
+ Lorsque la transaction (validation ou annulation) est terminée, le système copie le cache dans le journal binaire.
Ce processus crée trois copies des données :
+ Les données d’origine
+ Le cache sur le disque
+ La dernière entrée du journal binaire
Chaque opération d’écriture entraîne des E/S supplémentaires, ce qui a un impact supplémentaire sur les performances.
De ce fait, la journalisation binaire nécessite trois fois plus d’espace disque que la journalisation désactivée. Par exemple, le chargement de 10 GiB de données en une seule transaction crée trois copies :
+ 10 GiB pour les données du tableau
+ 10 GiB pour le cache du journal binaire
+ 10 GiB pour le fichier journal binaire
L’espace disque temporaire total requis est de 30 GiB.
Considérations importantes relatives à l’espace disque :
+ Le fichier de cache est conservé jusqu’à la fin de la session ou jusqu’à ce qu’une nouvelle transaction crée un autre cache.
+ Le journal binaire est conservé jusqu’à ce qu’il soit sauvegardé et peut contenir 20 GiB (cache et journal) pendant une période prolongée.
Si vous utilisez `LOAD DATA LOCAL INFILE` pour charger les données, la récupération des données crée une quatrième copie au cas où la base de données devrait être récupérée à partir d’une sauvegarde exécutée avant le chargement. Pendant la récupération, MariaDB extrait les données du journal binaire dans un fichier plat. MariaDB exécute ensuite `LOAD DATA LOCAL INFILE`. Sur la base de l’exemple précédent, cette récupération nécessite un espace disque temporaire total de 40 GiB, soit 10 Gib chacun pour la table, le cache, le journal et le fichier local. Si l’espace disque disponible est inférieur à 40 GiB, la restauration échoue.
### Optimisation des charges de données importantes
Pour les chargements de données volumineux, désactivez la journalisation binaire afin de réduire la surcharge et les contraintes d’espace disque. Vous pouvez désactiver la journalisation binaire en définissant la période de rétention des sauvegardes sur 0. Une fois le chargement terminé, restaurez la période de rétention des sauvegardes sur la valeur appropriée différente de zéro. Pour plus d’informations, consultez [Modification d'une instance de base de données Amazon RDS](Overview.DBInstance.Modifying.md) et la [Période de rétention des sauvegardes](USER_ModifyInstance.Settings.md) dans la table des paramètres.
**Note**
Si l’instance de base de données est une instance de base de données source pour les réplicas en lecture, vous ne pouvez pas définir la période de rétention des sauvegardes sur 0.
Avant de charger les données, nous vous recommandons de créer un instantané de base de données. Pour plus d’informations, consultez [Gestion des sauvegardes manuelles](USER_ManagingManualBackups.md).
## InnoDB
Les informations suivantes sur les options de journalisation des annulations et de récupération permettent de limiter la taille des transactions InnoDB afin d’optimiser les performances de la base de données.
### Compréhension de la journalisation des annulations par InnoDB
L’annulation est un mécanisme de journalisation qui permet l’annulation des transactions et prend en charge le contrôle de simultanéité multiversion (MVCC, Multi-Version Concurrency Control).
Pour les versions 10.11 et antérieures de MariaDB, les journaux d’annulation sont stockés dans le tablespace système InnoDB (généralement ibdata1) et conservés jusqu’à ce que le thread de purge les supprime. Ainsi, les transactions de chargements de données volumineux peuvent entraîner un agrandissement conséquent du tablespace système et utiliser de l’espace disque que vous ne pouvez pas revendiquer sans recréer la base de données.
Pour toutes les versions de MariaDB, le thread de purge doit attendre que la plus ancienne transaction active soit validée ou annulée pour supprimer les journaux d’annulation. Si la base de données traite d’autres transactions pendant le chargement, leurs journaux d’annulation s’accumulent également et ne peuvent pas être supprimés, même si les transactions sont validées et qu’aucune transaction ne nécessite les journaux d’annulation pour MVCC. Dans ce cas, toutes les transactions, y compris celles en lecture seule, ralentissent. Ce ralentissement se produit parce que toutes les transactions accèdent à toutes les lignes modifiées par toutes les transactions, et pas seulement par les transactions de chargement. En effet, les transactions doivent parcourir les journaux d’annulation dont les transactions de chargement de longue durée ont empêché la purge lors du nettoyage du journal d’annulation. Cela affecte les performances de toute opération accédant aux lignes modifiées.
### Options de récupération de transactions InnoDB
Bien qu’InnoDB optimise les opérations de validation, les annulations de transactions importantes sont lentes. Pour accélérer la restauration, effectuez une point-in-time restauration ou restaurez un instantané de base de données. Pour plus d’informations, consultez [Point-in-time rétablissement](USER_PIT.md) et [Restauration d’une instance de base de données](USER_RestoreFromSnapshot.md).
## formats d’importation de données
MariaDB prend en charge deux formats d’importation de données : fichiers plats et SQL. Passez en revue les informations relatives à chaque format afin de déterminer l’option la mieux adaptée à vos besoins.
### Fichiers plats
Pour les petites transactions, chargez des fichiers plats avec `LOAD DATA LOCAL INFILE`. Ce format d’importation de données offre les avantages suivants par rapport à l’utilisation de SQL :
+ Moins de trafic réseau
+ Réduction des coûts de transmission de données
+ Diminution des frais de traitement des bases de données
+ Accélération du traitement
`LOAD DATA LOCAL INFILE` charge la totalité du fichier plat comme une seule transaction. Maintenez une taille réduite pour chaque fichier afin de bénéficier des avantages suivants :
+ **Capacité de reprise** : vous pouvez suivre les fichiers qui ont été chargés. Si un problème survient pendant le chargement, vous pouvez reprendre la transaction là où elle s’est arrêtée. Vous devrez peut-être retransmettre des données à Amazon RDS, mais dans le cas de petits fichiers, la quantité retransmise est minimale.
+ **Chargement de données en parallèle** : si vous disposez d’une quantité suffisante d’IOPS et de bande passante du réseau pour le chargement d’un seul fichier, le chargement en parallèle peut faire gagner du temps.
+ **Contrôle du taux de chargement** : si le chargement de vos données a un impact négatif sur les autres processus, vous pouvez contrôler le taux de chargement en augmentant l’intervalle entre les fichiers.
Les transactions importantes réduisent les avantages liés à l’utilisation de `LOAD DATA LOCAL INFILE` pour importer des données. Lorsque vous ne pouvez pas diviser une grande quantité de données en fichiers plus petits, pensez à utiliser SQL.
### SQL
SQL possède un avantage principal sur les fichiers plats : vous pouvez facilement conserver une taille réduite pour les transactions. Cependant, le chargement avec SQL peut prendre beaucoup plus de temps que les fichiers plats. De plus, après un échec, il peut être difficile de définir à quel endroit reprendre : vous ne pouvez pas redémarrer les fichiers mariadb-dump. Si une défaillance se produit lors du chargement d’un fichier mariadb-dump, vous devez modifier ou remplacer le fichier avant que le chargement puisse reprendre. Sinon, après avoir corrigé la cause de la défaillance, vous pouvez restaurer à un instant dans le passé avant le chargement et renvoyer le fichier. Pour plus d’informations, consultez [Point-in-time rétablissement](USER_PIT.md).
## Utilisation d’instantanés de base de données Amazon RDS pour les points de contrôle de base de données
Si vous chargez des données sur de longues durées, par exemple des heures ou des jours, sans journalisation binaire, utilisez des instantanés de base de données pour fournir des points de contrôle périodiques en matière de sécurité des données. Chaque instantané de base de données crée une copie cohérente de votre instance de base de données, qui sert de point de récupération lors de défaillances du système ou d’événements de corruption de données. Les instantanés de base de données étant rapides, les points de contrôle fréquents ont un impact minimal sur les performances de chargement. Vous pouvez supprimer des instantanés de base de données précédents sans affecter la durabilité ou les capacités de récupération de la base de données. Pour plus d’informations sur les instantanés de base de données, consultez [Gestion des sauvegardes manuelles](USER_ManagingManualBackups.md).
## Réduction des temps de chargement des bases de données
Voici des conseils supplémentaires pour réduire les temps de chargement :
+ Créez tous les index secondaires avant le chargement des données dans les bases de données MariaDB. Contrairement aux autres systèmes de base de données, MariaDB reconstruit la table entière lors de l’ajout ou de la modification d’index secondaires. Ce processus crée une nouvelle table avec les modifications d’index, copie toutes les données et supprime la table d’origine.
+ Chargez les données dans l’ordre des clés primaires. Pour les tables InnoDB, cela peut réduire les temps de chargement de 75 % à 80 % et la taille des fichiers de données de 50 %.
+ Désactivez les contraintes liées aux clés étrangères en définissant `foreign_key_checks` sur `0`. Cela est souvent nécessaire pour les fichiers plats chargés avec `LOAD DATA LOCAL INFILE`. Pour tout chargement, la désactivation des contrôles par clé étrangère accélère le chargement des données. Une fois le chargement terminé, réactivez les contraintes en définissant `1` sur `foreign_key_checks` et vérifiez les données.
+ Chargez les données en parallèle à moins que vos ressources ne soient proches d’une limite. Pour permettre le chargement simultané sur plusieurs segments de table, utilisez des tables partitionnées le cas échéant.
+ Pour réduire la charge d’exécution du code SQL, combinez plusieurs instructions `INSERT` en opérations `INSERT` uniques à valeurs multiples. `mariadb-dump` implémente automatiquement cette optimisation.
+ Réduisez les opérations d’E/S du journal InnoDB en définissant `innodb_flush_log_at_trx_commit` sur `0`. Une fois le chargement terminé, restaurez `innodb_flush_log_at_trx_commit` vers `1`.
**Avertissement**
La définition de `innodb_flush_log_at_trx_commit` sur `0` oblige InnoDB à vider ses journaux toutes les secondes, et non à chaque validation. Ce paramètre améliore les performances, mais peut entraîner la perte de transactions en cas de défaillance du système.
+ Si vous chargez des données dans une instance de base de données ne disposant pas de réplicas en lecture, définissez `sync_binlog` sur `0`. Une fois le chargement terminé, restaurez `sync_binlog parameter` vers `1`.
+ Chargez les données dans une instance de base de données mono-AZ avant de convertir cette instance en déploiement multi-AZ. Si l’instance de base de données utilise déjà un déploiement multi-AZ, le passage à un déploiement mono-AZ pour le chargement des données n’est pas recommandé. Cela n’apporte que des améliorations marginales.
# Importation de données à partir d’une base de données MariaDB externe vers une instance de base de données Amazon RDS for MariaDB
Vous pouvez importer des données à partir d’une base de données MariaDB existante vers une instance de base de données RDS for MariaDB. Pour cela, vous devez copier la base de données avec [mysqldump](https://dev.mysql.com/doc/refman/8.0/en/mysqldump.html) ou [mariadb-dump](https://mariadb.com/kb/en/mariadb-dump/) et la transférer directement dans l’instance de base de données RDS for MariaDB. L’utilitaire de ligne de commande `mysqldump` ou `mariadb-dump` est généralement utilisé pour effectuer des sauvegardes et des transferts de données d’un serveur MariaDB vers un autre. Il est inclus dans les logiciels clients MariaDB.
À partir de MariaDB 11.0.1, vous devez utiliser `mariadb-dump` à la place de `mysqldump`.
Une commande `mysqldump` classique pour déplacer les données d’une base de données externe vers une instance de bases de données Amazon RDS ressemble à l’exemple suivant. Remplacez les valeurs par vos propres informations. Pour les versions 11.0.1 et ultérieures de MariaDB, remplacez `mysqldump` par `mariadb-dump`.
```
mysqldump -u local_user \
--databases database_name \
--single-transaction \
--compress \
--order-by-primary \
--routines=0 \
--triggers=0 \
--events=0 \
-plocal_password | mariadb -u RDS_user \
--port=port_number \
--host=host_name \
-pRDS_password
```
**Important**
Veillez à ne pas laisser d’espace entre l’option `-p` et le mot de passe saisi.
Une bonne pratique de sécurité consiste à spécifier des informations d’identification autres que les invites affichées dans cet exemple.
Assurez-vous que vous êtes conscient des recommandations et des considérations suivantes :
+ Excluez les schémas suivants du fichier de vidage :
+ `sys`
+ `performance_schema`
+ `information_schema`
L’utilitaire `mysqldump` et `mariadb-dump` exclut ces schémas par défaut.
+ Si vous devez migrer des utilisateurs et des privilèges, pensez à utiliser un outil qui génère le langage de contrôle des données (DCL) pour les recréer, tel que l'[pt-show-grants](https://www.percona.com/doc/percona-toolkit/LATEST/pt-show-grants.html)utilitaire.
+ Pour effectuer l'importation, assurez-vous que l'utilisateur qui l'effectue a accès à l'instance de base de données. Pour de plus amples informations, veuillez consulter [Contrôle d’accès par groupe de sécurité](Overview.RDSSecurityGroups.md).
Les paramètres utilisés sont les suivants :
+ `-u local_user` : utilisez ce paramètre pour spécifier un nom d’utilisateur. Lors de la première utilisation de ce paramètre, spécifiez le nom d’un compte utilisateur sur la base de données MariaDB locale que vous identifiez avec le paramètre `--databases`.
+ `--databases database_name` : utilisez ce paramètre pour spécifier le nom de la base de données sur l’instance MariaDB locale que vous souhaitez importer dans Amazon RDS.
+ `--single-transaction` : utilisez ce paramètre pour vérifier que toutes les données chargées depuis la base de données locale sont en cohérence avec un point dans le temps unique. S’il existe d’autres processus qui modifient les données pendant que `mysqldump` ou `mariadb-dump` les lit, l’utilisation de ce paramètre permet de maintenir l’intégrité des données.
+ `--compress` : utilisez ce paramètre pour réduire la consommation de bande passante réseau par compression des données à partir de la base de données locale avant de les envoyer vers Amazon RDS.
+ `--order-by-primary` : utilisez ce paramètre pour réduire le temps de chargement en triant les données de chaque tableau sur par clé primaire.
+ `--routines` : utilisez ce paramètre si des routines telles que des procédures stockées ou des fonctions existent dans la base de données que vous copiez. Définissez le paramètre sur `0` pour exclure les routines pendant le processus d’importation. Ensuite, recréez manuellement les routines dans la base de données Amazon RDS.
+ `--triggers` : utilisez ce paramètre si des déclencheurs existent dans la base de données que vous copiez. Définissez le paramètre sur `0` pour exclure les déclencheurs pendant le processus d’importation. Ensuite, recréez manuellement les déclencheurs dans la base de données Amazon RDS.
+ `--events` : utilisez ce paramètre si des événements existent dans la base de données que vous copiez. Définissez le paramètre sur `0` pour exclure les événements pendant le processus d’importation. Ensuite, recréez manuellement les événements dans la base de données Amazon RDS.
+ `-plocal_password` : utilisez ce paramètre pour spécifier un mot de passe. Lors de la première utilisation de ce paramètre, spécifiez le mot de passe du compte utilisateur identifié avec le premier paramètre `-u`.
+ `-u RDS_user` : utilisez ce paramètre pour spécifier un nom d’utilisateur. Lors de la seconde utilisation de ce paramètre, spécifiez le nom d’un compte utilisateur sur la base de données par défaut pour l’instance de bases de données MariaDB que vous identifiez avec le paramètre `--host`.
+ `--port port_number` : utilisez ce paramètre pour spécifier le port pour votre instance de base de données MariaDB. Par défaut, il s’agit du port 3306, sauf si vous avez modifié la valeur lorsque vous avez créé l’instance de base de données.
+ `--host host_name` : utilisez ce paramètre pour spécifier le nom du système de nom de domaine (DNS) du point de terminaison de l’instance de base de données Amazon RDS, par exemple, `myinstance.123456789012.us-east-1.rds.amazonaws.com`. Vous pouvez trouver la valeur du point de terminaison dans les détails de l’instance de base de données dans la console Amazon RDS.
+ `-pRDS_password` : utilisez ce paramètre pour spécifier un mot de passe. Lors de la seconde utilisation de ce paramètre, vous spécifiez le mot de passe du compte utilisateur identifié par le second paramètre `-u`.
Assurez-vous de créer manuellement les procédures stockées, déclencheurs, fonctions ou événements dans votre base de données Amazon RDS. Si vous avez l’un de ces objets dans la base de données que vous copiez, excluez-les lorsque lors de l’exécution de `mysqldump` ou `mariadb-dump`. Pour ce faire, incluez les paramètres suivants avec votre commande `mysqldump` ou `mariadb-dump` :
+ `--routines=0`
+ `--triggers=0`
+ `--events=0`
**Exemple**
L’exemple suivant copie l’exemple de base de données `world` de l’hôte local sur une instance de bases de données MariaDB. Remplacez les valeurs par vos propres informations.
Pour Linux, macOS ou Unix :
```
sudo mariadb-dump -u local_user \
--databases world \
--single-transaction \
--compress \
--order-by-primary \
--routines=0 \
--triggers=0 \
--events=0 \
-plocal_password | mariadb -u rds_user \
--port=3306 \
--host=my_instance.123456789012.us-east-1.rds.amazonaws.com \
-pRDS_password
```
Pour Windows :
Exécutez la commande suivante dans une invite de commandes ouverte en cliquant avec le bouton droit sur **Invite de commandes** dans le menu Programmes de Windows, puis en choisissant **Exécuter en tant qu’administrateur**. Remplacez les valeurs par vos propres informations.
```
mariadb-dump -u local_user ^
--databases world ^
--single-transaction ^
--compress ^
--order-by-primary ^
--routines=0 ^
--triggers=0 ^
--events=0 ^
-plocal_password | mariadb -u RDS_user ^
--port=3306 ^
--host=my_instance.123456789012.us-east-1.rds.amazonaws.com ^
-pRDS_password
```
**Note**
Une bonne pratique de sécurité consiste à spécifier des informations d’identification autres que les invites affichées dans l’exemple.
# Importation de données vers une instance de base de données Amazon RDS for MariaDB avec une durée d’indisponibilité réduite
Dans certains cas, vous devez importer les données à partir d’une base de données externe MariaDB prenant en charge une application active vers une instance de base de données RDS for MariaDB. Utilisez la procédure suivante pour réduire l’impact sur la disponibilité des applications. Cette procédure peut s’avérer également utile si vous travaillez avec une base de données très volumineuse. À l'aide de cette procédure, vous pouvez réduire le coût de l'importation en réduisant la quantité de données transmises sur le réseau AWS.
Dans cette procédure, vous transférez une copie des données de votre base de données vers une instance Amazon EC2 et vous importez les données dans une nouvelle base de données Amazon RDS. Vous utilisez ensuite la réplication pour intégrer la base de données Amazon RDS up-to-date à votre instance externe active, avant de rediriger votre application vers la base de données Amazon RDS. Si l'instance externe est MariaDB 10.0.24 ou version ultérieure et que l'instance cible est RDS pour MariaDB, configurez la réplication MariaDB en fonction des identifiants de transaction globaux (). GTIDs Sinon, configurez la réplication en fonction des coordonnées des journaux binaires. Nous recommandons la réplication GTID si votre base de données externe la prend en charge, car la réplication GTID est une méthode plus fiable. Pour plus d’informations, consultez [Identifiants de transaction mondiaux](http://mariadb.com/kb/en/mariadb/global-transaction-id/) dans la documentation MariaDB.
Le schéma suivant montre l’importation d’une base de données MariaDB externe dans une base de données MariaDB sur Amazon RDS.
![\[Flux de travail qui montre l’importation d’une base de données MariaDB externe dans une base de données MariaDB sur Amazon RDS.\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/MigrateMariaDBToRDS_1.png)
## Tâche 1 : Créer une copie de votre base de données existante
La première étape du processus de migration d’une grande quantité de données vers une base de données RDS for MariaDB avec une durée d’indisponibilité minimale consiste à créer une copie des données sources.
Le schéma suivant montre la création d’une sauvegarde de base de données MariaDB.
![\[Flux de travail qui montre la création d’une sauvegarde de la base de données MariaDB.\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/MigrateMariaDBToRDS_2.png)
Vous pouvez recourir à l’utilitaire `mysqldump` ou `mariadb-dump` pour créer une sauvegarde de base de données au format SQL ou texte délimité. Dans MariaDB 10.5, le client s’appelle [mariadb-dump](https://mariadb.com/kb/en/mariadb-dump/). À partir de MariaDB 11.0.1, vous devez utiliser `mariadb-dump` à la place de `mysqldump`. Nous vous recommandons d’effectuer un test avec chaque format dans un environnement autre que celui de production afin de déterminer la méthode qui minimise le temps d’exécution de `mysqldump` ou `mariadb-dump`.
Nous vous recommandons également de comparer les performances de `mysqldump` ou `mariadb-dump` avec les avantages offerts par l’utilisation du format texte délimité pour le chargement. Une sauvegarde à l’aide du format texte délimité crée un fichier texte séparé par des tabulations pour chaque table vidée. Pour réduire le temps nécessaire à l’importation de votre base de données, vous pouvez charger ces fichiers en parallèle en utilisant la commande `LOAD DATA LOCAL INFILE`. Pour plus d’informations, consultez [Étape 5 : Charger les données](mariadb-importing-data-any-source.md#mariadb-importing-data-any-source-load-data) dans la procédure Importation de données à partir de n’importe quelle source.
Avant de commencer l’opération de sauvegarde, assurez-vous de définir les options de réplication sur la base de données MariaDB que vous copiez vers Amazon RDS. Les options de réplication incluent l’activation de la journalisation binaire et la configuration d’un ID de serveur unique. La définition de ces options oblige votre serveur à démarrer la journalisation des transactions de base de données et le prépare à être une instance de réplication source ultérieurement dans le processus.
Assurez-vous que vous êtes conscient des recommandations et des considérations suivantes :
+ Utilisez l’option `--single-transaction` avec `mysqldump` ou `mariadb-dump`, car elle vide un état cohérent de la base de données. Pour vous assurer de la validité d’un fichier de vidage, n’exécutez pas les instructions DDL (Data Definition Language) pendant l’exécution de `mysqldump` ou de `mariadb-dump`. Vous pouvez planifier une fenêtre de maintenance pour ces opérations.
+ Excluez les schémas suivants du fichier de vidage :
+ `sys`
+ `performance_schema`
+ `information_schema`
Les utilitaires `mysqldump` et `mariadb-dump` excluent ces schémas par défaut.
+ Si vous devez migrer des utilisateurs et des privilèges, pensez à utiliser un outil qui génère le langage de contrôle des données (DCL) pour les recréer, tel que l'[pt-show-grants](https://www.percona.com/doc/percona-toolkit/LATEST/pt-show-grants.html)utilitaire.
### Pour définir les options de réplication
1. Modifiez le fichier `my.cnf`. Ce fichier se trouve généralement sous `/etc`.
```
sudo vi /etc/my.cnf
```
Ajoutez les options `log_bin` et `server_id` à la section `[mysqld]`. L’option `log_bin` fournit un identifiant de nom de fichier pour les fichiers journaux binaires. L’option `server_id` fournit un identifiant unique pour le serveur dans les relations source/réplica.
L’exemple suivant illustre la section `[mariadb]` mise à jour d’un fichier `my.cnf` :
```
[mariadb]
log-bin
server-id=1
log-basename=master1
binlog-format=mixed
```
Pour plus d’informations, consultez [Setting the Replication Source Configuration](https://mariadb.com/docs/server/ha-and-performance/standard-replication/setting-up-replication) dans la documentation MariaDB.
1. Pour la réplication avec un cluster de bases de données multi-AZ, activez `gtid_strict_mode`. Pour plus d’informations, consultez [gtid\$1strict\$1mode](https://mariadb.com/docs/server/ha-and-performance/standard-replication/gtid#gtid_strict_mode) dans la documentation MariaDB.
L’activation de `gtid_strict_mode` n’est pas requise pour la réplication avec une instance de base de données.
1. Redémarrez le service `mariadb`.
```
sudo service mariadb restart
```
### Pour créer une copie de sauvegarde de votre base de données existante
1. Créez une sauvegarde de vos données à l’aide de l’utilitaire `mysqldump` ou `mariadb-dump`, en spécifiant un format SQL ou un format texte délimité.
Pour améliorer les performances et assurer l’intégrité des données, utilisez les options `--order-by-primary` et `--single-transaction` pour `mysqldump` et `mariadb-dump`.
Pour éviter d’inclure la base de données système MySQL dans la sauvegarde, n’utilisez pas l’option `--all-databases` avec `mysqldump` ou `mariadb-dump`. Pour plus d’informations, consultez [Création d’un instantané de données avec mysqldump](https://dev.mysql.com/doc/mysql-replication-excerpt/8.0/en/replication-howto-mysqldump.html) dans la documentation MySQL.
Utilisez `chmod`, si nécessaire, pour vous assurer que le répertoire où le fichier de sauvegarde est en cours de création est accessible en écriture.
**Important**
Sur Windows, exécutez la fenêtre de commande en tant qu’administrateur.
+ Pour produire une sortie SQL, utilisez la commande suivante. Pour les versions 10.11 et supérieures de MariaDB, remplacez `mariadb-dump` par `mysqldump`.
Pour Linux, macOS ou Unix :
```
sudo mariadb-dump \
--databases database_name \
--master-data=2 \
--single-transaction \
--order-by-primary \
-r backup.sql \
-u local_user \
-ppassword
```
**Note**
Une bonne pratique de sécurité consiste à spécifier des informations d’identification autres que les invites affichées dans l’exemple.
Pour Windows :
```
mariadb-dump ^
--databases database_name ^
--master-data=2 ^
--single-transaction ^
--order-by-primary ^
-r backup.sql ^
-u local_user ^
-ppassword
```
**Note**
Une bonne pratique de sécurité consiste à spécifier des informations d’identification autres que les invites affichées dans l’exemple.
+ Pour produire une sortie à texte délimité, utilisez la commande suivante. Pour les versions 11.01 et ultérieures de MariaDB, remplacez `mysqldump` par `mariadb-dump`.
Pour Linux, macOS ou Unix :
```
sudo mysqldump \
--tab=target_directory \
--fields-terminated-by ',' \
--fields-enclosed-by '"' \
--lines-terminated-by 0x0d0a \
database_name \
--master-data=2 \
--single-transaction \
--order-by-primary \
-ppassword
```
Pour Windows :
```
mysqldump ^
--tab=target_directory ^
--fields-terminated-by "," ^
--fields-enclosed-by """ ^
--lines-terminated-by 0x0d0a ^
database_name ^
--master-data=2 ^
--single-transaction ^
--order-by-primary ^
-ppassword
```
**Note**
Une bonne pratique de sécurité consiste à spécifier des informations d’identification autres que les invites affichées dans l’exemple.
Assurez-vous de créer manuellement les procédures stockées, déclencheurs, fonctions ou événements dans votre base de données Amazon RDS. Si vous avez l’un de ces objets dans la base de données que vous copiez, excluez-les lorsque lors de l’exécution de `mysqldump` ou `mariadb-dump`. Pour ce faire, incluez les arguments suivants dans votre commande `mysqldump` ou `mariadb-dump` :
`--routines=0`
`--triggers=0`
`--events=0`
Lorsque vous exécutez `mysqldump` et spécifiez le format texte délimité, un commentaire `CHANGE MASTER TO` est retourné. Ce commentaire contient le nom du fichier journal maître et son emplacement. Si l’instance externe est la version 10.0.23 ou antérieure de MariaDB, notez les valeurs pour `MASTER_LOG_FILE` et `MASTER_LOG_POS`. Vous avez besoin de ces valeurs lors de la configuration de la réplication.
La sortie suivante est renvoyée pour les versions de MariaDB.
```
-- Position to start replication or point-in-time recovery from
--
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin-changelog.000031', MASTER_LOG_POS=107;
```
1. Si l’instance externe que vous utilisez est MariaDB version 10.0.24 ou ultérieure, utilisez la réplication basée sur le GTID. Exécutez `SHOW MASTER STATUS` sur l’instance MariaDB externe pour obtenir le nom du fichier journal binaire et son emplacement, puis convertissez-les en un GTID en exécutant `BINLOG_GTID_POS` sur l’instance MariaDB externe.
```
SELECT BINLOG_GTID_POS('binary_log_file_name', binary_log_file_position);
```
Notez le GTID renvoyé. Il vous faut le GTID pour configurer la réplication.
1. Compressez les données copiées afin de réduire la quantité de ressources réseau nécessaires pour copier vos données sur la base de données Amazon RDS. Notez la taille du fichier de sauvegarde. Vous avez besoin de cette information lorsque vous déterminez la taille de l'instance Amazon EC2 à créer. Lorsque vous avez terminé, compressez le fichier de sauvegarde à l’aide de GZIP ou de votre utilitaire de compression favori.
+ Pour compresser une sortie SQL, utilisez la commande suivante :
```
gzip backup.sql
```
+ Pour compresser une sortie à texte délimité, utilisez la commande suivante :
```
tar -zcvf backup.tar.gz target_directory
```
## Tâche 2 : Créer une instance Amazon EC2 et copier la base de données compressée
La copie du fichier de sauvegarde compressé de votre base de données sur une instance Amazon EC2 nécessite moins de ressources réseau que l’exécution d’une copie directe de données non compressées entre instances de bases de données. Une fois que vos données sont dans Amazon EC2, vous pouvez les copier directement de cet emplacement vers votre base de données MariaDB. Pour que vous puissiez économiser sur le coût des ressources réseau, votre instance Amazon EC2 doit être Région AWS identique à votre instance de base de données Amazon RDS. Le fait que l'instance Amazon EC2 soit Région AWS identique à votre base de données Amazon RDS réduit également la latence du réseau lors de l'importation.
Le schéma suivant montre la copie de la sauvegarde de base de données vers une instance Amazon EC2.
![\[Flux de travail montrant la copie de la sauvegarde de base de données vers une instance Amazon EC2.\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/MigrateMariaDBToRDS_3.png)
### Pour créer une instance Amazon EC2 et copier vos données
1. Dans l' Région AWS endroit où vous prévoyez de créer la base de données Amazon RDS, créez un cloud privé virtuel (VPC), un groupe de sécurité VPC et un sous-réseau VPC. Assurez-vous que les règles entrantes de votre groupe de sécurité VPC autorisent les adresses IP requises pour que votre application se connecte à AWS. Vous pouvez spécifier une plage d’adresses IP (par exemple, `203.0.113.0/24`) ou un autre groupe de sécurité VPC. Vous pouvez utiliser la [console Amazon VPC](https://console.aws.amazon.com/vpc) pour créer et gérer des sous-réseaux et VPCs des groupes de sécurité. Pour plus d’informations, consultez [Démarrez avec Amazon VPC](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html#getting-started) dans le *Guide de l’utilisateur Amazon Virtual Private Cloud*.
1. Ouvrez la [console Amazon EC2](https://console.aws.amazon.com/ec2) et choisissez celle qui doit contenir Région AWS à la fois votre instance Amazon EC2 et votre base de données Amazon RDS. Lancez une instance Amazon EC2 à l’aide du VPC, du sous-réseau et du groupe de sécurité que vous avez créés à l’étape 1. Vérifiez que vous sélectionnez un type d’instance avec un stockage suffisant pour le fichier de sauvegarde de votre base de données une fois qu’il est décompressé. Pour plus d’informations sur les instances Amazon EC2, consultez [Démarrez avec Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EC2_GetStarted.html) dans le *Guide de l’utilisateur Amazon Elastic Compute Cloud*.
1. Pour vous connecter à votre base de données Amazon RDS à partir de votre instance Amazon EC2, modifiez votre groupe de sécurité VPC. Ajoutez une règle de trafic entrant en spécifiant l’adresse IP privée de votre instance EC2. L’adresse IP privée se trouve sous l’onglet **Détails** du volet **Instance** de la fenêtre de la console EC2. Pour modifier le groupe de sécurité VPC et ajouter une règle de trafic entrant, choisissez **Security Groups** (Groupes de sécurité) dans le panneau de navigation de la console EC2, choisissez votre groupe de sécurité et ajoutez une règle de trafic entrant pour MySQL/Aurora en spécifiant l’adresse IP privée de votre instance EC2. Pour apprendre à ajouter une règle de trafic entrant à un groupe de sécurité VPC, consultez [Règles du groupe de sécurité](https://docs.aws.amazon.com/vpc/latest/userguide/security-group-rules.html) dans le *Guide de l’utilisateur Amazon VPC Private Cloud*.
1. Copiez le fichier de sauvegarde compressé de votre base de données depuis votre système local vers votre instance Amazon EC2. Utilisez `chmod`, si nécessaire, pour vous assurer d’avoir l’autorisation d’écriture dans le répertoire cible de l’instance Amazon EC2. Vous pouvez utiliser `scp` ou un client SSH pour copier le fichier. Voici un exemple de commande `scp` :
```
scp -r -i key pair.pem backup.sql.gz ec2-user@EC2 DNS:/target_directory/backup.sql.gz
```
**Important**
Lorsque vous copiez des données sensibles, assurez-vous d’utiliser un protocole de transfert réseau sécurisé.
1. Connectez-vous à votre instance Amazon EC2, puis installez les dernières mises à jour et les outils clients MariaDB à l’aide des commandes suivantes :
```
sudo yum update -y
sudo yum install mariadb1011-client-utils -y
```
Pour plus d’informations, consultez [Connexion à votre instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EC2_GetStarted.html#ec2-connect-to-instance-linux) pour les instances Linux dans le *Guide de l’utilisateur Amazon Elastic Compute Cloud* et [Connecteurs MariaDB](https://mariadb.com/docs/connectors) dans la documentation MariaDB.
1. Une fois connecté à votre instance Amazon EC2, décompressez le fichier de sauvegarde de votre base de données. Les commandes suivantes sont des exemples.
+ Pour décompresser une sortie SQL, utilisez la commande suivante :
```
gzip backup.sql.gz -d
```
+ Pour décompresser une sortie texte délimité, utilisez la commande suivante :
```
tar xzvf backup.tar.gz
```
## Tâche 3 : Créer une base de données MariaDB et importer les données depuis votre instance Amazon EC2
En créant une instance de base de données RDS pour MariaDB identique à Région AWS votre instance Amazon EC2, vous pouvez importer le fichier de sauvegarde de base de données depuis Amazon EC2 plus rapidement que sur Internet.
Le schéma suivant montre l’importation de la sauvegarde d’une instance Amazon EC2 vers une base de données MariaDB.
![\[Flux de travail montrant l’importation de la sauvegarde de l’instance EC2 vers la base de données MariaDB.\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/MigrateMariaDBToRDS_4.png)
### Pour créer une base de données MariaDB et importer vos données
1. Déterminez quelle classe d’instance de base de données et quelle quantité d’espace de stockage sont nécessaires pour prendre en charge la charge de travail attendue pour cette base de données Amazon RDS. Dans le cadre de ce processus, décidez de l’espace suffisant et de la capacité de traitement qui conviennent à vos procédures de chargement des données. Décidez également ce qui est nécessaire pour gérer la charge de travail de production. Vous pouvez estimer ces éléments en fonction de la taille et des ressources de la base de données source MariaDB. Pour de plus amples informations, veuillez consulter [Classes d'instances de base de données ](Concepts.DBInstanceClass.md).
1. Créez une instance de base de données dans le Région AWS contenant votre instance Amazon EC2. Suivez les instructions présentées dans [Création d'une instance de base de données Amazon RDS](USER_CreateDBInstance.md) et utilisez les directives suivantes :
+ Spécifiez une version du moteur de base de données compatible avec votre instance de base de données source.
+ Spécifiez les mêmes cloud privé virtuel (VPC) et groupe de sécurité VPC que pour votre instance Amazon EC2. Cette approche garantit que votre instance Amazon EC2 et votre instance Amazon RDS sont visibles l’une de l’autre sur le réseau. Assurez-vous que votre instance de base de données est accessible au public. Pour configurer la réplication avec votre base de données source comme décrit dans l’une des sections suivantes, votre instance de base de données doit être publiquement accessible.
+ Ne configurez pas plusieurs zones de disponibilité, la rétention des sauvegardes ou les réplicas en lecture tant que vous n’avez pas importé la sauvegarde de la base de données. Lorsque l'importation est terminée, vous pouvez configurer l'option multi-AZ et la rétention des sauvegardes pour l'instance de production.
1. Vérifiez les options de configuration par défaut de la base de données Amazon RDS. Si le groupe de paramètres par défaut pour la base de données ne dispose pas des options de configuration que vous voulez, trouvez un autre groupe qui les possède ou créez un groupe de paramètres. Pour plus d’informations sur la création d’un groupe de paramètres, consultez [Groupes de paramètres pour Amazon RDS](USER_WorkingWithParamGroups.md).
1. Connectez-vous à la nouvelle base de données Amazon RDS en tant qu’utilisateur principal. Créez ensuite les utilisateurs requis pour prendre en charge les administrateurs, les applications et les services qui doivent accéder à l’instance de base de données. Le nom d’hôte de la base de données Amazon RDS est la valeur **Point de terminaison** de cette instance de base de données sans le numéro de port. Par exemple, `mysampledb.123456789012.us-west-2.rds.amazonaws.com`. Vous pouvez trouver la valeur du point de terminaison dans les détails de la base de données dans la console Amazon RDS.
1. Connectez-vous à votre instance EC2 Amazon. Pour plus d’informations, consultez [Connexion à votre instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EC2_GetStarted.html#ec2-connect-to-instance-linux) pour les instances Linux dans le *Guide de l’utilisateur Amazon Elastic Compute Cloud*.
1. Connectez-vous à votre base de données Amazon RDS comme hôte distant depuis votre instance Amazon EC2 à l’aide de la commande `mysql`. Voici un exemple de commande :
```
mysql -h host_name -P 3306 -u db_master_user -p
```
*host\$1name*Il s'agit du point de terminaison de la base de données Amazon RDS.
1. À l’invite `mysql`, exécutez la commande `source` et transmettez-lui le nom du fichier de vidage de votre base de données. Cette commande charge les données dans l’instance de base de données Amazon RDS.
+ Pour le format SQL, utilisez la commande suivante :
```
MariaDB [(none)]> source backup.sql;
```
+ Pour le format texte délimité, créez d’abord la base de données, s’il ne s’agit pas de la base de données par défaut que vous avez créée lors de la configuration de la base de données Amazon RDS.
```
MariaDB [(none)]> create database database_name;
MariaDB [(none)]> use database_name;
```
Créez ensuite les tables.
```
MariaDB [(none)]> source table1.sql
MariaDB [(none)]> source table2.sql
etc...
```
Enfin, importez les données.
```
MariaDB [(none)]> LOAD DATA LOCAL INFILE 'table1.txt' INTO TABLE table1 FIELDS TERMINATED BY ',' ENCLOSED BY '"' LINES TERMINATED BY '0x0d0a';
MariaDB [(none)]> LOAD DATA LOCAL INFILE 'table2.txt' INTO TABLE table2 FIELDS TERMINATED BY ',' ENCLOSED BY '"' LINES TERMINATED BY '0x0d0a';
etc...
```
Pour améliorer les performances, vous pouvez exécuter ces opérations en parallèle à partir de plusieurs connexions de telle sorte que l’ensemble de vos tables soit créé et chargé simultanément.
**Note**
Si vous avez utilisé des options de mise en forme des données avec `mysqldump` ou `mariadb-dump` lorsque vous avez initialement vidé la table, assurez-vous d’utiliser les mêmes options avec `LOAD DATA LOCAL INFILE` pour garantir une interprétation correcte du contenu du fichier de données.
1. Exécutez une simple requête `SELECT` sur l’une ou les deux tables de la base de données importée afin de vérifier que l’importation s’est déroulée avec succès.
Si vous n'avez plus besoin de l'instance Amazon EC2 utilisée dans cette procédure, mettez-la hors service afin de réduire votre AWS consommation de ressources. Pour mettre fin à une instance EC2, consultez [Terminer une instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/terminating-instances.html#terminating-instances-console) dans le *Guide de l’utilisateur Amazon Elastic Compute Cloud*.
## Tâche 4 : Répliquer les données de votre base de données externe vers votre nouvelle base de données Amazon RDS
Votre base de données source a probablement été mise à jour pendant la copie et le transfert des données vers la base de données MariaDB. Vous pouvez utiliser la réplication pour intégrer la base de données copiée up-to-date à la base de données source.
![\[Flux de travail qui montre la réplication des données de la base de données externe MariaDB vers la base de données sur Amazon RDS.\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/MigrateMariaDBToRDS_5.png)
Les autorisations requises pour démarrer la réplication sur une base de données Amazon RDS sont restreintes et ne sont pas disponibles pour votre utilisateur principal Amazon RDS. Vous devez donc utiliser la procédure stockée Amazon RDS appropriée :
+ [mysql.rds\$1set\$1external\$1master](mysql-stored-proc-replicating.md#mysql_rds_set_external_master)
+ [mysql.rds\$1set\$1external\$1master\$1gtid](mysql_rds_set_external_master_gtid.md) pour configurer la réplication et [mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication) pour la démarrer
### Pour démarrer la réplication
Dans la Tâche 1, [lorsque vous avez défini les options de réplication](#mariadb-importing-data-reduced-downtime-set-replication-options), vous avez activé la journalisation binaire et défini un ID de serveur unique pour votre base de données source. À présent, vous pouvez configurer votre base de données Amazon RDS comme réplica avec votre base de données active comme instance de réplication source.
1. Dans la console Amazon RDS, ajoutez l’adresse IP du serveur qui héberge la base de données source au groupe de sécurité VPC de la base de données Amazon RDS. Pour plus d’informations sur la configuration d’un groupe de sécurité VPC, consultez [Configuration de règles de groupe de sécurité](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-security-group-rules.html) dans le *Guide de l’utilisateur Amazon Virtual Private Cloud*.
Il se peut aussi que vous ayez besoin de configurer votre réseau local pour autoriser les connexions à partir de l’adresse IP de votre base de données Amazon RDS, de telle sorte qu’elle puisse communiquer avec votre instance source. Pour obtenir l’adresse IP de la base de données Amazon RDS, utilisez la commande `host` :
```
host host_name
```
*host\$1name*Il s'agit du nom DNS du point de terminaison de la base de données Amazon RDS, par exemple`myinstance.123456789012.us-east-1.rds.amazonaws.com`. Vous pouvez trouver la valeur du point de terminaison dans les détails de l’instance de base de données dans la console Amazon RDS.
1. A l’aide du client de votre choix, connectez-vous à l’instance source et créez un utilisateur à utiliser pour la réplication. Ce compte est utilisé exclusivement pour la réplication et doit être limité à votre domaine pour améliorer la sécurité. Voici un exemple de commande :
```
CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY 'password';
```
**Note**
Spécifiez des informations d’identification autres que celles affichées ici, en tant que bonne pratique de sécurité.
1. Pour l’instance source, attribuez les privilèges `REPLICATION CLIENT` et `REPLICATION SLAVE` à votre utilisateur de réplication. Par exemple, pour accorder les privilèges `REPLICATION CLIENT` et `REPLICATION SLAVE` sur toutes les bases de données à l’utilisateur « `repl_user` » de votre domaine, émettez la commande suivante :
```
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com';
```
1. Si vous avez utilisé le format SQL pour créer votre fichier de sauvegarde et que l’instance externe n’est pas MariaDB 10.0.24 ou version ultérieure, examinez le contenu de ce fichier en exécutant la commande suivante :
```
cat backup.sql
```
Le fichier inclut un commentaire `CHANGE MASTER TO` qui contient le nom du fichier journal maître et son emplacement. Ce commentaire est inclus dans le fichier de sauvegarde quand vous utilisez l'option `--master-data` avec `mysqldump`. Notez les valeurs pour `MASTER_LOG_FILE` et `MASTER_LOG_POS`.
```
--
-- Position to start replication or point-in-time recovery from
--
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin-changelog.000031', MASTER_LOG_POS=107;
```
Si vous avez utilisé le format texte délimité pour créer votre fichier de sauvegarde et que l’instance externe n’est pas MariaDB 10.0.24 ou version ultérieure, vous devez avoir déjà les coordonnées du journal binaire de l’étape 1 dans la tâche 1 [lorsque vous avez créé une copie de sauvegarde de votre base de données existante](#mariadb-importing-data-reduced-downtime-create-backup).
Si l’instance externe est MariaDB 10.0.24 ou version ultérieure, vous devez déjà avoir le GTID à partir duquel démarrer la réplication de l’étape 2 dans la tâche 1, [lorsque vous avez créé une copie de sauvegarde de votre base de données existante](#mariadb-importing-data-reduced-downtime-create-backup).
1. Transformez la base de données Amazon RDS en réplica. Si l’instance externe ne possède pas la version MariaDB 10.0.24 ou ultérieure, connectez-vous à la base de données Amazon RDS en tant qu’utilisateur principal et identifiez la base de données source comme instance de réplication source à l’aide de la procédure stockée [mysql.rds\$1set\$1external\$1master](mysql-stored-proc-replicating.md#mysql_rds_set_external_master).
Si vous avez un fichier de sauvegarde au format SQL, utilisez le nom et la position du fichier journal maître que vous avez déterminés à l’étape 4. Si vous avez utilisé le format texte délimité, utilisez le nom et la position que vous avez déterminés lors de la création des fichiers de sauvegarde. Voici un exemple de commande :
```
CALL mysql.rds_set_external_master ('myserver.mydomain.com', 3306,
'repl_user', 'password', 'mysql-bin-changelog.000031', 107, 1);
```
**Note**
Spécifiez des informations d’identification autres que celles affichées ici, en tant que bonne pratique de sécurité.
Si l’instance externe possède la version MariaDB 10.0.24 ou ultérieure, connectez-vous à la base de données Amazon RDS en tant qu’utilisateur principal et identifiez la base de données source comme instance de réplication source à l’aide de la procédure stockée [mysql.rds\$1set\$1external\$1master\$1gtid](mysql_rds_set_external_master_gtid.md). Utilisez le GTID défini à l’étape 2 de la tâche 1 [lorsque vous avez créé une copie de sauvegarde de votre base de données existante](#mariadb-importing-data-reduced-downtime-create-backup). Voici un exemple de commande :
```
CALL mysql.rds_set_external_master_gtid ('source_server_ip_address', 3306, 'ReplicationUser', 'password', 'GTID', 1);
```
`source_server_ip_address` est l'adresse IP de l'instance de réplication source. Une adresse DNS privée EC2 n’est pas prise en charge actuellement.
**Note**
Spécifiez des informations d’identification autres que celles affichées ici, en tant que bonne pratique de sécurité.
1. Pour démarrer la réplication sur la base de données Amazon RDS, exécutez la commande suivante qui utilise la procédure stockée [mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication) :
```
CALL mysql.rds_start_replication;
```
1. Sur la base de données Amazon RDS, pour déterminer à quel moment la réplique se trouve up-to-date dans l'instance de réplication source, exécutez la commande [SHOW REPLICA STATUS](https://dev.mysql.com/doc/refman/8.0/en/show-replica-status.html). Les résultats de la commande `SHOW REPLICA STATUS` incluent le champ `Seconds_Behind_Master`. Lorsque le `Seconds_Behind_Master` champ renvoie 0, la réplique correspond up-to-date à l'instance de réplication source.
Pour une instance de base de données MariaDB 10.5, 10.6, 10.11, 11.4 ou 11.8, exécutez la procédure stockée [mysql.rds\$1replica\$1status](mysql_rds_replica_status.md) à la place de la commande MySQL.
1. Une fois la base de données Amazon RDS up-to-date installée, activez les sauvegardes automatiques afin de pouvoir restaurer cette base de données si nécessaire. Vous pouvez activer ou modifier les sauvegardes automatiques de votre base de données Amazon RDS à l’aide de la [console Amazon RDS](https://console.aws.amazon.com/rds/). Pour de plus amples informations, veuillez consulter [Présentation des sauvegardes](USER_WorkingWithAutomatedBackups.md).
## Tâche 5 : Rediriger votre application active vers votre instance Amazon RDS
Une fois que la base de données MariaDB up-to-date est associée à l'instance de réplication source, vous pouvez désormais mettre à jour votre application live pour utiliser l'instance Amazon RDS.
![\[Flux de travail qui montre l’arrêt de la réplication et la direction de l’application active vers la base de données sur Amazon RDS.\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/MigrateMariaDBToRDS_6.png)
### Pour rediriger votre application active vers votre base de données MariaDB et arrêter la réplication
1. Pour ajouter le groupe de sécurité VPC pour la base de données Amazon RDS, ajoutez l’adresse IP du serveur qui héberge l’application. Pour plus d’informations sur la modification d’un groupe de sécurité VPC, consultez [Configuration de règles de groupe de sécurité](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-security-group-rules.html) dans le *Guide de l’utilisateur Amazon Virtual Private Cloud*.
1. Vérifiez que le `Seconds_Behind_Master` champ des résultats de la commande [SHOW REPLICA STATUS](https://dev.mysql.com/doc/refman/8.0/en/show-replica-status.html) est égal à 0, ce qui indique que la réplique est up-to-date associée à l'instance de réplication source.
```
SHOW REPLICA STATUS;
```
Pour une instance de base de données MariaDB 10.5, 10.6, 10.11, 11.4 ou 11.8, exécutez la procédure [mysql.rds\$1replica\$1status](mysql_rds_replica_status.md) à la place de la commande MySQL.
1. Fermez toutes les connexions à la source une fois leurs transactions terminées.
1. Mettez à jour votre application pour utiliser la base de données Amazon RDS. Cette mise à jour implique généralement de modifier les paramètres de connexion pour identifier le nom d'hôte et le port de la base de données Amazon RDS, le compte utilisateur et le mot de passe avec lesquels se connecter, et la base de données à utiliser.
1. Connectez-vous à l’instance de base de données.
1. Arrêtez la réplication pour l’instance Amazon RDS en exécutant la commande suivante qui utilise la procédure stockée [mysql.rds\$1stop\$1replication](mysql-stored-proc-replicating.md#mysql_rds_stop_replication) :
```
CALL mysql.rds_stop_replication;
```
1. Réinitialisez la configuration de réplication de telle sorte que cette instance ne soit plus identifiée comme un réplica en exécutant la commande suivante, qui utilise la procédure stockée [mysql.rds\$1reset\$1external\$1master](mysql-stored-proc-replicating.md#mysql_rds_reset_external_master) sur votre base de données Amazon RDS :
```
CALL mysql.rds_reset_external_master;
```
1. Activez des fonctions Amazon RDS supplémentaires, telles que la prise en charge Multi-AZ et les réplicas en lecture. Pour plus d’informations, consultez [Configuration et gestion d’un déploiement multi-AZ pour Amazon RDS](Concepts.MultiAZ.md) et [Utilisation des réplicas en lecture d'instance de base de données](USER_ReadRepl.md).
# Importation de données depuis n’importe quelle source vers une instance de base de données Amazon RDS for MariaDB
Amazon RDS vous permet de migrer les données MariaDB existantes depuis n’importe quelle source vers une instance de base de données RDS for MariaDB. Vous pouvez transférer des données depuis des bases de données sur site, d’autres fournisseurs de cloud ou des instances de base de données RDS for MariaDB existantes vers votre instance de base de données RDS for MariaDB cible. Cette fonctionnalité vous permet de consolider les bases de données, de mettre en œuvre des solutions de reprise après sinistre ou d’y basculer à partir de bases de données autogérées. Les scénarios courants incluent le passage de serveurs MariaDB auto-hébergés vers des instances de base de données Amazon RDS entièrement gérées, la consolidation de plusieurs bases de données MariaDB en une seule instance de base de données ou la création d’environnements de test avec des données de production. Les sections suivantes fournissent des step-by-step instructions pour importer vos données MariaDB à l'aide de méthodes `mariadb-dump` telles que les fichiers de sauvegarde ou la réplication.
## Étape 1 : Créer les fichiers plats contenant les données à charger
Utilisez un format courant, tel que CSV (valeurs séparées par des virgules), pour stocker les données à charger. Chaque table doit avoir son propre fichier ; les données de plusieurs tables ne peuvent pas être combinées dans le même fichier. Attribuez à chaque fichier le même nom que celui de la table à laquelle il correspond. L’extension du fichier est laissée à votre libre choix. Par exemple, si le nom de la table est `sales`, le nom du fichier peut être `sales.csv` ou `sales.txt`.
Si possible, triez les données sur la clé primaire de la table en cours de chargement. Cela améliore de façon spectaculaire les temps de chargement et réduit le stockage disque requis.
Cette procédure est d'autant plus rapide et efficace que les fichiers ont une petite taille. Si la taille non compressée d’un fichier est supérieure à 1 Gio, scindez-le en plusieurs fichiers et chargez chacun d’eux séparément.
Sur les systèmes Unix (Linux inclus), utilisez la commande `split`. Par exemple, la commande suivante fractionne le fichier `sales.csv` en plusieurs fichiers de moins d’1 Gio, le fractionnement n’intervenant qu’aux sauts de ligne (-C 1 024m). Les noms des nouveaux fichiers incluent des suffixes numériques croissants. La commande suivante génère des fichiers portant des noms tels que `sales.part_00` et `sales.part_01`.
```
split -C 1024m -d sales.csv sales.part_
```
Des utilitaires semblables sont disponibles sur les autres systèmes d’exploitation.
Vous pouvez stocker les fichiers plats n’importe où. Toutefois, lorsque vous chargez les données à l’[Étape 5](#mariadb-importing-data-any-source-load-data), vous devez invoquer le shell `mysql` à partir de l’emplacement où se trouvent les fichiers, ou utiliser le chemin absolu des fichiers lors de l’exécution de `LOAD DATA LOCAL INFILE`.
## Étape 2 : Empêcher les applications d’accéder à l’instance de base de données cible
Avant de démarrer un chargement volumineux, empêchez toute activité d’application d’accéder à l’instance de base de données cible sur laquelle s’effectuera le chargement. Nous le recommandons particulièrement quand d’autres sessions sont susceptibles de modifier les tables chargées ou les tables qu’elles référencent. Cela réduit le risque de violation des contraintes intervenant pendant le chargement et améliore les performances de chargement. Dans le même temps, cela permet également de restaurer l'instance de base de données au point juste antérieur au chargement sans perdre les modifications effectuées par les processus non impliqués dans le chargement.
Il est vrai que cela peut ne pas être possible ou pratique. Si vous ne pouvez pas empêcher les applications d'accéder à l'instance de base de données avant le chargement, prenez les mesures nécessaires pour garantir la disponibilité et l'intégrité de vos données. Les étapes spécifiques requises varient grandement en fonction de cas d’utilisation spécifiques et des exigences du site.
## Étape 3 : Créer un instantané de base de données
Si vous envisagez de charger des données dans une nouvelle instance de base de données qui ne contient aucune donnée, vous pouvez ignorer cette étape. Sinon, nous vous recommandons de créer des instantanés de base de données de l’instance de base de données Amazon RDS cible avant et après le chargement de données. Les instantanés de base de données Amazon RDS sont des sauvegardes complètes de votre instance de base de données qui peuvent être utilisées pour restaurer l’instance de base de données à un état connu. Lorsque vous lancez un instantané de base de données, I/O les opérations sur votre instance de base de données sont momentanément suspendues pendant la sauvegarde de votre base de données.
La création d’un instantané de base de données juste avant le chargement vous permet, si besoin est, de restaurer la base de données à son état avant le chargement. Un instantané de base de données pris immédiatement après le chargement vous évite de devoir charger les données à nouveau en cas d’incident. Vous pouvez également utiliser des instantanés de base de données après le chargement pour importer des données dans de nouvelles instances de base de données.
L'exemple suivant exécute la AWS CLI [create-db-snapshot](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-snapshot.html)commande pour créer un instantané de base de données de l'`AcmeRDS`instance et attribuer l'identifiant à l'instantané de base de données`"preload"`.
Pour Linux, macOS ou Unix :
```
aws rds create-db-snapshot \
--db-instance-identifier AcmeRDS \
--db-snapshot-identifier preload
```
Pour Windows :
```
aws rds create-db-snapshot ^
--db-instance-identifier AcmeRDS ^
--db-snapshot-identifier preload
```
Vous pouvez aussi utiliser la restauration de la fonctionnalité d’instantané de bases de données pour créer des instances de bases de données de test dans le but de réaliser des essais ou pour annuler les modifications effectuées pendant le chargement.
Gardez à l’esprit que la restauration d’une base de données à partir d’un instantané de bases de données crée une nouvelle instance de base de données qui, comme toutes les instances de base de données, possède un point de terminaison et un identifiant unique. Si vous devez restaurer l'instance de base de données sans modifier le point de terminaison, vous devez d'abord supprimer l'instance de base de données de telle sorte que le point de terminaison puisse être réutilisé.
Par exemple, pour créer une instance de base de données pour les essais ou autres tests, vous attribuez à l'instance de base de données son propre identifiant. Dans cet exemple, l'identifiant est `AcmeRDS-2`. L’exemple se connecte à l’instance de base de données à l’aide du point de terminaison associé à `AcmeRDS-2`. Pour plus d'informations, consultez [restore-db-instance-from-db-snapshot](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-db-snapshot.html).
Pour Linux, macOS ou Unix :
```
aws rds restore-db-instance-from-db-snapshot \
--db-instance-identifier AcmeRDS-2 \
--db-snapshot-identifier preload
```
Pour Windows :
```
aws rds restore-db-instance-from-db-snapshot ^
--db-instance-identifier AcmeRDS-2 ^
--db-snapshot-identifier preload
```
Pour réutiliser le point de terminaison existant, il faut d’abord supprimer l’instance de base de données, puis donner le même identifiant à la base de données restaurée. Pour de plus amples informations, veuillez consulter [delete-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/delete-db-instance.html).
L’exemple suivant prend également un instantané de base de données final de l’instance de base de données avant de la supprimer. Cette action est facultative, mais recommandée.
Pour Linux, macOS ou Unix :
```
aws rds delete-db-instance \
--db-instance-identifier AcmeRDS \
--final-db-snapshot-identifier AcmeRDS-Final
aws rds restore-db-instance-from-db-snapshot \
--db-instance-identifier AcmeRDS \
--db-snapshot-identifier preload
```
Pour Windows :
```
aws rds delete-db-instance ^
--db-instance-identifier AcmeRDS ^
--final-db-snapshot-identifier AcmeRDS-Final
aws rds restore-db-instance-from-db-snapshot ^
--db-instance-identifier AcmeRDS ^
--db-snapshot-identifier preload
```
## Étape 4 (facultative) : Désactiver les sauvegardes automatiques Amazon RDS
**Avertissement**
Ne désactivez pas les sauvegardes automatiques si vous devez effectuer une point-in-time restauration.
La désactivation des sauvegardes automatiques est une optimisation des performances et n’est pas requise pour les chargements de données. La désactivation des sauvegardes automatiques efface toutes les sauvegardes existantes. Par conséquent, une fois les sauvegardes automatisées désactivées, la point-in-time restauration n'est pas possible. Les instantanés de bases de données manuels ne sont pas affectés par la désactivation des sauvegardes automatiques. Tous les instantanés manuels de base de données existants demeurent disponibles pour la restauration.
La désactivation des sauvegardes automatiques réduit le temps de chargement de près de 25 %, ainsi que la quantité d'espace de stockage requise pendant le chargement. Si vous envisagez de charger des données dans une nouvelle instance de base de données qui ne contient aucune donnée, la désactivation des sauvegardes constitue un moyen simple d'accélérer le chargement et d'éviter d'utiliser le stockage supplémentaire nécessaire pour les sauvegardes. Cependant, dans certains cas, vous pouvez envisager de charger dans une instance de base de données qui contient déjà des données. Si tel est le cas, évaluez les avantages de la désactivation des sauvegardes par rapport à l'impact de la perte de performance point-in-time-recovery.
Les instances de bases de données ont les sauvegardes automatiques activées par défaut (avec une période de rétention égale à une journée). Pour désactiver les sauvegardes automatiques, définissez la période de rétention des sauvegardes à 0. Après le chargement, vous pouvez réactiver les sauvegardes en définissant la période de rétention des sauvegardes avec une valeur différente de zéro. Pour activer ou désactiver les sauvegardes, Amazon RDS arrête l’instance de base de données, puis la redémarre pour activer ou désactiver la journalisation MariaDB.
Exécutez la AWS CLI `modify-db-instance` commande pour définir la rétention des sauvegardes sur zéro et appliquez la modification immédiatement. Comme la définition de la période de rétention à la valeur zéro nécessite un redémarrage de l’instance de base de données, attendez que le redémarrage soit terminé avant de poursuivre. Pour de plus amples informations, veuillez consulter [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html).
Pour Linux, macOS ou Unix :
```
aws rds modify-db-instance \
--db-instance-identifier AcmeRDS \
--apply-immediately \
--backup-retention-period 0
```
Pour Windows :
```
aws rds modify-db-instance ^
--db-instance-identifier AcmeRDS ^
--apply-immediately ^
--backup-retention-period 0
```
Vous pouvez vérifier l'état de votre instance de base de données à l'aide de la AWS CLI [describe-db-instances](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html)commande. L’exemple suivant montre comment afficher le statut de l’instance de base de données `AcmeRDS`.
```
aws rds describe-db-instances --db-instance-identifier AcmeRDS --query "*[].{DBInstanceStatus:DBInstanceStatus}"
```
Lorsque le statut de l’instance de base de données est `available`, vous êtes prêt à continuer.
## Étape 5 : Charger les données
Pour lire les lignes de vos fichiers plats dans les tables de base de données, utilisez l’instruction MariaDB `LOAD DATA LOCAL INFILE`.
**Note**
Vous devez invoquer le shell `mariadb` à partir de l’emplacement où se trouvent vos fichiers plats, ou utiliser le chemin absolu des fichiers lors de l’exécution de `LOAD DATA LOCAL INFILE`.
L’exemple suivant montre comment charger les données d’un fichier nommé `sales.txt` dans une table nommée `Sales` dans la base de données :
```
MariaDB [(none)]> LOAD DATA LOCAL INFILE 'sales.txt' INTO TABLE Sales FIELDS TERMINATED BY ' ' ENCLOSED BY '' ESCAPED BY '\\';
Query OK, 1 row affected (0.01 sec)
Records: 1 Deleted: 0 Skipped: 0 Warnings: 0
```
Pour plus d’informations sur l’instruction `LOAD DATA`, consultez [LOAD DATA INFILE](https://mariadb.com/docs/server/reference/sql-statements/data-manipulation/inserting-loading-data/load-data-into-tables-or-index/load-data-infile) dans la documentation MariaDB.
## Étape 6 : Réactiver les sauvegardes automatiques Amazon RDS
Si vous avez désactivé les sauvegardes automatiques Amazon RDS lors de l’[étape 4](#mariadb-importing-data-any-source-turn-off-automated-backups), une fois le chargement terminé, réactivez-les en redéfinissant la période de rétention des sauvegardes à la valeur qui était la sienne avant le chargement. Comme noté dans l’étape 4, Amazon RDS redémarre l’instance de base de données. Par conséquent, préparez-vous à une brève interruption de service.
L'exemple suivant exécute la AWS CLI [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html)commande pour activer les sauvegardes automatiques pour l'`AcmeRDS`instance de base de données et définir la période de rétention sur un jour :
Pour Linux, macOS ou Unix :
```
aws rds modify-db-instance \
--db-instance-identifier AcmeRDS \
--backup-retention-period 1 \
--apply-immediately
```
Pour Windows :
```
aws rds modify-db-instance ^
--db-instance-identifier AcmeRDS ^
--backup-retention-period 1 ^
--apply-immediately
```
# Utilisation de la réplication MariaDB dans Amazon RDS
Vous utilisez généralement des réplicas en lecture pour configurer la réplication entre instances de base de données Amazon RDS. Pour obtenir des informations générales sur les réplicas en lecture, consultez [Utilisation des réplicas en lecture d'instance de base de données](USER_ReadRepl.md). Pour obtenir des informations spécifiques sur l’utilisation des réplicas en lecture dans Amazon RDS for MariaDB, consultez [Utilisation de réplicas en lecture MariaDB](USER_MariaDB.Replication.ReadReplicas.md).
Vous pouvez également configurer la réplication en fonction des coordonnées des journaux binaires pour une instance de base de données MariaDB. Pour les instances MariaDB, vous pouvez également configurer la réplication en fonction de global IDs transaction GTIDs (), ce qui améliore la sécurité en cas de crash. Pour de plus amples informations, veuillez consulter [Configuration d’une réplication basée sur GTID avec une instance source externe](MariaDB.Procedural.Replication.GTID.md).
Les autres options de réplication disponibles avec RDS for MariaDB sont les suivantes :
+ Vous pouvez configurer la réplication entre une instance de base de données RDS for MariaDB et une instance MySQL ou MariaDB externe à Amazon RDS. Pour plus d'informations sur la réplication de configuration avec une source externe, consultez [Configuration d’une réplication de position de fichier journal binaire avec une instance source externe](MySQL.Procedural.Importing.External.ReplMariaDB.md).
+ Vous pouvez configurer la réplication de sorte à importer des bases de données d'une instance MySQL ou MariaDB extérieure à Amazon RDS, ou à exporter des bases de données vers de telles instances. Pour plus d’informations, consultez [Importation de données vers une instance de base de données Amazon RDS for MariaDB avec une durée d’indisponibilité réduite](mariadb-importing-data-reduced-downtime.md) et [Exportation de données à partir d'une instance DB MySQL grâce à la réplication](MySQL.Procedural.Exporting.NonRDSRepl.md).
Pour chacune de ces options de réplication, vous pouvez utiliser la réplication basée sur les lignes, basée sur les instructions ou mixte. La réplication basée sur les lignes réplique uniquement les lignes modifiées à la suite d'une instruction SQL. La réplication basée sur les instructions réplique l'ensemble de l'instruction SQL. La réplication mixte utilise la réplication basée sur les instructions chaque fois que possible, mais bascule vers la réplication basée sur les lignes lorsque des instructions SQL présentant un risque pour la réplication basée sur les instructions sont exécutées. La réplication mixte est recommandée dans la plupart des cas. Le format de journalisation binaire de l'instance de base de données détermine si la réplication est basée sur les lignes, basée sur les instructions ou mixte. Pour plus d'informations sur la définition du format de journalisation binaire, consultez la section [Configuration de la journalisation binaire MariaDB](USER_LogAccess.MariaDB.BinaryFormat.md).
Pour en savoir plus sur la compatibilité de réplication entre les versions de MariaDB, consultez [Compatibilité de réplication](https://mariadb.com/kb/en/mariadb-vs-mysql-compatibility/#replication-compatibility) dans la documentation de MariaDB.
**Topics**
+ [
# Utilisation de réplicas en lecture MariaDB
](USER_MariaDB.Replication.ReadReplicas.md)
+ [
# Configuration d’une réplication basée sur GTID avec une instance source externe
](MariaDB.Procedural.Replication.GTID.md)
+ [
# Configuration d’une réplication de position de fichier journal binaire avec une instance source externe
](MySQL.Procedural.Importing.External.ReplMariaDB.md)
# Utilisation de réplicas en lecture MariaDB
Ensuite, vous trouverez des informations spécifiques sur l'utilisation des réplicas en lecture sur Amazon RDS for MariaDB. Pour obtenir des informations générales sur les réplicas en lecture et des instructions pour les utiliser, veuillez consulter [Utilisation des réplicas en lecture d'instance de base de données](USER_ReadRepl.md).
+ [Configuration des filtres de réplication avec MariaDB](USER_MariaDB.Replication.ReadReplicas.ReplicationFilters.md)
+ [Configuration de la réplication différée avec MariaDB](USER_MariaDB.Replication.ReadReplicas.DelayReplication.md)
+ [Mise à jour des réplicas en lecture avec MariaDB](USER_MariaDB.Replication.ReadReplicas.Updates.md)
+ [Utiliser des déploiements de réplicas en lecture Multi-AZ avec MariaDB](USER_MariaDB.Replication.ReadReplicas.MultiAZ.md)
+ [Utilisation de réplicas en lecture en cascade avec RDS for MariaDB](USER_MariaDB.Replication.ReadReplicas.Cascading.md)
+ [Surveillance des réplicas en lecture MariaDB](USER_MariaDB.Replication.ReadReplicas.Monitor.md)
+ [Démarrage et arrêt de la réplication avec des réplicas en lecture MariaDB](USER_MariaDB.Replication.ReadReplicas.StartStop.md)
+ [Résolution d'un problème de réplica en lecture MariaDB](USER_ReadRepl.Troubleshooting.MariaDB.md)
## Configurer des réplicas en lecture avec MariaDB
Avant qu'une instance de base de données MariaDB puisse servir de source de réplication, assurez-vous d'activer les sauvegardes automatiques sur l'instance de base de données source en définissant la période de rétention des sauvegardes avec une valeur différente de 0. Cette exigence s'applique également à un réplica en lecture qui serait l'instance de base de données source d'un autre réplica en lecture.
Vous pouvez créer jusqu'à 15 réplicas en lecture à partir d'une seule instance de base de données au sein de la même région. Pour que la réplication fonctionne de façon efficace, chaque réplica en lecture doit avoir la même quantité de ressources de calcul et de stockage que l'instance de base de données source. Si vous mettez à l'échelle l'instance de base de données source, faites-le également pour les réplicas en lecture.
RDS for MariaDB prend en charge les réplicas en lecture en cascade. Pour apprendre à configurer des réplicas en lecture en cascade, consultez [Utilisation de réplicas en lecture en cascade avec RDS for MariaDB](USER_MariaDB.Replication.ReadReplicas.Cascading.md).
Vous pouvez exécuter simultanément plusieurs actions de création et suppression de réplicas en lecture qui référencent la même instance de base de données source. Lorsque vous effectuez ces actions, restez dans la limite de 15 réplicas en lecture pour chaque instance source.
# Configuration des filtres de réplication avec MariaDB
Vous pouvez utiliser des filtres de réplication pour spécifier quelles bases de données et tables sont répliquées avec un réplica en lecture. Les filtres de réplication peuvent inclure des bases de données et des tables dans la réplication ou les en exclure.
Voici quelques cas d’utilisation pour les filtres de réplication :
+ Pour réduire la taille d’un réplica en lecture. Avec le filtrage de réplication, vous pouvez exclure les bases de données et les tables qui ne sont pas nécessaires sur le réplica en lecture.
+ Pour exclure des bases de données et des tables des réplicas en lecture, pour des raisons de sécurité.
+ Pour répliquer différentes bases de données et tables pour des cas d’utilisation spécifiques au niveau de différents réplicas en lecture. Par exemple, vous pouvez utiliser des réplicas en lecture spécifiques pour l’analyse ou le partage.
+ Pour une instance de base de données qui a des réplicas en lecture dans différentes Régions AWS, pour répliquer différentes bases de données ou tables dans différentes Régions AWS.
**Note**
Vous pouvez également utiliser des filtres de réplication pour spécifier quelles bases de données et tables sont répliquées avec une instance de base de données MariaDB principale configurée en tant que réplica dans une topologie de réplication entrante. Pour plus d’informations sur cette configuration, consultez [Configuration d’une réplication de position de fichier journal binaire avec une instance source externe](MySQL.Procedural.Importing.External.Repl.md).
**Topics**
+ [
## Définition des paramètres de filtrage de la réplication pour RDS for MariaDB
](#USER_MariaDB.Replication.ReadReplicas.ReplicationFilters.Configuring)
+ [
## Limites du filtrage de réplication pour RDS for MariaDB
](#USER_MariaDB.Replication.ReadReplicas.ReplicationFilters.Limitations)
+ [
## Exemples de filtrage de réplication pour RDS for MariaDB
](#USER_MariaDB.Replication.ReadReplicas.ReplicationFilters.Examples)
+ [
## Affichage des filtres de réplication pour un réplica en lecture
](#USER_MariaDB.Replication.ReadReplicas.ReplicationFilters.Viewing)
## Définition des paramètres de filtrage de la réplication pour RDS for MariaDB
Pour configurer des filtres de réplication, définissez les paramètres de filtrage de réplication suivants sur le réplica en lecture :
+ `replicate-do-db` – Répliquer les modifications apportées aux bases de données spécifiées. Lorsque vous définissez ce paramètre pour un réplica en lecture, seules les bases de données spécifiées dans le paramètre sont répliquées.
+ `replicate-ignore-db` – Ne pas répliquer les modifications apportées aux bases de données spécifiées. Lorsque le paramètre `replicate-do-db` est défini pour un réplica en lecture, ce paramètre n’est pas évalué.
+ `replicate-do-table` – Répliquer les modifications apportées aux tables spécifiées. Lorsque vous définissez ce paramètre pour un réplica en lecture, seules les tables spécifiées dans le paramètre sont répliquées. En outre, lorsque le paramètre `replicate-do-db` ou `replicate-ignore-db` est défini, la base de données qui inclut les tables spécifiées doit être incluse dans la réplication avec le réplica en lecture.
+ `replicate-ignore-table` – Ne pas répliquer les modifications apportées aux tables spécifiées. Lorsque le paramètre `replicate-do-table` est défini pour un réplica en lecture, ce paramètre n’est pas évalué.
+ `replicate-wild-do-table` – Répliquer les tables en fonction des modèles de nom de base de données et nom de table spécifiés. Les caractères génériques `%` et `_` sont pris en charge. Lorsque le paramètre `replicate-do-db` ou `replicate-ignore-db` est défini, assurez-vous d’inclure la base de données qui comprend les tables spécifiées dans la réplication avec le réplica en lecture.
+ `replicate-wild-ignore-table` – Ne pas répliquer les tables en fonction des modèles de nom de base de données et de nom de table spécifiés. Les caractères génériques `%` et `_` sont pris en charge. Lorsque le paramètre `replicate-do-table` ou `replicate-wild-do-table` est défini pour un réplica en lecture, ce paramètre n’est pas évalué.
Les paramètres sont évalués dans l’ordre dans lequel ils sont répertoriés. Pour plus d'informations sur le fonctionnement de ces paramètres, consultez [la documentation de MariaDB](https://mariadb.com/kb/en/replication-filters/#replication-filters-for-replication-slaves).
Par défaut, chacun de ces paramètres a une valeur vide. Sur chaque réplica en lecture, vous pouvez utiliser ces paramètres pour définir, modifier et supprimer des filtres de réplication. Lorsque vous définissez l’un de ces paramètres, séparez chaque filtre des autres par une virgule.
Vous pouvez utiliser les caractères génériques `%` et `_` dans les paramètres `replicate-wild-do-table` et `replicate-wild-ignore-table`. Le caractère générique `%` correspond à un nombre quelconque de caractères, et le caractère générique `_` ne correspond qu’à un seul caractère.
Le format de journalisation binaire de l’instance de base de données source est important pour la réplication, car il détermine l’enregistrement des modifications de données. Le réglage du paramètre `binlog_format` détermine si la réplication est basée sur les lignes ou les instructions. Pour plus d’informations, consultez [Configuration de la journalisation binaire MariaDB](USER_LogAccess.MariaDB.BinaryFormat.md).
**Note**
Toutes les instructions DDL (Data Definition Language) sont répliquées en tant qu’instructions, quel que soit le paramètre `binlog_format` de l’instance de base de données source.
## Limites du filtrage de réplication pour RDS for MariaDB
Les limites suivantes s'appliquent au filtrage de réplication pour RDS for MariaDB :
+ Chaque paramètre de filtrage de réplication a une limite de 2 000 caractères.
+ Les virgules ne sont pas prises en charge dans les filtres de réplication.
+ Les options `binlog_do_db` et `binlog_ignore_db` de MariaDB pour le filtrage des journaux binaires ne sont pas prises en charge.
+ Le filtrage de réplication ne prend pas en charge les transactions XA.
Pour plus d’informations, consultez la section [Restrictions on XA Transactions](https://dev.mysql.com/doc/refman/8.0/en/xa-restrictions.html) dans la documentation MySQL.
+ Le filtrage de réplication n'est pas pris en charge pour RDS for MariaDB versions 10.2.
## Exemples de filtrage de réplication pour RDS for MariaDB
Pour configurer le filtrage de réplication pour un réplica en lecture, modifiez les paramètres de filtrage de réplication dans le groupe de paramètres associé au réplica en lecture.
**Note**
Vous ne pouvez pas modifier un groupe de paramètres par défaut. Si le réplica en lecture utilise un groupe de paramètres par défaut, créez un nouveau groupe de paramètres et associez-le au réplica en lecture. Pour plus d’informations sur les groupes de paramètres de base de données, consultez [Groupes de paramètres pour Amazon RDS](USER_WorkingWithParamGroups.md).
Vous pouvez définir des paramètres dans un groupe de paramètres à l’aide de la console AWS Management Console, de la AWS CLI ou de l’API RDS. Pour plus d’informations sur la définition des paramètres, consultez [Modification de paramètres dans un groupe de paramètres de base de données dans Amazon RDS](USER_WorkingWithParamGroups.Modifying.md). Lorsque vous définissez des paramètres dans un groupe de paramètres, toutes les instances de base de données associées au groupe de paramètres utilisent les réglages des paramètres. Si vous définissez les paramètres de filtrage de réplication dans un groupe de paramètres, assurez-vous que le groupe de paramètres est associé uniquement aux réplicas en lecture. Laissez les paramètres de filtrage de réplication vides pour les instances de base de données source.
Les exemples suivants définissent les paramètres à l’aide de la AWS CLI. Ces exemples définissent `ApplyMethod` sur `immediate` de sorte que les modifications de paramètre se produisent immédiatement après la fin de la commande de la CLI. Si vous souhaitez qu’une modification en attente soit appliquée après le redémarrage du réplica en lecture, définissez `ApplyMethod` sur `pending-reboot`.
Les exemples suivants définissent des filtres de réplication :
+ [Including databases in replication](#rep-filter-in-dbs-mariadb)
+ [Including tables in replication](#rep-filter-in-tables-mariadb)
+ [Including tables in replication with wildcard characters](#rep-filter-in-tables-wildcards-mariadb)
+ [Escaping wildcard characters in names](#rep-filter-escape-wildcards-mariadb)
+ [Excluding databases from replication](#rep-filter-ex-dbs-mariadb)
+ [Excluding tables from replication](#rep-filter-ex-tables-mariadb)
+ [Excluding tables from replication using wildcard characters](#rep-filter-ex-tables-wildcards-mariadb)
**Example Inclusion de bases de données dans la réplication**
L’exemple suivant inclut les bases de données `mydb1` et `mydb2` dans la réplication. Lorsque vous définissez `replicate-do-db` pour un réplica en lecture, seules les bases de données spécifiées dans le paramètre sont répliquées.
Pour Linux, macOS ou Unix :
```
aws rds modify-db-parameter-group \
--db-parameter-group-name myparametergroup \
--parameters "[{"ParameterName": "replicate-do-db", "ParameterValue": "mydb1,mydb2", "ApplyMethod":"immediate"}]"
```
Pour Windows :
```
aws rds modify-db-parameter-group ^
--db-parameter-group-name myparametergroup ^
--parameters "[{"ParameterName": "replicate-do-db", "ParameterValue": "mydb1,mydb2", "ApplyMethod":"immediate"}]"
```
**Example Inclusion de tables dans la réplication**
L’exemple suivant inclut les tables `table1` et `table2` dans la base de données `mydb1` dans la réplication.
Pour Linux, macOS ou Unix :
```
aws rds modify-db-parameter-group \
--db-parameter-group-name myparametergroup \
--parameters "[{"ParameterName": "replicate-do-table", "ParameterValue": "mydb1.table1,mydb1.table2", "ApplyMethod":"immediate"}]"
```
Pour Windows :
```
aws rds modify-db-parameter-group ^
--db-parameter-group-name myparametergroup ^
--parameters "[{"ParameterName": "replicate-do-table", "ParameterValue": "mydb1.table1,mydb1.table2", "ApplyMethod":"immediate"}]"
```
**Example Inclusion de tables dans la réplication à l’aide de caractères génériques**
L’exemple suivant inclut des tables dont les noms commencent par `orders` et `returns` dans la base de données `mydb` dans la réplication.
Pour Linux, macOS ou Unix :
```
aws rds modify-db-parameter-group \
--db-parameter-group-name myparametergroup \
--parameters "[{"ParameterName": "replicate-wild-do-table", "ParameterValue": "mydb.orders%,mydb.returns%", "ApplyMethod":"immediate"}]"
```
Pour Windows :
```
aws rds modify-db-parameter-group ^
--db-parameter-group-name myparametergroup ^
--parameters "[{"ParameterName": "replicate-wild-do-table", "ParameterValue": "mydb.orders%,mydb.returns%", "ApplyMethod":"immediate"}]"
```
**Example Échappement de caractères génériques dans les noms**
L'exemple suivant montre comment utiliser le caractère d'échappement `\` pour échapper à un caractère générique faisant partie d'un nom.
Supposons que vous avez plusieurs noms de tables dans la base de données `mydb1` qui commencent par `my_table`, et que vous souhaitez inclure ces tables dans la réplication. Les noms de table incluent un trait de soulignement, qui est également un caractère générique, de sorte que l'exemple échappe le trait de soulignement dans les noms de table.
Pour Linux, macOS ou Unix :
```
aws rds modify-db-parameter-group \
--db-parameter-group-name myparametergroup \
--parameters "[{"ParameterName": "replicate-wild-do-table", "ParameterValue": "my\_table%", "ApplyMethod":"immediate"}]"
```
Pour Windows :
```
aws rds modify-db-parameter-group ^
--db-parameter-group-name myparametergroup ^
--parameters "[{"ParameterName": "replicate-wild-do-table", "ParameterValue": "my\_table%", "ApplyMethod":"immediate"}]"
```
**Example Exclusion de bases de données de la réplication**
L’exemple suivant exclut les bases de données `mydb1` et `mydb2` de la réplication.
Pour Linux, macOS ou Unix :
```
aws rds modify-db-parameter-group \
--db-parameter-group-name myparametergroup \
--parameters "[{"ParameterName": "replicate-ignore-db", "ParameterValue": "mydb1,mydb2", "ApplyMethod":"immediate"}]"
```
Pour Windows :
```
aws rds modify-db-parameter-group ^
--db-parameter-group-name myparametergroup ^
--parameters "[{"ParameterName": "replicate-ignore-db", "ParameterValue": "mydb1,mydb2", "ApplyMethod":"immediate"}]"
```
**Example Exclusion de tables de la réplication**
L'exemple suivant exclut les tables `table1` et `table2` dans la base de données `mydb1` de la réplication.
Pour Linux, macOS ou Unix :
```
aws rds modify-db-parameter-group \
--db-parameter-group-name myparametergroup \
--parameters "[{"ParameterName": "replicate-ignore-table", "ParameterValue": "mydb1.table1,mydb1.table2", "ApplyMethod":"immediate"}]"
```
Pour Windows :
```
aws rds modify-db-parameter-group ^
--db-parameter-group-name myparametergroup ^
--parameters "[{"ParameterName": "replicate-ignore-table", "ParameterValue": "mydb1.table1,mydb1.table2", "ApplyMethod":"immediate"}]"
```
**Example Exclusion de tables de la réplication à l’aide des caractères génériques**
L’exemple suivant exclut de la réplication les tables dont les noms commencent par `orders` et `returns` dans la base de données `mydb`.
Pour Linux, macOS ou Unix :
```
aws rds modify-db-parameter-group \
--db-parameter-group-name myparametergroup \
--parameters "[{"ParameterName": "replicate-wild-ignore-table", "ParameterValue": "mydb.orders%,mydb.returns%", "ApplyMethod":"immediate"}]"
```
Pour Windows :
```
aws rds modify-db-parameter-group ^
--db-parameter-group-name myparametergroup ^
--parameters "[{"ParameterName": "replicate-wild-ignore-table", "ParameterValue": "mydb.orders%,mydb.returns%", "ApplyMethod":"immediate"}]"
```
## Affichage des filtres de réplication pour un réplica en lecture
Vous pouvez afficher les filtres de réplication pour un réplica en lecture de la manière suivante :
+ Vérifiez les réglages des paramètres de filtrage de réplication dans le groupe de paramètres associé au réplica en lecture.
Pour obtenir des instructions, consultez [Affichage des valeurs de paramètres pour un groupe de paramètres de base de données dans Amazon RDS](USER_WorkingWithParamGroups.Viewing.md).
+ Dans un client MariaDB, connectez-vous au réplica en lecture et exécutez l'instruction `SHOW REPLICA STATUS`.
Dans la sortie, les champs suivants affichent les filtres de réplication pour le réplica en lecture :
+ `Replicate_Do_DB`
+ `Replicate_Ignore_DB`
+ `Replicate_Do_Table`
+ `Replicate_Ignore_Table`
+ `Replicate_Wild_Do_Table`
+ `Replicate_Wild_Ignore_Table`
Pour plus d’informations sur ces champs, consultez [Vérification du statut de la réplication](https://dev.mysql.com/doc/refman/8.0/en/replication-administration-status.html) dans la documentation MySQL.
**Note**
Les versions précédentes de MariaDB utilisaient `SHOW SLAVE STATUS` à la place de `SHOW REPLICA STATUS`. Si vous utilisez une version de MariaDB antérieure à la version 10.5, utilisez `SHOW SLAVE STATUS`.
# Configuration de la réplication différée avec MariaDB
Vous pouvez utiliser la réplication retardée comme stratégie pour la reprise après sinistre. Avec la réplication retardée, vous spécifiez la durée minimale, en secondes, pour retarder la réplication de la source vers la réplique de lecture. En cas de sinistre, par exemple la suppression accidentelle d’une table, vous appliquez la procédure suivante pour reprendre rapidement après le sinistre :
+ Arrêtez la réplication vers le réplica en lecture avant que lui soit envoyée la modification qui a provoqué le sinistre.
Pour arrêter la réplication, utilisez la procédure stockée [mysql.rds\$1stop\$1replication](mysql-stored-proc-replicating.md#mysql_rds_stop_replication).
+ Effectuez la promotion du réplica en lecture pour qu’il devienne la nouvelle instance de base de données source, en suivant les instructions figurant dans [Promotion d'un réplica en lecture en instance de bases de données autonome](USER_ReadRepl.Promote.md).
**Note**
La réplication différée est prise en charge pour MariaDB 10.6 et versions ultérieures.
Utilisez des procédures stockées pour configurer la réplication retardée. Vous ne pouvez pas configurer une réplication retardée avec l’AWS Management Console, l’AWS CLI ou l’API Amazon RDS.
Vous pouvez utiliser la réplication basée sur les identifiants de transaction globaux (GTID) dans une configuration de réplication différée.
**Topics**
+ [
## Configuration de la réplication retardée pendant la création du réplica en lecture
](#USER_MariaDB.Replication.ReadReplicas.DelayReplication.ReplicaCreation)
+ [
## Modification de la réplication retardée pour un réplica en lecture existant
](#USER_MariaDB.Replication.ReadReplicas.DelayReplication.ExistingReplica)
+ [
## Promotion d’un réplica en lecture
](#USER_MariaDB.Replication.ReadReplicas.DelayReplication.Promote)
## Configuration de la réplication retardée pendant la création du réplica en lecture
Pour configurer la réplication retardée pour tout réplica en lecture à venir créé à partir d’une instance de base de données, exécutez la procédure stockée [mysql.rds\$1set\$1configuration](mysql-stored-proc-configuring.md#mysql_rds_set_configuration) avec le paramètre `target delay`.
**Pour configurer la réplication retardée pendant la création du réplica en lecture**
1. En utilisant un client MariaDB, connectez-vous à l'instance de base de données MariaDB qui sera la source des répliques en lecture en tant qu'utilisateur principal.
1. Exécutez la procédure stockée [mysql.rds\$1set\$1configuration](mysql-stored-proc-configuring.md#mysql_rds_set_configuration) avec le paramètre `target delay`.
Par exemple, exécutez la procédure stockée suivante pour indiquer que la réplication est retardée d’au moins une heure (3 600 secondes) pour tout réplica en lecture créé à partir de l’instance de base de données actuelle.
```
call mysql.rds_set_configuration('target delay', 3600);
```
**Note**
Une fois cette procédure stockée exécutée, tout réplica en lecture que vous créez en utilisant l’AWS CLI ou l’API Amazon RDS est configuré avec la réplication retardée du nombre de secondes spécifié.
## Modification de la réplication retardée pour un réplica en lecture existant
Pour modifier la réplication retardée pour un réplica en lecture existant, exécutez la procédure stockée [mysql.rds\$1set\$1source\$1delay](mysql-stored-proc-replicating.md#mysql_rds_set_source_delay).
**Pour modifier la réplication retardée pour un réplica en lecture existant**
1. En utilisant un client MariaDB, connectez-vous au réplica en lecture en tant qu'utilisateur principal.
1. Utilisez la procédure stockée [mysql.rds\$1stop\$1replication](mysql-stored-proc-replicating.md#mysql_rds_stop_replication) pour arrêter la réplication.
1. Exécutez la procédure stockée [mysql.rds\$1set\$1source\$1delay](mysql-stored-proc-replicating.md#mysql_rds_set_source_delay).
Par exemple, exécutez la procédure stockée suivante pour indiquer que la réplication vers le réplica en lecture est retardée d’au moins une heure (3 600 secondes).
```
call mysql.rds_set_source_delay(3600);
```
1. Utilisez la procédure stockée [mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication) pour lancer la réplication.
## Promotion d’un réplica en lecture
Après l’arrêt de la réplication, dans un scénario de reprise après sinistre, vous pouvez promouvoir un réplica en lecture comme nouvelle instance de base de données source. Pour en savoir plus sur la promotion d’un réplica en lecture, consultez [Promotion d'un réplica en lecture en instance de bases de données autonome](USER_ReadRepl.Promote.md).
# Mise à jour des réplicas en lecture avec MariaDB
Les réplicas en lecture sont conçus pour prendre en charge les requêtes de lecture, mais vous pouvez avoir besoin de mises à jour ponctuelles. A titre d'exemple, vous pouvez avoir besoin d'ajouter un index, pour accélérer les types spécifiques de requêtes accédant au réplica. Vous pouvez autoriser les mises à jour en affectant au paramètre `read_only` la valeur **0** dans le groupe de paramètres de base de données pour le réplica en lecture.
# Utiliser des déploiements de réplicas en lecture Multi-AZ avec MariaDB
Vous pouvez créer un réplica en lecture à partir de déploiements d'instance de base de données mono-AZ ou multi-AZ. Vous utilisez des déploiements multi-AZ pour améliorer la durabilité et la disponibilité des données critiques, mais vous ne pouvez pas utiliser une instance secondaire multi-AZ pour servir les requêtes en lecture seule. À la place, vous pouvez créer des réplicas en lecture à partir d'instances de base de données multi-AZ à trafic élevé pour décharger les requêtes en lecture seule. Si l'instance source d'un déploiement multi-AZ bascule vers l'instance secondaire, tous les réplicas en lecture associés se mettent automatiquement à utiliser l'instance secondaire (désormais principale) comme source de réplication. Pour plus d'informations, consultez [Configuration et gestion d’un déploiement multi-AZ pour Amazon RDS](Concepts.MultiAZ.md).
Vous pouvez créer un réplica en lecture en tant qu'instance de base de données Multi-AZ. Amazon RDS crée une instance de secours de votre réplica dans une autre zone de disponibilité pour la prise en charge du basculement pour le réplica. La création de votre réplica en lecture en tant qu'instance de base de données multi-AZ est indépendante du fait que la base de données source soit ou non une instance de base de données multi-AZ.
# Utilisation de réplicas en lecture en cascade avec RDS for MariaDB
RDS for MariaDB prend en charge les réplicas en lecture en cascade. Les *réplicas en lecture en cascade* vous permettent de mettre à l'échelle les lectures sans surcharger votre instance de base de données RDS for MariaDB source.
Avec les réplicas en lecture en cascade, votre instance de base de données RDS for MariaDB envoie des données au premier réplica en lecture de la chaîne. Ce réplica en lecture envoie ensuite les données au deuxième réplica de la chaîne, etc. Au final, tous les réplicas en lecture de la chaîne ont reçu les modifications de l'instance de base de données RDS for MariaDB, sans surcharger uniquement l'instance de base de données source.
Vous pouvez créer une série comportant jusqu'à trois réplicas en lecture dans une chaîne à partir d'une instance de base de données RDS for MariaDB source. Par exemple, supposons que vous disposez d'une instance de base de données RDS for MariaDB, `mariadb-main`. Vous pouvez effectuer les actions suivantes :
+ À partir de `mariadb-main`, créez le premier réplica en lecture de la chaîne, `read-replica-1`.
+ Ensuite, à partir de `read-replica-1`, créez le réplica en lecture suivant dans la chaîne, `read-replica-2`.
+ Enfin, à partir de `read-replica-2`, créez le troisième réplica en lecture de la chaîne, `read-replica-3`.
Vous ne pouvez pas créer un autre réplica en lecture au-delà de ce troisième réplica en lecture en cascade dans la série pour `mariadb-main`. Une série complète d'instances allant d'une instance de base de données source RDS for MariaDB jusqu'à la fin d'une série de réplicas en lecture en cascade peut comporter au plus quatre instances de base de données.
Pour que les réplicas en lecture en cascade fonctionnent, les sauvegardes automatisées doivent être activées sur chaque instance de base de données RDS for MariaDB. Pour activer les sauvegardes automatiques sur un réplica en lecture, commencez par créer le réplica en lecture, puis modifiez-le pour activer les sauvegardes automatiques. Pour plus d’informations, consultez [Création d’un réplica en lecture](USER_ReadRepl.Create.md).
Comme pour tout réplica en lecture, vous pouvez promouvoir un réplica en lecture faisant partie d’une cascade. La promotion d’un réplica en lecture depuis une chaîne de réplicas en lecture retire ce réplica de la chaîne. Par exemple, supposons que vous souhaitez déplacer une partie de la charge de travail de votre instance de base de données `mariadb-main` vers une nouvelle instance destinée uniquement au service comptable. En prenant pour hypothèse la chaîne de trois réplicas en lecture de l’exemple, vous décidez de promouvoir `read-replica-2`. La chaîne est affectée comme suit :
+ La promotion de `read-replica-2` le retire de la chaîne de réplication.
+ Il s’agit désormais d’une instance de base de données en lecture/écriture complète.
+ La réplication continue sur `read-replica-3`, tout comme avant la promotion.
+ Votre `mariadb-main` continue la réplication sur `read-replica-1`.
Pour plus d’informations sur la promotion des réplicas en lecture, consultez [Promotion d'un réplica en lecture en instance de bases de données autonome](USER_ReadRepl.Promote.md).
# Surveillance des réplicas en lecture MariaDB
Pour les réplicas en lecture MariaDB, vous pouvez surveiller le retard de réplication dans Amazon CloudWatch en consultant la métrique Amazon RDS `ReplicaLag`. La métrique `ReplicaLag` contient la valeur du champ `Seconds_Behind_Master` de la commande `SHOW REPLICA STATUS`.
**Note**
Les versions précédentes de MariaDB utilisaient `SHOW SLAVE STATUS` à la place de `SHOW REPLICA STATUS`. Si vous utilisez une version de MariaDB antérieure à la version 10.5, utilisez `SHOW SLAVE STATUS`.
Les causes courantes du retard de réplication pour MariaDB sont les suivantes :
+ Une indisponibilité du réseau.
+ L’écriture dans des tables avec des index sur un réplica en lecture. Si le paramètre `read_only` n’a pas pour valeur 0 sur le réplica en lecture, il peut interrompre la réplication.
+ Utilisation d’un moteur de stockage non transactionnel tel que MyISAM. La réplication est uniquement prise en charge pour le moteur de stockage InnoDB sur MariaDB.
Lorsque la métrique `ReplicaLag` atteint 0, le réplica a rattrapé le retard sur l’instance de base de données source. Si la métrique `ReplicaLag` retourne -1, la réplication n’est actuellement pas active. `ReplicaLag`= -1 est équivalent à `Seconds_Behind_Master` = `NULL`.
# Démarrage et arrêt de la réplication avec des réplicas en lecture MariaDB
Vous pouvez arrêter et redémarrer le processus de réplication sur une instance de base de données Amazon RDS en appelant les procédures stockées système [mysql.rds\$1stop\$1replication](mysql-stored-proc-replicating.md#mysql_rds_stop_replication) et [mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication). Vous pouvez procéder ainsi lors d'une réplication entre deux instances Amazon RDS pour des opérations de longue durée, telles que la création d'un grand index. Vous devez également arrêter et démarrer la réplication lors de l'importation ou de l'exportation de bases de données. Pour plus d’informations, consultez [Importation de données vers une instance de base de données Amazon RDS for MariaDB avec une durée d’indisponibilité réduite](mariadb-importing-data-reduced-downtime.md) et [Exportation de données à partir d'une instance DB MySQL grâce à la réplication](MySQL.Procedural.Exporting.NonRDSRepl.md).
Si la réplication est arrêtée pendant plus de 30 jours consécutifs, manuellement ou en raison d'une erreur de réplication, Amazon RDS met fin à la réplication entre l'instance de base de données source et tous les réplicas en lecture. Cela permet d'éviter l'augmentation des besoins en stockage sur l'instance de bases de données source et d'importants délais de basculement. L'instance de base de données du réplica en lecture est toujours disponible. En revanche, la réplication ne peut pas être reprise, car les journaux binaires requis par le réplica en lecture sont supprimés de l'instance de base de données source une fois la réplication terminée. Vous pouvez créer un nouveau réplica en lecture pour l'instance de base de données source afin de rétablir la réplication.
# Résolution d'un problème de réplica en lecture MariaDB
Les technologies de réplication pour MariaDB sont asynchrones. Parce qu’elles sont asynchrones, des augmentations occasionnelles de `BinLogDiskUsage` sur l’instance de base de données source et `ReplicaLag` sur le réplica en lecture sont prévisibles. Par exemple, un volume élevé d’opérations d’écriture sur l’instance de bases de données source peut se produire en parallèle. Tandis que les opérations d’écritures sur le réplica en lecture sont sérialisées à l’aide d’un seul thread d’I/O, ce qui peut conduire à un retard entre l’instance source et le réplica. Pour plus d'informations sur les réplicas en lecture seule dans la documentation MariaDB, consultez [Présentation de la réplication](http://mariadb.com/kb/en/mariadb/replication-overview/).
Vous pouvez effectuer plusieurs opérations pour réduire le retard entre les mises à jour d’une instance de base de données source et les mises à jour suivantes appliquées au réplica en lecture, telles que les opérations suivantes :
+ Dimensionnement d’un réplica en lecture pour qu’il ait une taille de stockage et une classe d’instance de base de données comparables à celles de l’instance de base de données source.
+ Garantie que les réglages des paramètres dans les groupes de paramètres de base de données utilisés par l’instance de base de données source et le réplica en lecture sont compatibles. Pour obtenir plus d’informations et un exemple, reportez-vous à la présentation du paramètre `max_allowed_packet`, plus loin dans cette section.
Amazon RDS surveille l’état de réplication de vos réplicas en lecture et met à jour le champ `Replication State` de l’instance du réplica en lecture avec la valeur `Error` si la réplication s’arrête pour une raison quelconque. Par exemple, dans le cas de requêtes DML exécutées sur votre réplica en lecture qui sont en conflit avec les mises à jour effectuées sur l’instance de base de données source.
Vous pouvez passer en revue les détails de l'erreur associée et déclenchée par le moteur MariaDB, en consultant le champ `Replication Error`. Des événements indiquant l’état du réplica en lecture sont également générés, y compris [RDS-EVENT-0045](USER_Events.Messages.md#RDS-EVENT-0045), [RDS-EVENT-0046](USER_Events.Messages.md#RDS-EVENT-0046) et [RDS-EVENT-0047](USER_Events.Messages.md#RDS-EVENT-0047). Pour plus d’informations sur les événements et l’abonnement aux événements, consultez [Utiliser la notification d'événements d'Amazon RDS](USER_Events.md). Si un message d'erreur MariaDB est retourné, consultez l'erreur dans la [documentation sur les messages d'erreur MariaDB](http://mariadb.com/kb/en/mariadb/mariadb-error-codes/).
Un problème courant susceptible de causer des erreurs de réplication se pose lorsque la valeur du paramètre `max_allowed_packet` d’un réplica en lecture est inférieure à celle du paramètre `max_allowed_packet` de l’instance de base de données source. Le paramètre `max_allowed_packet` est un paramètre personnalisé que vous pouvez définir dans un groupe de paramètres DB utilisé pour spécifier la taille maximale du code DML qui peut être exécuté sur la base de données. Dans certains cas, la valeur du paramètre `max_allowed_packet` dans le groupe de paramètres de base de données associé à une instance de base de données source est inférieure à la valeur du paramètre `max_allowed_packet` dans le groupe de paramètres de base de données associé au réplica en lecture de la source. Le processus de réplication peut alors générer une erreur (Packet bigger than 'max\$1allowed\$1packet' bytes) et arrêter la réplication. Vous pouvez corriger cette erreur en indiquant à la source et au réplica en lecture d'utiliser des groupes de paramètres de base de données avec les mêmes valeurs du paramètre `max_allowed_packet`.
Voici d’autres situations courantes susceptibles de causer des erreurs de réplication :
+ Écriture sur les tables d’un réplica en lecture. Si vous créez des index sur un réplica en lecture, le paramètre `read_only` doit être défini sur **0** pour créer les index. Si vous écrivez dans des tables sur le réplica en lecture, cela peut interrompre la réplication.
+ Lorsqu'elles utilisent un moteur de stockage non transactionnel tel que MyISAM, les réplicas en lecture nécessitent un moteur de stockage transactionnel. La réplication est uniquement prise en charge pour le moteur de stockage InnoDB sur MariaDB.
+ Utilisation de requêtes non déterministes non sécurisées telles que `SYSDATE()`. Pour plus d’informations, consultez [Determination of safe and unsafe statements in binary logging](https://dev.mysql.com/doc/refman/8.0/en/replication-rbr-safe-unsafe.html).
Si vous décidez que vous pouvez ignorer une erreur en toute sécurité, vous pouvez suivre la procédure décrite dans [Ignorer une erreur de réplication pour RDS for MySQL](Appendix.MySQL.CommonDBATasks.SkipError.md). Dans le cas contraire, vous pouvez supprimer le réplica en lecture et créer une instance à l'aide du même identifiant d'instance de base de données de sorte que le point de terminaison reste le même que celui de votre ancien réplica en lecture. Si une erreur de réplication est corrigée, le champ `Replication State` prend la valeur *replicating (réplication en cours)*.
Pour les instances de base de données MariaDB, dans certains cas, les réplicas en lecture ne peuvent pas être basculés vers l'instance secondaire si des événements de journaux binaires (binlog) ne sont pas vidés au cours de la panne. Dans ces situations, supprimez et recréez manuellement les réplicas en lecture. Vous pouvez réduire la probabilité que cela se produise en définissant les valeurs de paramètre suivantes : `sync_binlog=1` et `innodb_flush_log_at_trx_commit=1`. Ces paramètres peuvent réduire les performances. Testez donc leur impact avant d’implémenter les modifications dans un environnement de production.
# Configuration d’une réplication basée sur GTID avec une instance source externe
Vous pouvez configurer la réplication en fonction des identificateurs de transaction globaux (GTIDs) depuis une instance externe de MariaDB de version 10.0.24 ou supérieure vers une instance de base de données RDS pour MariaDB. Suivez ces instructions lorsque vous configurez une instance source externe et un réplica sur Amazon RDS :
+ Surveillez les événements de basculement de l'instance de base de données RDS for MariaDB qui constitue votre réplica. En cas de basculement, l’instance de base de données qui est votre réplica peut alors être recréée sur un nouvel hôte avec une autre adresse réseau. Pour plus d'informations sur la surveillance des événements de basculement, consultez [Utiliser la notification d'événements d'Amazon RDS](USER_Events.md).
+ Tenez à jour les journaux binaires sur votre instance source, jusqu'à ce que vous ayez vérifié qu'ils ont été appliqués au réplica. Cela garantit que vous pouvez restaurer votre instance source en cas de défaillance.
+ Activez les sauvegardes automatiques sur votre instance de base de données MariaDB sur Amazon RDS. L'activation des sauvegardes automatiques garantit que vous pouvez restaurer votre réplica sur un instant donné si vous devez resynchroniser votre instance source et votre réplica. Pour plus d'informations sur les sauvegardes et les Point-In-Time restaurations, consultez[Sauvegarde, restauration et exportation de données](CHAP_CommonTasks.BackupRestore.md).
**Note**
Les autorisations requises pour démarrer la réplication sur une instance de base de données MariaDB sont restreintes et ne sont pas disponibles pour votre utilisateur principal Amazon RDS. Pour cette raison, vous devez utiliser les commandes Amazon RDS, [mysql.rds\$1set\$1external\$1master\$1gtid](mysql_rds_set_external_master_gtid.md) et [mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication) pour configurer la réplication entre votre base de données active et votre base de données RDS for MariaDB.
Pour commencer la réplication entre une instance source externe et une instance de base de données MariaDB sur Amazon RDS, appliquez la procédure suivante.
**Pour démarrer la réplication**
1. Passez l'instance de base de données source MariaDB en lecture seule :
```
mysql> FLUSH TABLES WITH READ LOCK;
mysql> SET GLOBAL read_only = ON;
```
1. Obtenez le GTID actuel de l'instance MariaDB externe. Vous pouvez faire cela en utilisant `mysql` ou l'éditeur de requête de votre choix pour exécuter `SELECT @@gtid_current_pos;`.
Le GTID est formaté comme suit : `--`. Un GTID type ressemble un peu à ceci : **0-1234510749-1728**. Pour plus d'informations sur ces éléments GTIDs et leurs composants, consultez la section [Identifiant de transaction global](http://mariadb.com/kb/en/mariadb/global-transaction-id/) dans la documentation de MariaDB.
1. Copiez la base de données de l'instance externe MariaDB vers l'instance de base de données MariaDB à l'aide de `mysqldump`. Pour les bases de données très volumineuses, il se peut que vous vouliez utiliser la procédure décrite dans [Importation de données vers une instance de base de données Amazon RDS for MariaDB avec une durée d’indisponibilité réduite](mariadb-importing-data-reduced-downtime.md).
Pour Linux, macOS ou Unix :
```
mysqldump \
--databases database_name \
--single-transaction \
--compress \
--order-by-primary \
-u local_user \
-plocal_password | mysql \
--host=hostname \
--port=3306 \
-u RDS_user_name \
-pRDS_password
```
Pour Windows :
```
mysqldump ^
--databases database_name ^
--single-transaction ^
--compress ^
--order-by-primary \
-u local_user \
-plocal_password | mysql ^
--host=hostname ^
--port=3306 ^
-u RDS_user_name ^
-pRDS_password
```
**Note**
Veillez bien à ce qu’il n’y ait pas d’espace entre l’option `-p` et le mot de passe saisi.
Spécifiez un mot de passe autre que celui indiqué ici, en tant que bonne pratique de sécurité.
Utilisez les options `--host`, `--user (-u)`, `--port` et `-p` de la commande `mysql` pour spécifier le nom d'hôte, le nom d'utilisateur, le port et le mot de passe pour vous connecter à votre instance de base de données MariaDB. Le nom d'hôte est le nom DNS du point de terminaison de l'instance de base de données MariaDB, par exemple `myinstance.123456789012.us-east-1.rds.amazonaws.com`. Vous pouvez trouver la valeur du point de terminaison dans les détails de l'instance dans Amazon RDS Management Console.
1. Transformez l'instance source MariaDB en instance accessible de nouveau en écriture.
```
mysql> SET GLOBAL read_only = OFF;
mysql> UNLOCK TABLES;
```
1. Dans la console de gestion Amazon RDS, ajoutez l'adresse IP du serveur qui héberge la base de données MariaDB externe au groupe de sécurité VPC de l'instance de base de données MariaDB. Pour plus d'informations sur la modification d'un groupe de sécurité VPC, accédez à [Groupes de sécurité pour votre VPC](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) dans le *Guide de l'utilisateur Amazon Virtual Private Cloud*.
L'adresse IP peut changer lorsque les conditions suivantes sont réunies :
+ Vous utilisez une adresse IP publique pour la communication entre l'instance source externe et l'instance de base de données.
+ L'instance source externe a été arrêtée et redémarrée.
Si ces conditions sont réunies, vérifiez l'adresse IP avant de l'ajouter.
Vous devrez peut-être aussi configurer votre réseau local de sorte à autoriser les connexions à partir de l'adresse IP de votre instance de base de données MariaDB, pour qu'elle puisse communiquer avec votre instance MariaDB externe. Pour obtenir l'adresse IP de l'instance de base de données MariaDB, utilisez la commande `host`.
```
host db_instance_endpoint
```
Le nom d'hôte est le nom DNS du point de terminaison de l'instance de base de données MariaDB.
1. A l'aide du client de votre choix, connectez-vous à l'instance MariaDB externe et créez un utilisateur MariaDB à utiliser pour la réplication. Ce compte est utilisé exclusivement pour la réplication et doit être limité à votre domaine pour améliorer la sécurité. 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. Pour l'instance MariaDB externe, attribuez les privilèges `REPLICATION CLIENT` et `REPLICATION SLAVE` à votre utilisateur de réplication. Par exemple, pour accorder les privilèges `REPLICATION CLIENT` et `REPLICATION SLAVE` sur toutes les bases de données à l'utilisateur « `repl_user` » de votre domaine, émettez la commande suivante.
```
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com';
```
1. Transformez l'instance de base de données MariaDB en réplica. Connectez-vous à l'instance de base de données MariaDB en tant qu'utilisateur principal et, à l'aide de la commande [mysql.rds\$1set\$1external\$1master\$1gtid](mysql_rds_set_external_master_gtid.md), identifiez la base de données MariaDB externe en tant qu'instance source de réplication. Utilisez le GTID que vous avez déterminé à l'étape 2. Voici un exemple.
```
CALL mysql.rds_set_external_master_gtid ('mymasterserver.mydomain.com', 3306, 'repl_user', 'password', 'GTID', 1);
```
**Note**
Spécifiez un mot de passe autre que celui indiqué ici, en tant que bonne pratique de sécurité.
1. Sur l'instance de base de données MariaDB, utilisez la commande [mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication) pour démarrer la réplication.
```
CALL mysql.rds_start_replication;
```
# Configuration d’une réplication de position de fichier journal binaire avec une instance source externe
Vous pouvez configurer la réplication entre une instance de base de données RDS for MySQL ou MariaDB et une instance MySQL ou MariaDB externe à Amazon RDS en utilisant la réplication de fichiers journaux binaires.
**Topics**
+ [
## Avant de commencer
](#MySQL.Procedural.Importing.External.Repl.BeforeYouBegin)
+ [
## Configuration d’une réplication de position de fichier journal binaire avec une instance source externe
](#MySQL.Procedural.Importing.External.Repl.Procedure)
## Avant de commencer
Vous pouvez configurer la réplication en utilisant la position du fichier journal binaire des transactions répliquées.
Les autorisations requises pour démarrer la réplication sur une instance de base de données Amazon RDS sont restreintes et ne sont pas disponibles pour votre utilisateur principal Amazon RDS. Pour cette raison, assurez-vous d’utiliser les commandes Amazon RDS [mysql.rds\$1set\$1external\$1master (RDS for MariaDB et RDS for MySQL, versions majeures 8.0 et antérieures)](mysql-stored-proc-replicating.md#mysql_rds_set_external_master) ou [mysql.rds\$1set\$1external\$1source (RDS for MySQL, versions majeures 8.4 et ultérieures)](mysql-stored-proc-replicating.md#mysql_rds_set_external_source), et [mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication) pour configurer la réplication entre votre base de données active et votre base de données Amazon RDS.
Pour définir le format de journalisation binaire pour une base de données MySQL ou MariaDB, mettez à jour le paramètre `binlog_format`. Si votre instance de base de données utilise le groupe de paramètres d’instance de base de données par défaut, créez un nouveau groupe de paramètres de base de données pour modifier le paramètre `binlog_format`. Dans MariaDB, MySQL 8.0 et versions antérieures, la valeur par défaut de `binlog_format` est `MIXED`. Cependant, vous pouvez également définir `binlog_format` sur `ROW` ou `STATEMENT` si vous avez besoin d’un format de journaux binaires (binlog) spécifique. Redémarrez votre instance de base de données pour que les modifications prennent effet. Dans MySQL 8.4 et versions ultérieures, la valeur par défaut de `binlog_format` est `ROW`.
Pour plus d’informations sur la configuration du paramètre `binlog_format`, consultez [Configuration d' RDS pour la journalisation binaire MySQL pour les bases de données mono-AZ](USER_LogAccess.MySQL.BinaryFormat.md). Pour plus d’informations sur les implications des différents types de réplication MySQL, consultez [Advantages and Disadvantages of Statement-Based and Row-Based Replication](https://dev.mysql.com/doc/refman/8.0/en/replication-sbr-rbr.html) de la documentation MySQL.
## Configuration d’une réplication de position de fichier journal binaire avec une instance source externe
Suivez ces instructions lorsque vous configurez une instance source externe et un réplica sur Amazon RDS :
+ Surveillez les événements de basculement de l'instance de base de données Amazon RDS qui constitue votre réplica. En cas de basculement, l'instance de base de données qui est votre réplica peut alors être recréée sur un nouvel hôte avec une autre adresse réseau. Pour plus d'informations sur la surveillance des événements de basculement, consultez [Utiliser la notification d'événements d'Amazon RDS](USER_Events.md).
+ Tenez à jour les journaux binaires sur votre instance source jusqu’à ce que vous ayez vérifié qu’ils ont été appliqués au réplica. Cette maintenance garantit que vous pouvez restaurer votre instance source en cas de défaillance.
+ Activez les sauvegardes automatiques sur votre instance de base de données Amazon RDS. L'activation des sauvegardes automatiques garantit que vous pouvez restaurer votre réplica sur un instant donné si vous devez resynchroniser votre instance source et votre réplica. Pour plus d'informations sur les sauvegardes et les point-in-time restaurations, consultez[Sauvegarde, restauration et exportation de données](CHAP_CommonTasks.BackupRestore.md).
**Pour configurer une réplication de position de fichier journal binaire avec une instance source externe**
1. Rendez l'instance MySQL ou MariaDB source accessible en lecture seule.
```
mysql> FLUSH TABLES WITH READ LOCK;
mysql> SET GLOBAL read_only = ON;
```
1. Exécutez la commande `SHOW MASTER STATUS` sur l'instance source MySQL ou MariaDB pour déterminer l'emplacement du journal binaire.
Vous obtenez une sortie similaire à ce qui suit.
```
File Position
------------------------------------
mysql-bin-changelog.000031 107
------------------------------------
```
1. Copiez la base de données de l'instance externe vers l'instance de base de données Amazon RDS à l'aide de `mysqldump`. Pour les bases de données très volumineuses, il se peut que vous vouliez utiliser la procédure décrite dans [Importation de données vers une base de données Amazon RDS for MySQL avec une durée d’indisponibilité réduite](mysql-importing-data-reduced-downtime.md).
Pour Linux, macOS ou Unix :
```
mysqldump --databases database_name \
--single-transaction \
--compress \
--order-by-primary \
-u local_user \
-plocal_password | mysql \
--host=hostname \
--port=3306 \
-u RDS_user_name \
-pRDS_password
```
Pour Windows :
```
mysqldump --databases database_name ^
--single-transaction ^
--compress ^
--order-by-primary ^
-u local_user ^
-plocal_password | mysql ^
--host=hostname ^
--port=3306 ^
-u RDS_user_name ^
-pRDS_password
```
**Note**
Veillez bien à ce qu’il n’y ait pas d’espace entre l’option `-p` et le mot de passe saisi.
Pour spécifier le nom d’hôte, le nom d’utilisateur, le port et le mot de passe afin de vous connecter à votre instance de base de données Amazon RDS, utilisez les options `--host`, `--user (-u)`, `--port` et `-p` dans la commande `mysql`. Le nom d'hôte est le nom DNS du point de terminaison de l'instance de base de données Amazon RDS : par exemple `myinstance.123456789012.us-east-1.rds.amazonaws.com`. Vous pouvez trouver la valeur du point de terminaison dans la AWS Management Console au niveau des détails de l’instance.
1. Rendez l'instance source MySQL ou MariaDB à nouveau accessible en écriture.
```
mysql> SET GLOBAL read_only = OFF;
mysql> UNLOCK TABLES;
```
Pour plus d’informations sur la création de sauvegardes en vue de les utiliser avec la réplication, consultez [la documentation MySQL](https://dev.mysql.com/doc/refman/8.0/en/replication-solutions-backups-read-only.html).
1. Dans le AWS Management Console, ajoutez l'adresse IP du serveur qui héberge la base de données externe au groupe de sécurité du cloud privé virtuel (VPC) pour l'instance de base de données Amazon RDS. Pour plus d’informations sur la modification d’un groupe de sécurité de VPC, consultez [Groupes de sécurité pour votre VPC](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) dans le *Guide de l’utilisateur Amazon Virtual Private Cloud*.
L'adresse IP peut changer lorsque les conditions suivantes sont réunies :
+ Vous utilisez une adresse IP publique pour la communication entre l'instance source externe et l'instance de base de données.
+ L'instance source externe a été arrêtée et redémarrée.
Si ces conditions sont réunies, vérifiez l'adresse IP avant de l'ajouter.
Vous devrez peut-être aussi configurer votre réseau local pour autoriser les connexions à partir de l'adresse IP de votre instance de base de données Amazon RDS. Cela permet la communication entre votre réseau local et votre instance MySQL ou MariaDB externe. Pour obtenir l'adresse IP de l'instance de base de données Amazon RDS, utilisez la commande `host`.
```
host db_instance_endpoint
```
Le nom d'hôte est le nom DNS du point de terminaison de l'instance de base de données Amazon RDS.
1. En utilisant le client de votre choix, connectez-vous à l’instance externe et créez un utilisateur à utiliser pour la réplication. Utilisez ce compte exclusivement pour la réplication et limitez-le à votre domaine pour améliorer la sécurité. 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. Pour l’instance externe, attribuez les privilèges `REPLICATION CLIENT` et `REPLICATION SLAVE` à votre utilisateur de réplication. Par exemple, pour accorder les privilèges `REPLICATION CLIENT` et `REPLICATION SLAVE` sur toutes les bases de données à l'utilisateur « `repl_user` » de votre domaine, émettez la commande suivante.
```
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com';
```
1. Transformez l'instance de base de données Amazon RDS en réplica. Pour cela, connectez-vous d’abord à l’instance de base de données Amazon RDS en tant qu’utilisateur principal. Identifiez ensuite la base de données MySQL ou MariaDB externe comme instance source à l’aide de la commande [mysql.rds\$1set\$1external\$1source (RDS for MySQL, versions majeures 8.4 et ultérieures)](mysql-stored-proc-replicating.md#mysql_rds_set_external_source) ou [mysql.rds\$1set\$1external\$1master (RDS for MariaDB et RDS for MySQL, versions majeures 8.0 et antérieures)](mysql-stored-proc-replicating.md#mysql_rds_set_external_master). Utilisez le nom et la position du fichier journal maître que vous avez déterminés à l’étape 2. Les commandes suivantes sont des exemples.
**MySQL 8.4**
```
CALL mysql.rds_set_external_source ('mysourceserver.mydomain.com', 3306, 'repl_user', 'password', 'mysql-bin-changelog.000031', 107, 1);
```
**MariaDB et MySQL 8.0 et 5.7**
```
CALL mysql.rds_set_external_master ('mymasterserver.mydomain.com', 3306, 'repl_user', 'password', 'mysql-bin-changelog.000031', 107, 1);
```
**Note**
Sur RDS for MySQL, vous pouvez décider d’utiliser la réplication différée en exécutant à la place la procédure stockée [mysql.rds\$1set\$1external\$1source\$1with\$1delay (RDS for MySQL, versions majeures 8.4 et ultérieures)](mysql-stored-proc-replicating.md#mysql_rds_set_external_source_with_delay) ou [mysql.rds\$1set\$1external\$1master\$1with\$1delay (RDS for MariaDB et RDS for MySQL, versions majeures 8.0 et antérieures)](mysql-stored-proc-replicating.md#mysql_rds_set_external_master_with_delay). Sur RDS for MySQL, une des raisons d’utiliser la réplication différée est d’activer la reprise après sinistre avec la procédure stockée [](mysql-stored-proc-replicating.md#mysql_rds_start_replication_until). Actuellement, RDS for MariaDB prend en charge la réplication différée, mais ne prend pas en charge la procédure `mysql.rds_start_replication_until`.
1. Sur l’instance de base de données Amazon RDS, émettez la commande [mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication) pour démarrer la réplication.
```
CALL mysql.rds_start_replication;
```
# Options pour le moteur de base de données MariaDB
La section suivante décrit les options ou fonctions supplémentaires, disponibles pour les instances Amazon RDS exécutant le moteur de base de données MariaDB. Pour activer ces options, vous les ajoutez à un groupe d'options personnalisé, puis associer ce dernier à votre instance de base de données. Pour plus d'informations sur l'utilisation de groupes d'options, consultez [Utilisation de groupes d’options](USER_WorkingWithOptionGroups.md).
Amazon RDS prend en charge les options suivantes pour MariaDB :
| ID d'option | Versions du moteur |
| --- | --- |
| `MARIADB_AUDIT_PLUGIN` | MariaDB versions 10.3 et ultérieures |
## Prise en charge du plugin d'audit MariaDB
Amazon RDS prend en charge l'utilisation du plugin d'audit MariaDB sur les instances de base de données MariaDB. Le plugin d'audit MariaDB enregistre l'activité de la base de données, telle que les utilisateurs qui se connectent à la base de données, les requêtes exécutées sur la base de données et plus encore. L'enregistrement de l'activité de la base de données est stocké dans un fichier journal.
### Paramètres de l'option du plugin d'audit
Amazon RDS prend en charge les paramètres suivants pour l'option de plugin d'audit MariaDB.
**Note**
Si vous ne configurez aucun paramètre d'option dans la console RDS, RDS utilise le paramètre par défaut.
| Paramètre d'option | Valeurs valides | Valeur par défaut | Description |
| --- | --- | --- | --- |
| `SERVER_AUDIT_FILE_PATH` | `/rdsdbdata/log/audit/` | `/rdsdbdata/log/audit/` | Emplacement du fichier journal. Le fichier journal contient l'enregistrement de l'activité spécifiée dans `SERVER_AUDIT_EVENTS`. Pour plus d'informations, veuillez consulter [Liste et affichage des fichiers journaux de base de données](USER_LogAccess.Procedural.Viewing.md) et [Fichiers journaux de base de données MariaDB](USER_LogAccess.Concepts.MariaDB.md). |
| `SERVER_AUDIT_FILE_ROTATE_SIZE` | 1–1000000000 | 1000000 | Taille en octets qui, lorsqu'elle est atteinte, entraîne la rotation du fichier. Pour plus d'informations, consultez [Rotation et conservation des journaux pour MariaDB](USER_LogAccess.MariaDB.LogFileSize.md). |
| `SERVER_AUDIT_FILE_ROTATIONS` | 0–100 | 9 | Nombre de rotations de journaux à enregistrer quand `server_audit_output_type=file`. S'il est défini sur 0, le fichier journal ne pivote jamais. Pour plus d’informations, consultez [Rotation et conservation des journaux pour MariaDB](USER_LogAccess.MariaDB.LogFileSize.md) et [Téléchargement d'un fichier journal de base de données](USER_LogAccess.Procedural.Downloading.md). |
| `SERVER_AUDIT_EVENTS` | `CONNECT`, `QUERY`, `TABLE`, `QUERY_DDL`, `QUERY_DML`, `QUERY_DML_NO_SELECT`, `QUERY_DCL` | `CONNECT`, `QUERY` | Types d'activités à enregistrer dans le journal. L'installation du plugin d'audit MariaDB est elle-même enregistrée. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/Appendix.MariaDB.Options.html) |
| `SERVER_AUDIT_INCL_USERS` | Plusieurs valeurs séparées par des virgules | Aucune | Incluez uniquement l'activité des utilisateurs spécifiés. Par défaut, l'activité est enregistrée pour tous les utilisateurs. `SERVER_AUDIT_INCL_USERS` et `SERVER_AUDIT_EXCL_USERS` sont mutuellement exclusifs. Si vous ajoutez des valeurs à `SERVER_AUDIT_INCL_USERS`, assurez-vous qu'aucune valeur n'est ajoutée à `SERVER_AUDIT_EXCL_USERS`. |
| `SERVER_AUDIT_EXCL_USERS` | Plusieurs valeurs séparées par des virgules | Aucune | Excluez l'activité des utilisateurs spécifiés. Par défaut, l'activité est enregistrée pour tous les utilisateurs. `SERVER_AUDIT_INCL_USERS` et `SERVER_AUDIT_EXCL_USERS` sont mutuellement exclusifs. Si vous ajoutez des valeurs à `SERVER_AUDIT_EXCL_USERS`, assurez-vous qu'aucune valeur n'est ajoutée à `SERVER_AUDIT_INCL_USERS`. L'utilisateur `rdsadmin` interroge la base de données par seconde pour vérifier l'intégrité de la base de données. En fonction de vos autres paramètres, cette activité peut éventuellement provoquer un accroissement considérable et rapide de la taille de votre fichier journal. Si vous n'avez pas besoin d'enregistrer cette activité, ajoutez l'utilisateur `rdsadmin` à la liste `SERVER_AUDIT_EXCL_USERS`. `CONNECT`L'activité est toujours enregistrée pour tous les utilisateurs, même si l'utilisateur est spécifié pour ce paramètre d'option. |
| `SERVER_AUDIT_LOGGING` | `ON` | `ON` | La journalisation est active. La seule valeur valide est `ON`. Amazon RDS ne prend pas en charge la désactivation de la journalisation. Si vous souhaitez désactiver la journalisation, supprimez le plugin d'audit MariaDB. Pour plus d'informations, consultez [Suppression du plugin d'audit MariaDB](#Appendix.MariaDB.Options.AuditPlugin.Remove). |
| `SERVER_AUDIT_QUERY_LOG_LIMIT` | 0–2147483647 | 1 024 | Limite de longueur de la chaîne de requête dans un enregistrement. |
### Ajout du plugin d'audit MariaDB
Le processus général pour ajouter le plugin d'audit MariaDB à une instance de base de données est le suivant :
1. Créer un groupe d'options ou copier ou modifier un groupe existant.
1. Ajoutez l'option au groupe d'options.
1. Associez le groupe d'options à l'instance de base de données.
Une fois que vous ajoutez le plugin d'audit MariaDB, vous n'avez pas besoin de redémarrer votre instance de base de données. Dès que le groupe d'options est actif, l'audit commence immédiatement.
**Pour ajouter le plugin d'audit MariaDB**
1. Déterminez le groupe d'options que vous voulez utiliser. Vous pouvez créer un groupe d'options ou utiliser un groupe d'options existant. Si vous souhaitez utiliser un groupe d'options existant, passez à l'étape suivante. Sinon, créez un groupe d'options de base de données personnalisé. Choisissez **mariadb** pour **Engine** (Moteur), puis la version **10.3** ou ultérieure pour **Major engine version** (Version majeure du moteur). Pour de plus amples informations, consultez [Création d’un groupe d’options](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.Create).
1. Ajoutez l'option **MARIADB\$1AUDIT\$1PLUGIN** pour le groupe d'options et configurez les paramètres de l'option. Pour plus d'informations sur l'ajout d'options, consultez [Ajout d’une option à un groupe d’options](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.AddOption). Pour plus d'informations sur chaque paramètre, consultez [Paramètres de l'option du plugin d'audit](#Appendix.MariaDB.Options.AuditPlugin.Options).
1. Appliquez le groupe d'options à une instance de base de données nouvelle ou existante.
+ Pour une nouvelle instance de base de données, vous appliquez le groupe d'options lorsque vous lancez l'instance. Pour plus d'informations, consultez [Création d'une instance de base de données Amazon RDS](USER_CreateDBInstance.md).
+ Pour une instance de base de données existante, vous appliquez le groupe d'options en modifiant l'instance de base de données et en attachant le nouveau groupe d'options. Pour plus d'informations, consultez [Modification d'une instance de base de données Amazon RDS](Overview.DBInstance.Modifying.md).
### Affichage et téléchargement du journal du plugin d'audit MariaDB
Une fois que vous activez le plugin d'audit MariaDB, vous accéder aux résultats dans les fichiers journaux de la même manière que tous les autres fichiers journaux texte. Les fichiers journaux d'audit se trouvent dans `/rdsdbdata/log/audit/`. Pour plus d'informations sur l'affichage du fichier journal dans la console, consultez [Liste et affichage des fichiers journaux de base de données](USER_LogAccess.Procedural.Viewing.md). Pour plus d'informations sur le téléchargement du fichier journal, consultez [Téléchargement d'un fichier journal de base de données](USER_LogAccess.Procedural.Downloading.md).
### Modification des paramètres de plugin d'audit MariaDB
Une fois que vous activez le plugin d'audit MariaDB, vous pouvez modifier ses paramètres. Pour plus d'informations sur la modification des paramètres d'options, consultez [Modification d’un paramètre d’option](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.ModifyOption). Pour plus d'informations sur chaque paramètre, consultez [Paramètres de l'option du plugin d'audit](#Appendix.MariaDB.Options.AuditPlugin.Options).
### Suppression du plugin d'audit MariaDB
Amazon RDS ne prend pas en charge la désactivation de la journalisation du plugin d'audit MariaDB. Toutefois, vous pouvez supprimer le plugin dans une instance de base de données. Lorsque vous supprimez le plugin d'audit MariaDB, l'instance de base de données est automatiquement redémarrée pour cesser l'audit.
Pour supprimer le plugin d'audit MariaDB d'une instance de base de données, effectuez l'une des actions suivantes :
+ Supprimez l'option de plugin d'audit MariaDB du groupe d'options auquel elle appartient. Ce changement affecte toutes les instances de bases de données qui utilisent le groupe d'options. Pour plus d'informations, consultez [Suppression d’une option d’un groupe d’options](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.RemoveOption)
+ Modifiez l'instance de base de données et spécifiez un groupe d'options différent qui n'inclut pas le plugin. Ce changement affecte une seule instance de base de données. Vous pouvez spécifier le groupe d'options (vide) par défaut, ou un groupe d'options personnalisées différent. Pour plus d'informations, consultez [Modification d'une instance de base de données Amazon RDS](Overview.DBInstance.Modifying.md).
# Paramètres pour MariaDB
Par défaut, une instance de base de données MariaDB utilise un groupe de paramètres DB qui est spécifique à une base de données MariaDB. Ce groupe de paramètres contient certains, mais pas la totalité, des paramètres du groupe de paramètres de base de données Amazon RDS du moteur de base de données MySQL. Il contient également un certain nombre de nouveaux paramètres propres à MariaDB. Pour de plus amples informations sur l'utilisation des groupes de paramètres et sur la définition des paramètres, veuillez consulter [Groupes de paramètres pour Amazon RDS](USER_WorkingWithParamGroups.md).
## Affichage des paramètres MariaDB
Les paramètres RDS for MariaDB sont définis aux valeurs par défaut du moteur de stockage que vous avez sélectionné. Pour plus d’informations sur les paramètres MariaDB, consultez la [documentation MariaDB](http://mariadb.com/kb/en/mariadb/documentation/). Pour plus d’informations sur les moteurs de stockage MariaDB, consultez [Moteurs de stockage pris en charge pour MariaDB sur Amazon RDS](MariaDB.Concepts.Storage.md).
Vous pouvez afficher les paramètres disponibles pour une version spécifique de RDS for MariaDB à l’aide de la console RDS ou de l’ AWS CLI. Pour plus d’informations sur l’affichage des paramètres d’un groupe de paramètres MariaDB dans la console RDS, consultez [Affichage des valeurs de paramètres pour un groupe de paramètres de base de données dans Amazon RDS](USER_WorkingWithParamGroups.Viewing.md).
À l'aide de AWS CLI, vous pouvez afficher les paramètres d'une version de RDS pour MariaDB en exécutant la commande. [https://docs.aws.amazon.com/cli/latest/reference/rds/describe-engine-default-parameters.html](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-engine-default-parameters.html) Spécifiez l'une des valeurs suivantes pour l'option `--db-parameter-group-family` :
+ `mariadb11.8`
+ `mariadb11.4`
+ `mariadb10.11`
+ `mariadb10.6`
+ `mariadb10.5`
+ `mariadb10.4`
+ `mariadb10.3`
Par exemple, pour afficher les paramètres de RDS for MariaDB version 10.6, exécutez la commande suivante.
```
aws rds describe-engine-default-parameters --db-parameter-group-family mariadb10.6
```
Votre résultat ressemble à ce qui suit.
```
{
"EngineDefaults": {
"Parameters": [
{
"ParameterName": "alter_algorithm",
"Description": "Specify the alter table algorithm.",
"Source": "engine-default",
"ApplyType": "dynamic",
"DataType": "string",
"AllowedValues": "DEFAULT,COPY,INPLACE,NOCOPY,INSTANT",
"IsModifiable": true
},
{
"ParameterName": "analyze_sample_percentage",
"Description": "Percentage of rows from the table ANALYZE TABLE will sample to collect table statistics.",
"Source": "engine-default",
"ApplyType": "dynamic",
"DataType": "float",
"AllowedValues": "0-100",
"IsModifiable": true
},
{
"ParameterName": "aria_block_size",
"Description": "Block size to be used for Aria index pages.",
"Source": "engine-default",
"ApplyType": "static",
"DataType": "integer",
"AllowedValues": "1024-32768",
"IsModifiable": false
},
{
"ParameterName": "aria_checkpoint_interval",
"Description": "Interval in seconds between automatic checkpoints.",
"Source": "engine-default",
"ApplyType": "dynamic",
"DataType": "integer",
"AllowedValues": "0-4294967295",
"IsModifiable": true
},
...
```
Pour ne lister que les paramètres modifiables de RDS for MariaDB version 10.6, exécutez la commande suivante.
Pour Linux, macOS ou Unix :
```
aws rds describe-engine-default-parameters --db-parameter-group-family mariadb10.6 \
--query 'EngineDefaults.Parameters[?IsModifiable==`true`]'
```
Pour Windows :
```
aws rds describe-engine-default-parameters --db-parameter-group-family mariadb10.6 ^
--query "EngineDefaults.Parameters[?IsModifiable==`true`]"
```
## Paramètres MySQL qui ne sont pas disponibles
Les paramètres MySQL suivants ne sont pas disponibles dans les groupes de paramètres DB spécifiques à MariaDB :
+ bind\$1address
+ binlog\$1error\$1action
+ binlog\$1gtid\$1simple\$1recovery
+ binlog\$1max\$1flush\$1queue\$1time
+ binlog\$1order\$1commits
+ binlog\$1row\$1image
+ binlog\$1rows\$1query\$1log\$1events
+ binlogging\$1impossible\$1mode
+ block\$1encryption\$1mode
+ core\$1file
+ default\$1tmp\$1storage\$1engine
+ div\$1precision\$1increment
+ end\$1markers\$1in\$1json
+ enforce\$1gtid\$1consistency
+ eq\$1range\$1index\$1dive\$1limit
+ explicit\$1defaults\$1for\$1timestamp
+ gtid\$1executed
+ gtid-mode
+ gtid\$1next
+ gtid\$1owned
+ gtid\$1purged
+ log\$1bin\$1basename
+ log\$1bin\$1index
+ log\$1bin\$1use\$1v1\$1row\$1events
+ log\$1slow\$1admin\$1statements
+ log\$1slow\$1slave\$1statements
+ log\$1throttle\$1queries\$1not\$1using\$1indexes
+ master-info-repository
+ optimizer\$1trace
+ optimizer\$1trace\$1features
+ optimizer\$1trace\$1limit
+ optimizer\$1trace\$1max\$1mem\$1size
+ optimizer\$1trace\$1offset
+ relay\$1log\$1info\$1repository
+ rpl\$1stop\$1slave\$1timeout
+ slave\$1parallel\$1workers
+ slave\$1pending\$1jobs\$1size\$1max
+ slave\$1rows\$1search\$1algorithms
+ storage\$1engine
+ table\$1open\$1cache\$1instances
+ timed\$1mutexes
+ transaction\$1allow\$1batching
+ validate-password
+ validate\$1password\$1dictionary\$1file
+ validate\$1password\$1length
+ validate\$1password\$1mixed\$1case\$1count
+ validate\$1password\$1number\$1count
+ validate\$1password\$1policy
+ validate\$1password\$1special\$1char\$1count
Pour plus d’informations sur les paramètres MySQL, consultez la [documentation MySQL](https://dev.mysql.com/doc/refman/8.0/en/).
# Migration de données d’un instantané de base de données MySQL vers une instance de base de données MariaDB
Vous pouvez migrer un instantané de bases de données RDS for MySQL vers une nouvelle instance de base de données exécutant MariaDB à l'aide de la AWS Management Console, d'AWS CLI ou de l'API Amazon RDS. Vous devez utiliser un instantané de base de données créé à partir d'une instance de base de données Amazon RDS exécutant MySQL 5.6 ou 5.7. Pour savoir comment créer un instantané de base de données RDS for MySQL, consultez [Création d’un instantané de base de données pour une instance de base de données mono-AZ pour Amazon RDS](USER_CreateSnapshot.md).
La migration de l'instantané n'affecte pas l'instance de base de données d'origine à partir de laquelle l'instantané a été pris. Vous pouvez tester et valider la nouvelle instance de base de données avant d'y détourner le trafic en remplacement de l'instance de base de données d'origine.
Après la migration de MySQL vers MariaDB, l'instance de base de données MariaDB est associée au groupe d'options et au groupe de paramètres de base de données par défaut. Après la restauration de l'instantané de base de données, vous pouvez associer un groupe de paramètres de base de données personnalisé à la nouvelle instance de base de données. Toutefois, un groupe de paramètres MariaDB présente un ensemble de variables système configurables différent. Pour connaître les différences entre les variables système MySQL et MariaDB, consultez la page [System Variable Differences Between MariaDB and MySQL](https://mariadb.com/kb/en/system-variable-differences-between-mariadb-and-mysql/). Pour en savoir plus sur les groupes de paramètres de base de données, consultez [Groupes de paramètres pour Amazon RDS](USER_WorkingWithParamGroups.md). Pour en savoir plus sur les groupes d'options, consultez [Utilisation de groupes d’options](USER_WorkingWithOptionGroups.md).
## Exécution de la migration
Vous pouvez migrer un instantané de base de données RDS for MySQL vers une nouvelle instance de base de données MariaDB à l'aide de la AWS Management Console, d'AWS CLI ou de l'API RDS.
### Console
**Pour migrer un instantané de base de données MySQL vers une instance de base de données MariaDB**
1. Connectez-vous à la AWS Management Console et ouvrez la console Amazon RDS à l’adresse [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Dans le panneau de navigation, choisissez **Snapshots (Instantanés)**, puis sélectionnez l’instantané de base de données MySQL que vous souhaitez migrer.
1. Pour **Actions**, choisissez **Migrate shapshot (Migrer l'instantané)**. La page **Migrate database (Migrer la base de données)** apparaît.
1. Pour **Migrate to DB Engine (Migrer vers le moteur de base de données)**, choisissez **mariadb**.
Amazon RDS sélectionne automatiquement la **version du moteur de base de données**. Vous ne pouvez pas modifier la version du moteur de base de données.
![\[La page Procéder à la migration de la base de données pour procéder à la migration de MySQL vers MariaDB dans la console Amazon RDS.\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/MigrateMariaDB.png)
1. Pour les sections restantes, spécifiez vos paramètres d’instance de base de données. Pour plus d’informations sur chaque paramètre, consultez [Paramètres des instances de base de données](USER_CreateDBInstance.Settings.md).
1. Choisissez **Migrate (Migrer)**.
### AWS CLI
Pour migrer les données d’un instantané de base de données MySQL vers une instance de base de données MariaDB, exécutez la commande [https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-db-snapshot.html](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-db-snapshot.html) d’AWS CLI avec les options suivantes :
+ --db-instance-identifier – Nom de l'instance de base de données à créer à partir de l'instantané de base de données.
+ --db-snapshot-identifier – Identifiant de l’instantané de base de données à partir duquel la restauration est effectuée.
+ --engine – Moteur de base de données à utiliser pour la nouvelle instance.
**Example**
Pour Linux, macOS ou Unix :
```
1. aws rds restore-db-instance-from-db-snapshot \
2. --db-instance-identifier newmariadbinstance \
3. --db-snapshot-identifier mysqlsnapshot \
4. --engine mariadb
```
Pour Windows :
```
1. aws rds restore-db-instance-from-db-snapshot ^
2. --db-instance-identifier newmariadbinstance ^
3. --db-snapshot-identifier mysqlsnapshot ^
4. --engine mariadb
```
### « Hello, World\$1 »
Pour migrer les données d'un instantané de base de données MySQL vers une instance de base de données MariaDB, appelez l'opération d'API Amazon RDS [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceFromDBSnapshot.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceFromDBSnapshot.html).
## Incompatibilités entre MariaDB et MySQL
Les incompatibilités entre MySQL et MariaDB sont les suivantes :
+ Vous ne pouvez pas migrer un instantané de base de données créé avec MySQL 8.0 vers MariaDB.
+ Si la base de données MySQL source utilise un hachage de mot de passe SHA256, assurez-vous de réinitialiser les mots de passe utilisateur qui ont été hachés via SHA256 avant de vous connecter à la base de données MariaDB. Le code suivant montre comment réinitialiser un mot de passe qui a été haché via SHA256.
```
SET old_passwords = 0;
UPDATE mysql.user SET plugin = 'mysql_native_password',
Password = PASSWORD('new_password')
WHERE (User, Host) = ('master_user_name', %);
FLUSH PRIVILEGES;
```
+ Si votre compte d'utilisateur principal RDS utilise le hachage de mot de passe SHA-256, assurez-vous de réinitialiser le mot de passe à l'aide de l'AWS Management Console, de la commande [https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) de l'AWS CLI ou de l'opération de l'API RDS [ModifyDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html). Pour plus d’informations sur la modification d’une instance de base de données, consultez [Modification d'une instance de base de données Amazon RDS](Overview.DBInstance.Modifying.md).
+ MariaDB ne prend pas en charge le plugin Memcached. Toutefois, les données utilisées par le plugin Memcached sont stockées dans les tables InnoDB. Après voir migré un instantané de base de données MySQL, vous pouvez accéder aux données utilisées par le plugin Memcached à l'aide de SQL. Pour plus d’informations sur la base de données innodb\$1memcache, consultez la page [InnoDB memcached Plugin Internals](https://dev.mysql.com/doc/refman/8.0/en/innodb-memcached-internals.html).
# Référence MariaDB sur SQL Amazon RDS
La section suivant décrit les procédures stockées système disponibles pour les instances Amazon RDS exécutant le moteur de base de données MariaDB.
Vous pouvez utiliser les procédures système stockées, qui sont disponibles pour les instances de bases de données MySQL et MariaDB. Ces procédures stockées sont documentées dans [Référence des procédures stockées RDS pour MySQL](Appendix.MySQL.SQLRef.md). Les instances de base de données MariaDB prennent en charge toutes les procédures stockées, à l'exception de `mysql.rds_start_replication_until` et `mysql.rds_start_replication_until_gtid`.
En outre, les procédures stockées système suivantes sont prises en charge uniquement pour les instances de base de données Amazon RDS exécutant MariaDB :
+ [mysql.rds\$1replica\$1status](mysql_rds_replica_status.md)
+ [mysql.rds\$1set\$1external\$1master\$1gtid](mysql_rds_set_external_master_gtid.md)
+ [mysql.rds\$1kill\$1query\$1id](mysql_rds_kill_query_id.md)
+ [mysql.rds\$1execute\$1operation](mysql_rds_execute_operation.md)
# mysql.rds\$1replica\$1status
Affiche l'état de réplication d'un réplica en lecture MariaDB.
Appelez cette procédure sur le réplica en lecture pour afficher les informations d'état sur les paramètres essentiels des threads du réplica.
## Syntaxe
```
CALL mysql.rds_replica_status;
```
## Notes d'utilisation
Cette procédure est uniquement prise en charge pour les instances de base de données MariaDB exécutant MariaDB version 10.5 et ultérieure.
Cette procédure est l'équivalent de la commande `SHOW REPLICA STATUS`. Cette commande n'est pas prise en charge pour les instances de base de données MariaDB version 10.5 et ultérieures.
Dans les versions antérieures de MariaDB, la commande `SHOW SLAVE STATUS` équivalente exigeait le privilège `REPLICATION SLAVE`. Dans MariaDB version 10.5, elle requiert le privilège `REPLICATION REPLICA ADMIN`. Pour protéger la gestion RDS des instances de base de données MariaDB 10.5 et versions ultérieures, ce nouveau privilège n'est pas accordé à l'utilisateur principal RDS.
## Exemples
L'exemple suivant montre l'état d'un réplica en lecture MariaDB :
```
call mysql.rds_replica_status;
```
La réponse est similaire à ce qui suit :
```
*************************** 1. row ***************************
Replica_IO_State: Waiting for master to send event
Source_Host: XX.XX.XX.XXX
Source_User: rdsrepladmin
Source_Port: 3306
Connect_Retry: 60
Source_Log_File: mysql-bin-changelog.003988
Read_Source_Log_Pos: 405
Relay_Log_File: relaylog.011024
Relay_Log_Pos: 657
Relay_Source_Log_File: mysql-bin-changelog.003988
Replica_IO_Running: Yes
Replica_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table: mysql.rds_sysinfo,mysql.rds_history,mysql.rds_replication_status
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Source_Log_Pos: 405
Relay_Log_Space: 1016
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: 0
Source_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Source_Server_Id: 807509301
Source_SSL_Crl:
Source_SSL_Crlpath:
Using_Gtid: Slave_Pos
Gtid_IO_Pos: 0-807509301-3980
Replicate_Do_Domain_Ids:
Replicate_Ignore_Domain_Ids:
Parallel_Mode: optimistic
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Replica_SQL_Running_State: Reading event from the relay log
Replica_DDL_Groups: 15
Replica_Non_Transactional_Groups: 0
Replica_Transactional_Groups: 3658
1 row in set (0.000 sec)
Query OK, 0 rows affected (0.000 sec)
```
# mysql.rds\$1set\$1external\$1master\$1gtid
Configure la réplication GTID d'une instance MariaDB s'exécutant à l'extérieur de Amazon RDS à une instance de base de données MariaDB. Cette procédure stockée est prise en charge uniquement lorsque l'instance MariaDB externe est à la version 10.0.24 ou ultérieure. Lors de la configuration d'une réplication où une ou les deux instances ne prennent pas en charge les identificateurs de transaction globaux (GTID) MariaDB, utilisez [mysql.rds\$1set\$1external\$1master (RDS for MariaDB et RDS for MySQL, versions majeures 8.0 et antérieures)](mysql-stored-proc-replicating.md#mysql_rds_set_external_master).
L'utilisation de GTID pour la réplication fournit des fonctions de sécurité en cas d'incident non proposées par une réplication de journal binaire. Nous la recommandons donc dans les situations où les instances de réplication assurent une prise en charge.
## Syntaxe
```
CALL mysql.rds_set_external_master_gtid(
host_name
, host_port
, replication_user_name
, replication_user_password
, gtid
, ssl_encryption
);
```
## Paramètres
*host\$1name*
String. Nom d'hôte ou adresse IP de l'instance MariaDB s'exécutant à l'extérieur de Amazon RDS et qui deviendra l'instance source.
*host\$1port*
Entier : Port utilisé par l'instance MariaDB s'exécutant à l'extérieur de Amazon RDS pour une configuration comme instance source. Si votre configuration réseau inclut une réplication de port SSH qui convertit le numéro de port, spécifiez le numéro de port qui est exposé par SSH.
*replication\$1user\$1name*
String. L'ID d'un utilisateur avec les autorisations `REPLICATION SLAVE` de l'instance de base de données MariaDB à configurer comme réplica en lecture.
*replication\$1user\$1password*
String. Mot de passe de l'ID utilisateur spécifié dans `replication_user_name`.
*gtid*
String. L'ID de transaction global sur l'instance source à partir de laquelle la réplication doit démarrer.
Vous pouvez utiliser `@@gtid_current_pos` pour obtenir le GTID actuel si l'instance source a été verrouillée pendant que vous configurez la réplication, afin que le journal binaire ne change pas entre les moments où vous obtenez le GTID et celui où la réplication démarre.
Sinon, si vous utilisez `mysqldump` version 10.0.13, ou ultérieure, pour remplir l'instance de réplica avant de démarrer la réplication, vous pouvez obtenir la position GTID dans le résultat en utilisant les options `--master-data` ou `--dump-slave`. Si vous n'utilisez pas `mysqldump` version 10.0.13 ou ultérieure, vous pouvez exécuter le `SHOW MASTER STATUS` ou les mêmes options `mysqldump` pour obtenir la position et le nom du fichier journal binaire, puis les convertir dans un GTID en exécutant `BINLOG_GTID_POS` sur l'instance MariaDB :
```
SELECT BINLOG_GTID_POS('', );
```
Pour plus d'informations sur l'implémentation MariaDB de GTID, accédez à [ID de transaction global](http://mariadb.com/kb/en/mariadb/global-transaction-id/) dans la documentation MariaDB.
*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
La procédure `mysql.rds_set_external_master_gtid` doit être exécutée par l'utilisateur maître. Elle doit être exécutée sur l'instance de base de données MariaDB que vous configurez comme le réplica d'une instance MariaDB s'exécutant à l'extérieur de Amazon RDS. Avant d'exécuter `mysql.rds_set_external_master_gtid`, vous devez avoir configuré l'instance de MariaDB s'exécutant en dehors de Amazon RDS comme instance source. Pour plus d'informations, consultez [Importation de données dans une instance de base de données Amazon RDS for MariaDB](MariaDB.Procedural.Importing.md).
**Avertissement**
N'utilisez pas `mysql.rds_set_external_master_gtid` pour gérer la réplication entre deux instances de base de données Amazon RDS. N'utilisez la procédure que lors de la réplication avec une instance MariaDB s'exécutant à l'extérieur de RDS. Pour plus d'informations sur la gestion de la réplication entre les instances de base de données Amazon RDS, consultez [Utilisation des réplicas en lecture d'instance de base de données](USER_ReadRepl.md).
Après avoir appelé `mysql.rds_set_external_master_gtid` pour configurer une instance de base de données Amazon RDS comme réplica en lecture, vous pouvez appeler [mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication) sur le réplica pour démarrer le processus de réplication. Vous pouvez appeler [mysql.rds\$1reset\$1external\$1master (RDS for MariaDB et RDS for MySQL, versions majeures 8.0 et antérieures)](mysql-stored-proc-replicating.md#mysql_rds_reset_external_master) pour supprimer la configuration du réplica en lecture.
Quand la procédure `mysql.rds_set_external_master_gtid` 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
Lorsqu'il est exécuté sur une instance de base de données MariaDB, l'exemple suivant la configure comme le réplica d'une instance de MariaDB s'exécutant à l'extérieur de Amazon RDS.
```
call mysql.rds_set_external_master_gtid ('Sourcedb.some.com',3306,'ReplicationUser','SomePassW0rd','0-123-456',0);
```
# mysql.rds\$1kill\$1query\$1id
Termine une requête s’exécutant sur le serveur MariaDB afin de mettre fin aux requêtes s’exécutant sur le long terme ou posant problème. Vous pouvez identifier l’ID de requête et arrêter efficacement une requête spécifique pour résoudre les problèmes de performances et maintenir un fonctionnement optimal de la base de données.
## Syntaxe
```
CALL mysql.rds_kill_query_id(queryID);
```
## Paramètres
*queryID*
Entier : L'identité de la requête à terminer.
## Notes d'utilisation
Pour arrêter une requête s'exécutant sur le serveur MariaDB, utilisez la procédure `mysql.rds_kill_query_id` et transmettez-lui l'ID de cette requête. Pour obtenir l'ID de requête, interrogez [Information Schema PROCESSLIST Table](http://mariadb.com/kb/en/mariadb/information-schema-processlist-table/) de MariaDB, comme indiqué ci-après :
```
SELECT USER, HOST, COMMAND, TIME, STATE, INFO, QUERY_ID FROM
INFORMATION_SCHEMA.PROCESSLIST WHERE USER = '';
```
La connexion au serveur MariaDB est conservée.
## Exemples
L'exemple suivant termine une requête avec un ID de requête 230040 :
```
call mysql.rds_kill_query_id(230040);
```
# mysql.rds\$1execute\$1operation
Exécute des opérations InnoDB pour gérer les états du pool de mémoire tampon et le tablespace temporaire. Cette procédure peut être utilisée pour contrôler dynamiquement les opérations InnoDB telles que le vidage et le chargement des états du pool de mémoire tampon ou la troncation d’un tablespace temporaire.
## Syntaxe
```
CALL mysql.rds_execute_operation(operation);
```
## Paramètres
*fonctionnement*
String. Les opérations InnoDB à exécuter. Les valeurs valides sont :
+ *innodb\$1buffer\$1pool\$1dump\$1now* : opération qui vide l’état actuel du pool de tampons.
+ *innodb\$1buffer\$1pool\$1load\$1now* : opération qui charge l’état du pool de mémoire tampon enregistré.
+ *innodb\$1buffer\$1pool\$1load\$1abort* : opération qui interrompt une opération de chargement du pool de mémoire tampon.
+ *innodb\$1truncate\$1temporary\$1tablespace\$1now* : opération qui tronque le tablespace temporaire.
## Notes d’utilisation
Cette procédure n'est prise en charge que pour les instances de base de données MariaDB exécutant MariaDB version 11.8 ou supérieure.
Pendant l’exécution, la journalisation binaire est temporairement désactivée pour empêcher la réplication de ces commandes administratives.
La procédure gère une piste d’audit en enregistrant toutes les opérations dans la table [https://mariadb.com/docs/server/security/securing-mariadb/securing-mariadb-encryption/data-in-transit-encryption/securing-connections-for-client-and-server#requiring-tls](https://mariadb.com/docs/server/security/securing-mariadb/securing-mariadb-encryption/data-in-transit-encryption/securing-connections-for-client-and-server#requiring-tls).
## Exemples
L’exemple suivant illustre la réduction temporaire du tablespace à l’aide de `mysql.rds_execute_operation` :
Pour vérifier la taille actuelle du tablespace temporaire, exécutez l’une des requêtes suivantes :
```
SELECT FILE_SIZE FROM information_schema.innodb_sys_tablespaces WHERE name LIKE 'innodb_temporary';
+------------+
| FILE_SIZE |
+------------+
| 6723469312 | -- 6.3 GB
+------------+
```
Lorsque vous supprimez des tables temporaires, cela ne réduit pas l’utilisation du stockage dans le tablespace global. Pour réduire la taille du tablespace global, exécutez la commande `mysql.rds_execute_operation` pour réduire le tablespace temporaire.
```
CALL mysql.rds_execute_operation('innodb_truncate_temporary_tablespace_now');
Query OK, 2 rows affected (0.004 sec)
```
Après avoir exécuté la procédure, vérifiez que l’espace a été récupéré.
```
SELECT FILE_SIZE FROM information_schema.innodb_sys_tablespaces WHERE name LIKE 'innodb_temporary';
+-----------+
| FILE_SIZE |
+-----------+
| 12582912 | -- 12 MB
+-----------+
```
**Note**
L’opération de réduction peut prendre du temps, en fonction de la taille du tablespace temporaire et de la charge de travail actuelle.
**Important**
Le tablespace temporaire ne se réduit que lorsque toutes les tables temporaires qui ont contribué à sa taille ne sont plus utilisées. Nous vous recommandons d’exécuter cette procédure lorsqu’aucun tablespace temporaire n’est actif sur l’instance.
# Fuseau horaire local pour les instances de base de données MariaDB
Par défaut, le fuseau horaire d'une instance de base de données MariaDB est le fuseau UTC (temps universel). Vous pouvez à la place définir le fuseau horaire de votre instance de base de données sur le fuseau horaire local de votre application.
Pour définir le fuseau horaire local d'une instance de base de données, définissez le paramètre `time_zone` du groupe de paramètres de votre instance de base de données avec l'une des valeurs prises en charge et répertoriées plus bas dans cette section. Lorsque vous définissez le paramètre `time_zone` d'un groupe de paramètres, toutes les instances de base de données et tous les réplicas en lecture qui ont recours à ce groupe de paramètres sont modifiés de façon à utiliser le nouveau fuseau horaire local. Pour plus d'informations sur la définition des paramètres d'un groupe de paramètres, consultez [Groupes de paramètres pour Amazon RDS](USER_WorkingWithParamGroups.md).
Une fois que vous avez défini le fuseau horaire local, toutes les nouvelles connexions à la base de données reflètent la modification. Si des connexions à votre base de données sont ouvertes lorsque vous modifiez le fuseau horaire local, la mise à jour du fuseau horaire local n'apparaît pas tant que vous n'avez pas fermé la connexion et n'en avez pas ouvert une nouvelle.
Vous pouvez définir un fuseau horaire local différent pour une instance de base de données et un ou plusieurs de ses réplicas en lecture. Pour ce faire, utilisez un autre groupe de paramètres pour l’instance de base de données et les réplicas, et définissez le paramètre `time_zone` de chaque groupe de paramètres avec un autre fuseau horaire local.
Si la réplication s'effectue entre les Régions AWS, l'instance de base de données source et le réplica en lecture utilisent des groupes de paramètres différents (les groupes de paramètres sont propres à chaque Région AWS). Pour que chaque instance utilise le même fuseau horaire local, vous devez définir le paramètre `time_zone` dans les groupes de paramètres de l’instance et du réplica en lecture.
Lorsque vous restaurez une instance de base de données à partir d'un instantané de base de données, le fuseau horaire local a la valeur UTC. Vous pouvez mettre à jour le fuseau horaire sur votre fuseau horaire local une fois la restauration terminée. Si vous restaurez une instance de base de données à un instant dans le passé, le fuseau horaire local de l’instance de base de données restaurée est le paramètre de fuseau horaire du groupe de paramètres de l’instance de base de données restaurée.
L'Internet Assigned Numbers Authority (IANA) publie de nouveaux fuseaux horaires sur [https://www.iana.org/time-zones](https://www.iana.org/time-zones) plusieurs fois par an. Chaque fois que RDS publie une nouvelle version de maintenance mineure de MariaDB, elle est livrée avec les dernières données de fuseau horaire au moment de la publication. Lorsque vous utilisez les dernières versions de RDS for MariaDB, vous disposez de données de fuseau horaire récentes provenant de RDS. Pour vous assurer que votre instance de base de données dispose de données de fuseau horaire récentes, nous vous recommandons de passer à une version supérieure du moteur de base de données. Vous pouvez également modifier manuellement les tables de fuseaux horaires dans les instances de base de données MariaDB. Pour ce faire, vous pouvez utiliser des commandes SQL ou exécuter l'[outil mysql\$1tzinfo\$1to\$1sql](https://mariadb.com/kb/en/mysql_tzinfo_to_sql/) dans un client SQL. Après la mise à jour manuelle des données de fuseau horaire, redémarrez votre instance de base de données pour que la modification prenne effet. RDS ne modifie ni ne réinitialise les données de fuseau horaire des instances de base de données en cours d'exécution. Les nouvelles données de fuseau horaire ne sont installées que lorsque vous effectuez une mise à niveau de la version du moteur de base de données.
Vous pouvez définir votre fuseau horaire local avec l’une des valeurs suivantes.
| disponibilité | Fuseau horaire |
| --- | --- |
| Afrique | Afrique/Le Caire, Afrique/Casablanca, Afrique/Harare, Afrique/Monrovia, Afrique/Nairobi, Afrique/Tripoli, Afrique/Windhoek |
| Amérique | Amérique/Araguaina, Amérique/Asuncion, Amérique/Bogota, Amérique/Buenos\$1Aires, Amérique/Caracas, Amérique/Chihuahua, Amérique/Cuiaba, Amérique/Denver, Amérique/Fortaleza, Amérique/Guatemala, Amérique/Halifax, Amérique/Manaus, Amérique/Matamoros, Amérique/Monterrey, Amérique/Montevideo, Amérique/Phoenix, Amérique/Santiago, Amérique/Tijuana |
| Asie | Asie/Amman, Asie/Achgabat, Asie/Bagdad, Asie/Bakou, Asie/Bangkok, Asie/Beyrouth, Asie/Calcutta, Asie/Damas, Asie/Dhaka, Asie/Irkoutsk, Asie/Jérusalem, Asie/Kaboul, Asie/Karachi, Asie/Katmandou, Asie/Krasnoïarsk, Asie/Magadan, Asie/Muscat, Asie/Novosibirsk, Asie/Riyad, Asie/Séoul, Asie/Shanghai, Asie/Singapour, Asie/Taipei, Asie/Téhéran, Asie/Tokyo, Asie/Oulan\$1Bator, Asie/Vladivostok, Asie/Iakoutsk, Asie/Yerevan |
| Atlantique | Atlantique/Açores |
| Australie | Australie/Adelaide, Australie/Brisbane, Australie/Darwin, Australie/Hobart, Australie/Perth, Australie/Sydney |
| Brésil | Brésil/DeNoronha, Brésil/Est |
| Canada | Canada/Terre-Neuve, Canada/Saskatchewan, Canada/Yukon |
| Europe | Europe/Amsterdam, Europe/Athènes, Europe/Dublin, Europe/Helsinki, Europe/Istanbul, Europe/Kaliningrad, Europe/Moscou, Europe/Paris, Europe/Prague, Europe/Sarajevo |
| Pacifique | Pacifique/Auckland, Pacifique/Fidji, Pacifique/Guam, Pacifique/Honolulu, Pacifique/Samoa |
| ETATS-UNIS | États-Unis/Alaska, États-Unis/Centre, États-Unis/Indiana Est, États-Unis/Est, États-Unis/Pacifique |
| UTC | UTC |
# Limites et problèmes connus pour RDS for MariaDB
Les éléments suivants sont des problèmes et limitations connus liés à l'utilisation de RDS for MariaDB.
**Note**
Cette liste n'est pas exhaustive.
**Topics**
+ [
## Limites de taille des fichiers MariaDB dans Amazon RDS
](#RDS_Limits.FileSize.MariaDB)
+ [
## Mot réservé InnoDB
](#MariaDB.Concepts.InnodbDatabaseName)
+ [
## Ports personnalisés
](#MariaDB.Concepts.CustomPorts)
+ [
## Performance Insights
](#MariaDB.Concepts.PerformanceInsights)
## Limites de taille des fichiers MariaDB dans Amazon RDS
Pour les instances de base de données MariaDB, la taille maximale d'une table est de 16 To lors de l'utilisation des espaces de table file-per-table InnoDB. Cette limite restreint également l'espace de table du système à une taille maximum de 16 To. Les espaces de table file-per-table InnoDB (avec des tables chacune dans leur propre espace de table) sont définis par défaut pour les instances de base de données MariaDB. Cette limite n'est pas liée à la limite de stockage maximale pour les instances de base de données MariaDB. Pour plus d'informations sur les limites de stockage, veuillez consulter [Stockage d'instance de base de données Amazon RDS](CHAP_Storage.md).
Selon votre application, l'utilisation des espaces de table file-per-table InnoDB présente des avantages et des inconvénients. Pour déterminer l'approche optimale pour votre application, veuillez consulter [File-Per-Table Tablespaces](https://dev.mysql.com/doc/refman/5.7/en/innodb-file-per-table-tablespaces.html) dans la documentation MySQL.
Il est déconseillé d'autoriser les tables à dépasser la taille maximale de fichier. En général, une meilleure pratique consiste à partitionner les données en tables plus petites, ce qui peut améliorer la performance et les temps de récupération.
Vous pouvez utiliser l'option de partitionnement pour diviser une grande table en tables plus petites. Le *partitionnement* répartit des portions de votre grande table en fichiers distincts en fonction des règles que vous spécifiez. Par exemple, si vous stockez des transactions par date, vous pouvez créer des règles de partitionnement qui répartissent des transactions plus anciennes en fichiers distincts en utilisant le partitionnement. Ensuite, vous pouvez archiver régulièrement les données de transaction historiques qui n'ont pas besoin d'être rapidement utilisables par votre application. Pour de plus amples informations, veuillez consulter [Partitionnement](https://dev.mysql.com/doc/refman/5.7/en/partitioning.html) dans la documentation MySQL.
**Pour déterminer la taille de tous les espaces de table InnoDB**
+ Utilisez la commande SQL suivante pour déterminer si certaines de vos tables sont trop volumineuses et peuvent faire l'objet d'un partitionnement.
**Note**
Pour MariaDB 10.6 et versions supérieures, cette requête renvoie également la taille de l'espace de table système InnoDB.
Pour les versions de MariaDB antérieures à 10.6, vous ne pouvez pas déterminer la taille de l'espace de table système InnoDB en interrogeant les tables système. Nous vous recommandons de procéder à une mise à niveau vers une version ultérieure.
```
1. SELECT SPACE,NAME,ROUND((ALLOCATED_SIZE/1024/1024/1024), 2)
2. as "Tablespace Size (GB)"
3. FROM information_schema.INNODB_SYS_TABLESPACES ORDER BY 3 DESC;
```
**Pour déterminer la taille des tables utilisateur non-InnoDB**
+ Utilisez la commande SQL suivante pour déterminer si certaines de vos tables utilisateur non-InnoDB sont trop volumineuses.
```
SELECT TABLE_SCHEMA, TABLE_NAME, round(((DATA_LENGTH + INDEX_LENGTH+DATA_FREE)
/ 1024 / 1024/ 1024), 2) As "Approximate size (GB)" FROM information_schema.TABLES
WHERE TABLE_SCHEMA NOT IN ('mysql', 'information_schema', 'performance_schema')
and ENGINE<>'InnoDB';
```
**Pour activer les espaces de table file-per-table InnoDB**
+ Définissez le paramètre `innodb_file_per_table` sur `1` dans le groupe de paramètres pour l'instance de base de données.
**Pour désactiver les espaces de table file-per-table InnoDB**
+ Définissez le paramètre `innodb_file_per_table` sur `0` dans le groupe de paramètres pour l'instance de base de données.
Pour plus d'informations sur la mise à jour d'un groupe de paramètres, consultez [Groupes de paramètres pour Amazon RDS](USER_WorkingWithParamGroups.md).
Après avoir activé ou désactivé les espaces de table file-per-table InnoDB, vous pouvez émettre une commande `ALTER TABLE`. Vous pouvez utiliser cette commande pour déplacer une table de l'espace de table global vers son propre espace de table. Vous pouvez également déplacer une table de son propre espace de table vers l'espace de table global. Voici un exemple.
```
1. ALTER TABLE table_name ENGINE=InnoDB, ALGORITHM=COPY;
```
## Mot réservé InnoDB
`InnoDB` est un mot réservé pour RDS for MariaDB. Vous ne pouvez pas utiliser ce nom pour une base de données MariaDB.
## Ports personnalisés
Amazon RDS bloque les connexions au port personnalisé 33060 pour le moteur MariaDB. Choisissez un port différent pour votre moteur MariaDB.
## Performance Insights
Les compteurs InnoDB ne sont pas visibles dans l'analyse des performances pour RDS for MariaDB version 10.11, car la communauté MariaDB ne les prend plus en charge.