MariaDB sur Amazon RDS

Amazon RDS prend en charge les instances de base de données qui exécutent plusieurs versions de MariaDB. Vous pouvez utiliser les versions majeures suivantes :

• MariaDB 10.5

• MariaDB 10.4

• MariaDB 10.3

• MariaDB 10.2

Pour plus d'informations sur la prise en charge des versions mineures, consultez Versions de MariaDB sur Amazon RDS.

Vous utilisez d'abord les interfaces ou les outils de gestion Amazon RDS pour créer une instance de base de données MariaDB. Vous pouvez ensuite utiliser les outils Amazon RDS pour effectuer des actions de gestion de l'instance de base de données, comme reconfigurer ou redimensionner l'instance de base de données, autoriser les connexions à l'instance de base de données, créer et restaurer à partir de sauvegardes ou d'instantanés, créer des secondaires multi-AZ, créer des réplicas en lecture et surveiller les performances de l'instance de base de données. Vous utilisez les applications et les utilitaires MariaDB pour stocker les données de l'instance de base de données et y accéder.

MariaDB est disponible dans toutes les régions AWS. Pour plus d'informations sur les régions AWS, consultez Régions, zones de disponibilité et zones locales .

Vous pouvez utiliser Amazon RDS pour les bases de données 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. AWS Les services AWS 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 de plus amples informations, veuillez consulter les services AWS concernés par le programme de conformité.

Avant de créer votre première instance de base de données, vous devez suivre la procédure décrite dans la section du présent guide relative à la configuration. Pour plus d'informations, consultez Configuration pour Amazon RDS.

Tâches courantes de gestion pour MariaDB sur Amazon RDS

Vous trouverez ci-dessous les tâches courantes de gestion que vous exécutez avec une instance de base de données Amazon RDS exécutant MariaDB, avec des liens vers la documentation appropriée relative à chaque tâche.

Type de tâche	Documentation
Classes d'instance, stockage et PIOPS Si vous créez une instance de base de données à des fins de production, vous devez comprendre comment les classes d'instance, les types de stockage et les IOPS provisionnées fonctionnent dans Amazon RDS.	Classes d'instances de base de données Types de stockage Amazon RDS
Déploiements multi-AZ Assurez un haut niveau de disponibilité grâce à une réplication de secours synchrone dans une autre zone de disponibilité, au basculement automatique, à la tolérance aux pannes pour les instances de base de données à l'aide de déploiements multi-AZ et aux réplicas en lecture.	Haute disponibilité (multi-AZ) pour Amazon RDS
Amazon Virtual Private Cloud (VPC) Si votre compte AWS possède un VPC par défaut, votre instance de base de données est automatiquement créée dans le VPC par défaut. Si votre compte n'a pas de VPC par défaut et que vous voulez que l'instance de base de données soit dans un VPC, vous devez créer le VPC et les groupes de sous-réseaux avant de créer l'instance de base de données.	Déterminer si vous utilisez une plateforme EC2-VPC ou EC2-Classic Utilisation d'une instance de base de données dans un VPC
Groupes de sécurité Par défaut, les instances de bases de données sont créées avec un pare-feu qui empêche d'y accéder. Vous devez donc créer un groupe de sécurité avec les adresses IP correctes et la configuration réseau permettant d'accéder à l'instance de base de données. Le groupe de sécurité que vous créez dépend de la plateforme Amazon EC2 sur laquelle se trouve votre instance de base de données et du fait que vous accédiez ou non à votre instance de base de données depuis une instance Amazon EC2. En général, si votre instance de base de données est sur la plateforme EC2-Classic, vous devez créer un groupe de sécurité de base de données ; si votre instance de base de données est sur la plateforme EC2-VPC, vous devez créer un groupe de sécurité VPC.	Déterminer si vous utilisez une plateforme EC2-VPC ou EC2-Classic Contrôle d'accès par groupe de sécurité
Groupes de paramètres Si votre instance de base de données doit nécessiter des paramètres de base de données spécifiques, vous devez créer un groupe de paramètres avant de créer l'instance de base de données.	Utilisation de groupes de paramètres de base de données
Importation et exportation de données Etablir les procédures d'importation ou d'exportation de données.	Importation de données dans une instance de base de données MariaDB
Réplication Vous pouvez décharger le trafic en lecture de votre instance de base de données MariaDB source en créant des réplicas en lecture.	Utilisation des réplicas en lecture
Connexion à votre instance de base de données Connectez-vous à votre instance de base de données à l'aide d'une application client SQL standard.	Connexion à une instance de base de données exécutant le moteur de base de données MariaDB
Sauvegarde et restauration Lorsque vous créez votre instance de base de données, vous pouvez la configurer pour effectuer des sauvegardes automatiques. Vous pouvez également sauvegarder et restaurer vos bases de données manuellement à l'aide des fichiers de sauvegarde complète (fichiers .bak).	Utilisation des sauvegardes
Surveillance Surveillez votre instance de base de données MariaDB en utilisant les métriques RDS Amazon CloudWatch, les événements et la supervision améliorée. Afficher des fichiers journaux pour votre instance de base de données MariaDB.	Affichage des métriques d'instances de base de données Affichage d'événements Amazon RDS
Fichiers journaux Vous pouvez accéder aux fichiers journaux de votre instance de base de données MariaDB.	Utilisation des fichiers journaux de base de données Amazon RDS Fichiers journaux de base de données MariaDB

