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

  • MariaDB 10.5

  • MariaDB 10.4

  • MariaDB 10.3

  • MariaDB 10.2 (fin de vie prévue pour le 15 octobre 2022)

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 for MariaDB afin de développer des applications conformes à la loi HIPAA. Vous pouvez stocker les informations relatives à la santé, y compris les données de santé protégées (PHI, Protected Health Information), selon les termes d'un accord de partenariat (BAA, Business Associate Agreement) avec AWS. Pour plus d'informations, consultez Conformité à la loi HIPAA. AWS Les services concernés par le programme de conformité ont été intégralement évalués par un auditeur tiers et donnent lieu à une certification, une attestation de conformité ou une autorisation d'opérer (ATO, Authorization to operate). Pour 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.

Déploiements multi-AZ pour une haute disponibilité

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 des groupes de paramètres

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 dans la console Amazon RDS

Affichage d'évènements Amazon RDS

Fichiers journaux

Vous pouvez accéder aux fichiers journaux de votre instance de base de données MariaDB.

Surveillance des fichiers journaux 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.5 à la version 10.6. Un changement de version sera considéré comme mineur si seul le numéro de la version mineure change, par exemple, en passant de la version 10.6.5 à la version 10.6.7.

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

Version majeure Version mineure

MariaDB 10.6

  • 10.6.7

  • 10.6.5

MariaDB 10.5

  • 10.5.15

  • 10.5.13

  • 10.5.12

MariaDB 10.4

  • 10.4.24

  • 10.4.22

  • 10.4.21

MariaDB 10.3

  • 10.3.34

  • 10.3.32

  • 10.3.31

  • 10.3.28

MariaDB 10.2

  • 10.2.43

  • 10.2.41

  • 10.2.40

  • 10.2.39

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

Fin de vie MariaDB 10.2

Le 15 octobre 2022, Amazon RDS commencera le processus de fin de vie de MariaDB version 10.2 selon le calendrier suivant, qui comprend des recommandations de mise à niveau. Le processus de fin de vie met fin à la prise en charge standard de cette version. Nous vous recommandons de mettre à niveau toutes les instances de base de données MariaDB 10.2 vers MariaDB 10.3 ou une version plus récente dès que possible. Pour plus d'informations, consultez Mise à niveau du moteur de base de données MariaDB.

Action ou recommandation Dates

Nous vous recommandons de mettre à niveau manuellement les instances de base de données MariaB version 10.2 vers la version de votre choix. Vous pouvez passer directement à la version 10.3 ou 10.6 de MariaDB.

Maintenant – 15 octobre 2022

Nous vous recommandons de mettre à niveau manuellement les instantanés MariaB version 10.2 vers la version de votre choix.

Maintenant – 15 octobre 2022

Vous ne pouvez plus créer de nouvelles instances MariaDB version 10.2.

Vous pouvez toujours créer des réplicas en lecture d'instances de base de données MariaDB 10.2 existantes et les changer de déploiements mono-AZ à des déploiements Multi-AZ.

15 juillet 2022

Amazon RDS démarre les mises à niveau automatiques de vos instances de base de données MariaDB version 10.2 vers la version 10.3.

15 octobre 2022

Amazon RDS démarre les mises à niveau automatiques vers la version 10.3 de toutes les instances de base de données MariaDB version 10.2 restaurées à partir d'instantanés.

15 octobre 2022

