MariaDB sur Amazon RDS - Amazon Relational Database Service

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 :

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 :

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 :

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 :

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.