Il existe également des tâches d'administration avancées permettant d'utiliser les instances de base de données exécutant MariaDB. Pour de plus amples informations, veuillez consulter la documentation suivante :

• Paramètres pour MariaDB

• Référence MariaDB sur SQL Amazon RDS

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.4 à la version 10.5. 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.3.20 à la version 10.3.23.

Amazon RDS prend actuellement en charge les versions de MariaDB suivantes :

Version majeure	Version mineure
MariaDB 10.5	10.5.9 10.5.8
MariaDB 10.4	10.4.18 10.4.13
MariaDB 10.3	10.3.28 10.3.23 10.3.20 10.3.13 10.3.8
MariaDB 10.2	10.2.37 10.2.32 10.2.21 10.2.15 10.2.12 10.2.11

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 afficher la liste des versions prises en charge, ainsi que celles par défaut pour des instances de base de données nouvellement créées, utilisez la commande describe-db-engine-versions de l’AWS CLI.

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 secondaire par défaut d'une région AWS à l'aide de la commande AWS CLI 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

Remplacez major-engine-version par la version majeure du moteur et region par la région AWS. Par exemple, la commande de l'AWS CLI suivante renvoie la version du moteur mineur MariaDB par défaut pour la version majeure 10.5 et la région AWS USA Ouest (Oregon) (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

Prise en charge des fonctions MariaDB sur Amazon RDS

Les sections suivantes décrivent les fonctions MariaDB prises en charge sur Amazon RDS pour les versions majeures de MariaDB :

Pour de plus amples informations sur les versions mineures de Amazon RDS for MariaDB prises en charge, veuillez consulter Versions de MariaDB sur Amazon RDS.

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 : Améliorations liées aux performances, etc.

• 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 Mises à jour du schéma de performances pour assurer la mise en correspondance avec l'instrumentation et les tables de MySQL 5.7.

• 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 de plus amples informations sur la modification des paramètres d'instance, veuillez consulter Modification de paramètres dans un groupe de paramètres de bases de données.

• 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_replica_status.

• 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_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.

  • La valeur par défaut du paramètre innodb_adaptive_hash_index a été remplacée par OFF (0).

  • La valeur par défaut du paramètre innodb_checksum_algorithm a été remplacée par full_crc32.

  • La valeur par défaut du paramètre innodb_log_file_size a été remplacée par 2 Go.

Pour accéder à la liste complète des fonctions MariaDB 10.5 ainsi qu'à la documentation associée, consultez Modifications et améliorations apportées à MariaDB 10.5 et Notes de mise à jour - Série MariaDB 10.5 sur le site Web de MariaDB.

Pour obtenir la liste des fonctions non prises en charge, consultez Fonctions non prises en charge.

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 et du verrouillage des comptes

• Améliorations de l'optimiseur – Fonction Optimizer Trace

• Améliorations InnoDB – Prise en charge de l'opération DROP COLUMN instantanée et extension VARCHAR instantanée pour ROW_FORMAT=DYNAMIC et ROW_FORMAT=COMPACT

• Nouveaux paramètres – Notamment : tcp_nodedelay, tls_version et gtid_cleanup_batch_size

Pour obtenir la liste de toutes les fonctions MariaDB 10.4 et leur documentation, veuillez consulter Changes and Improvements in MariaDB 10.4 (Modifications et améliorations dans MariaDB 10.4) et Release Notes - MariaDB 10.4 Series (Notes de mise à jour - MariaDB 10.4 Series) sur le site web de MariaDB.