Pour plus d'informations sur la fin de vie d'Amazon RDS for MariaDB 10.2, consultez Announcement: Amazon Relational Database Service (Amazon RDS) for MariaDB 10.2 End-of-Life date is October 15, 2022 (Annonce : la date de fin de vie d'Amazon Relational Database Service (Amazon RDS) for MariaDB 10.2 est le 15 octobre 2022).

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 d'Amazon RDS for 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.6 sur Amazon RDS

Amazon RDS prend en charge les nouvelles fonctions suivantes pour vos instances de base de données exécutant MariaDB version 10.6 ou versions ultérieures :

  • Moteur de stockage MyRocks : vous pouvez utiliser le moteur de stockage MyRocks avec RDS for MariaDB pour optimiser la consommation de stockage de vos applications Web hautes performances et exigeantes en écriture. Pour plus d'informations, veuillez consulter Moteurs de stockage pris en charge pour MariaDB sur Amazon RDS et MyRocks.

  • Authentification de base de données IAM : vous pouvez utiliser l'authentification DB IAM pour une meilleure sécurité et une gestion centralisée des connexions à vos instances de base de données MariaDB. Pour plus d'informations, consultez Authentification de base de données IAM pour MariaDB, MySQL et PostgreSQL.

  • Options de surclassement : vous pouvez désormais effectuer une mise à niveau vers RDS for MariaDB version 10.6 depuis n'importe quelle version majeure antérieure (10.2, 10.3, 10.4, 10.5). Vous pouvez également restaurer un instantané d'une instance de base de données MySQL 5.6 ou 5.7 existante sur une instance MariaDB 10.6. Pour plus d'informations, consultez Mise à niveau du moteur de base de données MariaDB.

  • Réplication retardée: vous pouvez désormais définir une période configurable pour laquelle un réplica en lecture est en retard par rapport à la base de données source. Dans une configuration de réplication MariaDB standard, le délai de réplication entre la source et le réplica est minime. Avec la réplication différée, vous pouvez définir un délai intentionnel comme stratégie de reprise après sinistre. Pour plus d'informations, consultez Configuration de la réplication différée avec MariaDB.

  • Compatibilité Oracle PL/SQL : en utilisant RDS for MariaDB version 10.6, vous pouvez migrer plus facilement vos applications Oracle héritées vers Amazon RDS. Pour de plus amples informations, veuillez consulter SQL_MODE=ORACLE.

  • DDL atomique : vos instructions DDL (Dynamic Data Language) peuvent être relativement sécurisées avec RDS for MariaDB version 10.6. CREATE TABLE, ALTER TABLE, RENAME TABLE, DROP TABLE, DROP DATABASE et les instructions DDL associées sont désormais atomiques. Soit l'instruction réussit, soit elle est complètement inversée. Pour de plus amples informations, veuillez consulter DDL atomique.

  • Autres améliorations : ces améliorations incluent une fonction JSON_TABLE pour transformer les données JSON au format relationnel dans SQL, et une charge plus rapide des données de table vides avec Innodb. Ils incluent également de nouveaux sys_schema à des fins d'analyse et de dépannage, d'amélioration de l'optimiseur pour ignorer les index inutilisés et d'amélioration des performances. Pour en savoir plus, veuillez consulter JSON_TABLE.

  • Nouvelles valeurs par défaut pour les paramètres : les paramètres suivants disposent de nouvelles valeurs par défaut pour les instances de base de données MariaDB version 10.6 :

Pour accéder à la liste complète des fonctions MariaDB 10.6 ainsi qu'à la documentation associée, veuillez consulter Modifications et améliorations apportées à MariaDB 10.6 et Notes de mise à jour – Série MariaDB 10.6 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.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 S3

  • Plug-in d'authentification – GSSAPI

  • Plug-in d'authentification – Socket Unix

  • AWSPlugin de chiffrement Key Management

  • Réplication différée pour les versions MariaDB inférieures à 10.6

  • Chiffrement au repos MariaDB natif pour InnoDB et Aria.

    Vous pouvez activer le chiffrement au repos pour une instance de base de données MariaDB en suivant les instructions de Chiffrement des ressources Amazon RDS.

  • HandlerSocket

  • Type de table JSON pour les versions MariaDB inférieures à 10.6

  • MariaDB ColumnStore

  • MariaDB Galera Cluster

  • Réplication multi-source

  • Moteur de stockage MyRocks pour les versions MariaDB inférieures à 10.6

  • 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

RDS for MariaDB prend en charge les moteurs de stockage suivants.

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

Le moteur de stockage InnoDB

Bien que MariaDB prenne en charge plusieurs moteurs de stockage avec diverses capacités, toutes ne sont pas optimisées pour la récupération sur incident et la durabilité des données. InnoDB est le moteur de stockage recommandé et pris en charge pour les instances de base de données MariaDB sur Amazon RDS. Les fonctions Amazon RDS telles que la restauration ponctuelle et la restauration instantanée 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.

Pour plus d'informations, veuillez consulter InnoDB.

Moteur de stockage MyRocks

Le moteur de stockage MyRocks est disponible dans RDS for MariaDB 10.6 et versions ultérieures. Avant d'utiliser le moteur de stockage MyRocks dans une base de données de production, nous vous recommandons d'effectuer des tests et des tests approfondis afin de vérifier tous les avantages potentiels par rapport à InnoDB pour votre cas d'utilisation.

Le groupe de paramètres par défaut de MariaDB version 10.6 inclut les paramètres MyRocks. Pour plus d'informations, consultez Paramètres pour MariaDB et Utilisation des groupes de paramètres.

Pour créer une table qui utilise le moteur de stockage MyRocks, spécifiez ENGINE=RocksDB dans l'instruction CREATE TABLE. L'exemple suivant crée une table qui utilise le moteur de stockage MyRocks.

CREATE TABLE test (a INT NOT NULL, b CHAR(10)) ENGINE=RocksDB;

Il est déconseillé d'exécuter des transactions couvrant les tables InnoDB et MyRocks. MariaDB ne garantit pas ACID (atomicité, cohérence, isolement, durabilité) pour les transactions entre moteurs de stockage. Bien qu'il soit possible d'avoir des tables InnoDB et MyRocks dans une instance de base de données, nous ne recommandons pas cette approche, sauf lors d'une migration d'un moteur de stockage à l'autre. Lorsque les tables InnoDB et MyRocks existent dans une instance de base de données, chaque moteur de stockage possède son propre groupe de tampons, ce qui peut entraîner une dégradation des performances.

MyRocks ne supporte pas l'isolation SERIALIZABLE ou les verrous d'espace. Par conséquent, vous ne pouvez généralement pas utiliser MyRocks avec une réplication basée sur des instructions. Pour de plus amples informations, veuillez consulter MyRocks et la réplication.

Actuellement, vous ne pouvez modifier que les paramètres MyRocks suivants :

Le moteur de stockage MyRocks et le moteur de stockage InnoDB peuvent rivaliser pour obtenir de la mémoire en fonction des paramètres rocksdb_block_cache_size et innodb_buffer_pool_size. Dans certains cas, il se peut que vous ayez l'intention d'utiliser le moteur de stockage MyRocks uniquement sur une instance de base de données particulière. Dans l'affirmative, nous vous recommandons de définir le paramètre innodb_buffer_pool_size minimal à une valeur minimale et de définir le paramètre rocksdb_block_cache_size à une valeur aussi haute que possible.

Vous pouvez accéder aux fichiers journaux MyRocks en utilisant les opérations DescribeDBLogFiles et DownloadDBLogFilePortion.

Pour de plus amples informations sur MyRocks, veuillez consulter MyRocks sur le site Web MariaDB.

Limites de taille des fichiers MariaDB dans Amazon RDS

Pour les instances de base de données MariaDB, la taille maximale d'une table est de 16 To lors de l'utilisation des espaces de table file-per-table InnoDB. Cette limite restreint également l'espace de table du système à une taille maximum de 16 To. Les espaces de table file-per-table InnoDB (avec des tables chacune dans leur propre espace de table) sont définis par défaut pour les instances de base de données MariaDB. Cette limite n'est pas liée à la limite de stockage maximale pour les instances de base de données MariaDB. Pour plus d'informations sur les limites de stockage, veuillez consulter Stockage d'instance de base de données Amazon RDS.

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 des groupes de paramètres.

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

Pris en charge

Pris en charge

Pris en charge

Pris en charge

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.15-MariaDB, for osx10.15 (x86_64) using readline 5.1

La plupart des distributions Linux, telles qu'Amazon Linux, CentOS, SUSE et Debian, ont remplacé MySQL par MariaDB, et la version de mysql qu'elles contiennent provient de MariaDB.

Pour 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 des groupes de paramètres.

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 également à une instance de base de données MariaDB exécutant InnoDB.

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 des groupes de paramètres.

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

Mot réservé InnoDB

InnoDB est un mot réservé pour RDS for MariaDB. Vous ne pouvez pas utiliser ce nom pour une base de données MariaDB.

Versions rendues obsolètes pour Amazon RDS for MariaDB

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

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