MariaDB sur Amazon RDS - Amazon Relational Database Service
Tâches courantes de gestionVersions de MariaDBPrise en charge des fonctions MariaDBFonctions non prises en chargeMoteurs de stockage pris en chargeLimites de taille des fichiersSécurité MariaDBSSL SupportPréparation du cacheParamètres de la base de données.Tâches d'administrateur de base de données courantesFuseau horaire local

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.

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 Amazon RDS 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 de plus amples informations, veuillez consulter Conformité à la loi HIPAA. 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 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 RDS MariaDB à l'aide de métriques RDS Amazon CloudWatch, d'événements et de Surveillance améliorée. Afficher des fichiers journaux pour votre instance de base de données RDS 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.

Amazon RDS Fichiers journaux de base de données

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 plus d'informations, consultez la documentation suivante :

Versions de MariaDB sur Amazon RDS

Les numéros de versions de MariaDB sont organisés selon la version X.Y.Z. Dans la terminologie Amazon RDS, X.Y représente 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.4.8 à la version 10.4.13.

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

Version majeure Version mineure

MariaDB 10.5

  • 10.5.8 (prise en charge dans toutes les régions AWS)

MariaDB 10.4

  • 10.4.13 (prise en charge dans toutes les régions AWS)

  • 10.4.8 (prise en charge dans toutes les régions AWS)

MariaDB 10.3

  • 10.3.23 (prise en charge dans toutes les régions AWS)

  • 10.3.20 (prise en charge dans toutes les régions AWS)

  • 10.3.13 (prise en charge dans toutes les régions AWS)

  • 10.3.8 (prise en charge dans toutes les régions AWS)

MariaDB 10.2

  • 10.2.32 (prise en charge dans toutes les régions AWS)

  • 10.2.21 (prise en charge dans toutes les régions AWS)

  • 10.2.15 (prise en charge dans toutes les régions AWS)

  • 10.2.12 (prise en charge dans toutes les régions AWS)

  • 10.2.11 (prise en charge dans toutes les régions AWS)

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 AWS CLI suivante renvoie la version du moteur mineur MariaDB par défaut pour la version majeure 10.3 et la région AWS USA Ouest (Oregon) (us-west-2) : 

aws rds describe-db-engine-versions --default-only --engine mariadb --engine-version 10.3 --region us-west-2 --query '*[].{Engine:Engine,EngineVersion:EngineVersion}' --output text

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

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 bases 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, cette commande requiert le privilège REPLICATION SLAVE ADMIN. Ce nouveau privilège n'est pas accordé à l'utilisateur principal de RDS.

    Au lieu d'utiliser la commande SHOW SLAVE 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 SLAVE 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 bases 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.

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

  • Réplication parallèle dans l'ordre optimiste

  • Compression de page

  • Nettoyage des données XtraDB et défragmentation

Pour obtenir la liste de toutes les fonctionnalités de MariaDB 10.1 et leur documentation, consultez Changes & Improvements in MariaDB 10.1 (Modifications et améliorations dans MariaDB 10.1) 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.0 sur Amazon RDS

Pour obtenir la liste de toutes les fonctionnalités de MariaDB 10.0 et leur documentation, consultez Changes & Improvements in MariaDB 10.0 (Modifications et améliorations dans MariaDB 10.0) 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

  • Plug-in de chiffrement AWS 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

  • Filtres de réplication

  • 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

Afin de livrer une expérience de service géré, Amazon RDS ne fournit pas d'accès de coquille aux instances de base de données et il restreint l'accès à certaines procédures de systèmes et à des tableaux qui nécessitent 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 qui utilise toute application de client 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 Windows Remote Desktop Connection.

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 (pour les versions 10.2 et ultérieures) et XtraDB (pour les versions 10.0 et 10.1) sont les moteurs de stockage recommandés et pris en charge pour les instances de base de données MariaDB sur Amazon RDS. Les fonctions Amazon RDS comme la restauration à un instant dans le passé et l'instantané nécessitent un moteur de stockage récupérable et ne sont pris en charge que pour le moteur de stockage recommandé pour la version MariaDB. Amazon RDS prend également en charge Aria, même si l'usage de cette dernière peut avoir un impact négatif sur la récupération en cas d'échec d'instance. Cependant, si vous avez besoin d'utiliser des index spatiaux pour gérer les données géographiques sur MariaDB 10.1 ou 10.0, vous devez utiliser Aria, parce que les index spatiaux ne sont pas pris en charge par XtraDB. Sur MariaDB 10.2 et versions suivantes, le moteur de stockage InnoDB prend en charge les index spatiaux.

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 Amazon RDS MariaDB, la limite maximale de stockage alloué 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 Amazon RDS 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 Amazon RDS 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 les instances de base de données. Lorsque vous vous connectez à AWS à l'aide des 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 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 Amazon RDS 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 AWS modify-db-instance 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.

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.