Pour obtenir la liste des fonctions non prises en charge, consultez Fonctions non prises en charge.

Prise en charge de MariaDB 10.3 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.3 ou ultérieure :

• Compatibilité avec Oracle – analyseur de compatibilité PL/SQL, séquences, INTERSECT et EXCEPT pour compléter UNION, nouvelles déclarations TYPE OF et ROW TYPE OF et colonnes invisibles.

• Traitement de données temporelles – tables gérées par version du système, pour interroger les états passés et présents de la base de données.

• Flexibilité – regroupements définis par l'utilisateur, compression de colonnes indépendante du stockage, et prise en charge du protocole proxy pour relayer l'adresse IP du client au serveur.

• Facilité de gestion – opérations ADD COLUMN instantanées et opérations DDL (Data Definition Language) à échec rapide.

Pour obtenir la liste de toutes les fonctionnalités de MariaDB 10.3 et leur documentation, consultez Changes & Improvements in MariaDB 10.3 (Modifications et améliorations dans MariaDB 10.3) et Release Notes - MariaDB 10.0 Series (Notes de mise à jour - MariaDB 10.0 Series) sur le site web de MariaDB.

Pour obtenir la liste des fonctions non prises en charge, consultez Fonctions non prises en charge.

Prise en charge de MariaDB 10.2 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.2 ou ultérieure :

• ALTER USER

• Expressions de table communes

• Compression des événements pour réduire la taille du journal binaire

• CREATE USER — Nouvelles options pour limiter l'utilisation des ressources et TLS/SSL

• EXECUTE IMMEDIATE

• Flashback

• InnoDB — Nouveau moteur de stockage par défaut à la place de XtraDB

• InnoDB — Définissez dynamiquement la taille du pool de mémoires tampons

• Fonctions JSON

• Fonctions de fenêtrage

• WITH

Pour obtenir la liste de toutes les fonctionnalités de MariaDB 10.2 et leur documentation, consultez Changes & Improvements in MariaDB 10.2 (Modifications et améliorations dans MariaDB 10.2) et Release Notes - MariaDB 10.0 Series (Notes de mise à jour - MariaDB 10.0 Series) sur le site web de MariaDB.

Pour obtenir la liste des fonctions non prises en charge, consultez Fonctions non prises en charge.

Fonctions non prises en charge

Les fonctionnalités de MariaDB suivantes ne sont pas prises en charge sur Amazon RDS :

• Moteur de stockage ColumnStore

• Moteur de stockage S3

• Plug-in d'authentification – GSSAPI

• Plug-in d'authentification – Socket Unix

• AWSPlugin de chiffrement Key Management

• Réplication retardée

• Chiffrement au repos MariaDB natif pour XtraDB, 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.

• HandlerSocket

• Type de table JSON

• MariaDB ColumnStore

• MariaDB Galera Cluster

• Réplication multi-source

• Moteur de stockage MyRocks

• Plug-in de validation de mot de passe, simple_password_check et cracklib_password_check

• Moteur de stockage Spider

• Moteur de stockage Sphinx

• Moteur de stockage TokuDB

• Attributs d'objets spécifiques au moteur de stockage, comme décrit dans Engine-defined New Table/Field/Index Attributes dans la documentation MariaDB.

• Chiffrement de table et d'espace de tables

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.

Moteurs de stockage pris en charge pour MariaDB sur Amazon RDS

Même si MariaDB prend en charge plusieurs moteurs de stockage aux capacités diverses, ils ne sont pas tous optimisés pour la récupération 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 fonctions de restauration à un instant dans le passé et de restauration d'instantané d'Amazon RDS nécessitent un moteur de stockage tolérant aux incidents, et ne sont prises en charge que pour le moteur de stockage recommandé pour la version MariaDB. Amazon RDS prend également en charge Aria, bien que l'utilisation d'Aria puisse avoir un impact négatif sur la récupération en cas d'échec d'une instance.

Les autres moteurs de stockage ne sont pas pris en charge actuellement par Amazon RDS pour MariaDB.

Limites de taille des fichiers MariaDB dans Amazon RDS

Pour les instances de base de données MariaDB, la limite maximale de stockage provisionné restreint la taille d'une table à un maximum 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. Pour plus d'informations, consultez Stockage d'instance de base de données Amazon RDS.

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 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.

Une option que vous pouvez utiliser pour diviser une grande table en plus petites consiste à partitionner. 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 dans la documentation MySQL.

Pour déterminer la taille de fichier d'une table