MariaDB utilise yaSSL pour les connexions sécurisées dans les versions suivantes :

  • Version MariaDB 10.1.26 et versions 10.1 antérieures

  • Version MariaDB 10.0.32 et versions 10.0 antérieures

MariaDB utilise OpenSSL pour les connexions sécurisées dans les versions suivantes :

  • Versions MariaDB 10.5

  • Versions MariaDB 10.4

  • Versions MariaDB 10.3

  • Versions MariaDB 10.2

  • Version MariaDB 10.1.31 et versions 10.1 ultérieures

  • Version MariaDB 10.0.34 et versions 10.0 ultérieures

Amazon RDS pour MariaDB prend en charge les versions 1.0, 1.1 et 1.2 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

MariaDB 10.5

Pris en charge

Pris en charge

Pris en charge

MariaDB 10.4

Pris en charge

Pris en charge

Pris en charge

MariaDB 10.3

Pris en charge

Pris en charge

Pris en charge

MariaDB 10.2

Pris en charge

Pris en charge

Pris en charge

MariaDB 10.1

Pris en charge

Pris en charge pour la version 10.1.31 et les versions 10.1 ultérieures

Pris en charge pour la version 10.1.31 et les versions 10.1 ultérieures

MariaDB 10.0

Pris en charge

Pris en charge pour la version 10.0.34 et les versions 10.0 ultérieures

Pris en charge pour la version 10.0.34 et les versions 10.0 ultérieures

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 pour MariaDB 10.2 ou version ultérieure. 

mysql -h myinstance.c9akciq32.rds-us-east-1.amazonaws.com
--ssl-ca=[full path]rds-combined-ca-bundle.pem --ssl-mode=REQUIRED

L'exemple suivant montre comment lancer le client à l'aide du paramètre --ssl-ca pour MariaDB 10.1 ou version antérieure. 

mysql -h myinstance.c9akciq32.rds-us-east-1.amazonaws.com
--ssl-ca=[full path]rds-combined-ca-bundle.pem --ssl-verify-server-cert

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.

Pour MariaDB 10.2 et version ultérieure, utilisez la déclaration suivante.


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

Pour MariaDB 10.1 et version antérieure, utilisez la déclaration suivante.


GRANT USAGE ON *.* TO '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 (version 10.2 et suivante) et XtraDB (versions 10.0 et 10.1) 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 Amazon RDS MariaDB, consultez Paramètres pour MariaDB.

Tâches DBA courantes pour MariaDB

Supprimer des sessions ou des requêtes, ignorer des erreurs de réplication, utiliser les espaces de table InnoDB (version 10.2 et suivante) et XtraDB (versions 10.0 et 10.1) pour améliorer les temps de récupération sur incident et gérer l'historique global des statuts sont des tâches DBA courantes que vous pouvez exécuter dans une instance de base de données MariaDB. Vous pouvez gérer ces tâches tout comme dans une instance de base de données MySQL Amazon RDS, comme 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 RDS 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/Bangkok

Australia/Darwin

Africa/Casablanca

Asia/Beirut

Australia/Hobart

Africa/Harare

Asia/Calcutta

Australia/Perth

Africa/Monrovia

Asia/Damascus

Australia/Sydney

Africa/Nairobi

Asia/Dhaka

Brazil/East

Africa/Tripoli

Asia/Irkutsk

Canada/Newfoundland

Africa/Windhoek

Asia/Jerusalem

Canada/Saskatchewan

America/Araguaina

Asia/Kabul

Europe/Amsterdam

America/Asuncion

Asia/Karachi

Europe/Athens

America/Bogota

Asia/Kathmandu

Europe/Dublin

America/Caracas

Asia/Krasnoyarsk

Europe/Helsinki

America/Chihuahua

Asia/Magadan

Europe/Istanbul

America/Cuiaba

Asia/Muscat

Europe/Kaliningrad

America/Denver

Asia/Novosibirsk

Europe/Moscow

America/Fortaleza

Asia/Riyadh

Europe/Paris

America/Guatemala

Asia/Seoul

Europe/Prague

America/Halifax

Asia/Shanghai

Europe/Sarajevo

America/Manaus

Asia/Singapore

Pacific/Auckland

America/Matamoros

Asia/Taipei

Pacific/Fiji

America/Monterrey

Asia/Tehran

Pacific/Guam

America/Montevideo

Asia/Tokyo

Pacific/Honolulu

America/Phoenix

Asia/Ulaanbaatar

Pacific/Samoa

America/Santiago

Asia/Vladivostok

US/Alaska

America/Tijuana

Asia/Yakutsk

US/Central

Asia/Amman

Asia/Yerevan

US/Eastern

Asia/Ashgabat

Atlantic/Azores

US/East-Indiana

Asia/Baghdad

Australia/Adelaide

US/Pacific

Asia/Baku

Australia/Brisbane

UTC