Utilisez la commande SQL suivante pour déterminer si certaines de vos tables sont trop volumineuses et peuvent faire l'objet d'un partitionnement. Pour mettre à jour les statistiques de table, exécutez une commande ANALYZE TABLE sur chaque table. Pour de plus amples informations, veuillez consulter Instruction ANALYZE TABLE dans la documentation MySQL.

SELECT TABLE_SCHEMA, TABLE_NAME, 
    round(((DATA_LENGTH + INDEX_LENGTH) / 1024 / 1024), 2) As "Approximate size (MB)", DATA_FREE 
    FROM information_schema.TABLES
    WHERE TABLE_SCHEMA NOT IN ('mysql', 'information_schema', 'performance_schema'); 

Pour activer les espaces de table file-per-table InnoDB

• Pour activer les espaces de table file-per-table d'InnoDB, affectez au paramètre innodb_file_per_table la valeur 1 dans le groupe de paramètres relatif à l'instance de base de données.

Pour désactiver les espaces de table file-per-table InnoDB

• Pour désactiver les espaces de table file-per-table d'InnoDB, affectez au paramètre innodb_file_per_table la valeur 0 dans le groupe de paramètres relatif à l'instance de base de données.

Pour plus d'informations sur la mise à jour d'un groupe de paramètres, consultez Utilisation de groupes de paramètres de base de données.

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.

ALTER TABLE table_name ENGINE=InnoDB, ALGORITHM=COPY; 

Sécurité MariaDB sur Amazon RDS

La sécurité des instances de base de données MariaDB est gérée à trois niveaux :

• AWS Identity and Access Management 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 dans Amazon RDS.

• Lorsque vous créez une instance de base de données, vous utilisez un groupe de sécurité VPC ou un groupe de sécurité DB 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 effectuées à l'aide du protocole SSL (Secure Socket Layer). 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'accorde pas l'accès aux opérations FLUSH LOGS ou FLUSH TABLES WITH READ LOCK.

• replication client

• replication slave

• select

• show databases

• show view

• trigger

• update

Pour plus d'informations sur ces privilèges, consultez Gestion des comptes d'utilisateur 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 de SSL avec une instance de base de données MariaDB

Amazon RDS prend en charge les connexions SSL avec les instances de base de données exécutant le moteur de base de données MariaDB. MariaDB utilise OpenSSL pour des connexions sécurisées.

Amazon RDS crée un certificat SSL et l'installe sur l'instance de base de données quand Amazon RDS alloue l'instance. Ces certificats sont signés par une autorité de certification. Le certificat SSL inclut le point de terminaison de l'instance de base de données en tant que nom commun du certificat SSL pour assurer une protection contre les attaques par usurpation.

Pour de plus amples informations sur le téléchargement de certificats, veuillez consulter Utilisation de SSL/TLS pour chiffrer une connexion à une instance de base de données .

Amazon RDS for MariaDB prend en charge les versions 1.0, 1.1, 1.2 et 1.3 du protocole TLS (Transport Layer Security). Le tableau suivant affiche la prise en charge du protocole TLS pour les versions MySQL.

Version MariaDB	TLS 1.0	TLS 1.1	TLS 1.2	TLS 1.3
MariaDB 10.5	Pris en charge	Pris en charge	Pris en charge	Pris en charge
MariaDB 10.4	Pris en charge	Pris en charge	Pris en charge	Pris en charge
MariaDB 10.3	Pris en charge	Pris en charge	Pris en charge	Pris en charge
MariaDB 10.2	Pris en charge	Pris en charge	Pris en charge	Pris en charge

Important

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.9-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 chiffrer les connexions à l'aide du client mysql par défaut, lancez le client mysql à l'aide du paramètre --ssl-ca pour référencer la clé publique, comme illustré dans l'exemple suivant.

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 myinstance.123456789012.rds-us-east-1.amazonaws.com
--ssl-ca=[full path]global-bundle.pem --ssl-mode=REQUIRED

L'exemple suivant montre comment lancer le client à l'aide du paramètre --ssl-ca en utilisant le client MariaDB.

mysql -h myinstance.123456789012.rds-us-east-1.amazonaws.com
--ssl-ca=[full path]global-bundle.pem --ssl

Pour plus d'informations sur le téléchargement de solutions groupées de certificat, consultez Utilisation de SSL/TLS pour chiffrer une connexion à une instance de base de données .

Vous pouvez exiger des connexions SSL pour des comptes d'utilisateur spécifiques. Par exemple, vous pouvez utiliser l'une des instructions suivantes, selon votre version MariaDB, pour exiger des connexions SSL sur le compte utilisateur encrypted_user.

Utilisez l'instruction suivante.

ALTER USER 'encrypted_user'@'%' REQUIRE SSL;            
        

Pour plus d'informations sur les connexions SSL avec MariaDB, consultez la page SSL Overview dans la documentation MariaDB.

Préparation du cache

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 dans la documentation MariaDB.

La préparation du cache est activée par défaut sur les instances de base de données MariaDB 10.2 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 Utilisation de groupes de paramètres de base de données.

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.

CREATE EVENT periodic_buffer_pool_dump 
   ON SCHEDULE EVERY 1 HOUR 
   DO CALL mysql.rds_innodb_buffer_pool_dump_now(); 

Pour plus d'informations, consultez Événements 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_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_innodb_buffer_pool_load_now.

• Pour annuler une opération de chargement en cours, appelez la procédure stockée mysql.rds_innodb_buffer_pool_load_abort.

Paramètres de base de données 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 plus d'informations sur les paramètres disponibles pour le moteur de base de données RDS for MariaDB, consultez Paramètres pour MariaDB.

Tâches DBA courantes pour MariaDB

La suppression des sessions ou des requêtes, le fait d'ignorer des erreurs de réplication, l'utilisation des espaces de table InnoDB pour améliorer les temps de récupération sur incident et la gestion de l'historique global des statuts sont des tâches d'administrateur de base de données courantes que vous pouvez exécuter dans une instance de base de données MariaDB. Vous pouvez gérer ces tâches de la même façon que dans une instance de base de données MySQL, comme cela est décrit dans Tâches DBA courantes pour les instances de base de données MySQL. Les instructions de récupération sur incident se rapportent ici au moteur InnoDB MySQL, mais s'appliquent aussi bien à une instance MariaDB exécutant InnoDB ou XtraDB.

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 Utilisation de groupes de paramètres de base de données.

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.

Vous pouvez définir votre fuseau horaire local avec l'une des valeurs suivantes.

Africa/Cairo	Asia/Riyadh
Africa/Casablanca	Asia/Seoul
Africa/Harare	Asia/Shanghai
Africa/Monrovia	Asia/Singapore
Africa/Nairobi	Asia/Taipei
Africa/Tripoli	Asia/Tehran
Africa/Windhoek	Asia/Tokyo
America/Araguaina	Asia/Ulaanbaatar
America/Asuncion	Asia/Vladivostok
America/Bogota	Asia/Yakutsk
America/Buenos_Aires	Asia/Yerevan
America/Caracas	Atlantic/Azores
America/Chihuahua	Australia/Adelaide
America/Cuiaba	Australia/Brisbane
America/Denver	Australia/Darwin
America/Fortaleza	Australia/Hobart
America/Guatemala	Australia/Perth
America/Halifax	Australia/Sydney
America/Manaus	Brazil/East
America/Matamoros	Canada/Newfoundland
America/Monterrey	Canada/Saskatchewan
America/Montevideo	Canada/Yukon
America/Phoenix	Europe/Amsterdam
America/Santiago	Europe/Athens
America/Tijuana	Europe/Dublin
Asia/Amman	Europe/Helsinki
Asia/Ashgabat	Europe/Istanbul
Asia/Baghdad	Europe/Kaliningrad
Asia/Baku	Europe/Moscow
Asia/Bangkok	Europe/Paris
Asia/Beirut	Europe/Prague
Asia/Calcutta	Europe/Sarajevo
Asia/Damascus	Pacific/Auckland
Asia/Dhaka	Pacific/Fiji
Asia/Irkutsk	Pacific/Guam
Asia/Jerusalem	Pacific/Honolulu
Asia/Kabul	Pacific/Samoa
Asia/Karachi	US/Alaska
Asia/Kathmandu	US/Central
Asia/Krasnoyarsk	US/Eastern
Asia/Magadan	US/East-Indiana
Asia/Muscat	US/Pacific
Asia/Novosibirsk	UTC

Versions rendues obsolètes pour Amazon RDS for MariaDB

Amazon RDS for MariaDB versions 10.0 et 10.1 sont rendues obsolètes.

Pour plus d'informations, consultez Annonce : Extension du processus de fin de vie pour Amazon RDS for MariaDB 10.0 et 10.1.

Pour de plus amples informations sur la stratégie d'obsolescence Amazon RDS pour MariaDB, veuillez consulter FAQ Amazon RDS.