Prise en charge des fonctions MariaDB sur Amazon RDS - Amazon Relational Database Service

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.

Prise en charge des fonctions MariaDB sur Amazon RDS

RDS for MariaDB prend en charge la plupart des fonctionnalités et des capacités de MariaDB. Certaines fonctions peuvent avoir une prise en charge limitée ou des privilèges restreints.

Vous pouvez filtrer les nouvelles fonctions de Amazon RDS sur la page Nouveautés en matière de base de données. Pour Produits, choisissez Amazon RDS. Ensuite, effectuez une recherche à l'aide de mots clés tels que MariaDB 2023.

Note

Les listes suivantes ne sont pas exhaustives.

Prise en charge des fonctionnalités d’Amazon RDS for MariaDB pour les versions majeures de MariaDB

Dans les sections suivantes, vous trouverez des informations sur les fonctions MariaDB prises en charge sur les versions majeures d'Amazon RDS for MariaDB :

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.11 sur Amazon RDS

Amazon RDS prend en charge les nouvelles fonctionnnalités suivantes pour vos instances de base de données exécutant MariaDB version 10.11 ou versions ultérieures.

  • Plug-in Password Reuse Check : vous pouvez utiliser le plug-in MariaDB Password Reuse Check pour empêcher les utilisateurs de réutiliser les mots de passe et pour définir la période de conservation des mots de passe. Pour plus d'informations, consultez Plug-in Password Reuse Check (langue française non garantie).

  • Autorisation GRANT TO PUBLIC : vous pouvez accorder des privilèges à tous les utilisateurs qui disposent d'un accès à votre serveur. Pour plus d'informations, consultez GRANT TO PUBLIC (langue française non garantie).

  • Séparation des privilèges SUPER et READ ONLY ADMIN : vous pouvez supprimer les privilèges READ ONLY ADMIN de tous les utilisateurs, même des utilisateurs qui bénéficiaient auparavant de privilèges SUPER.

  • Sécurité : vous pouvez maintenant définir l'option --ssl par défaut pour votre client MariaDB. MariaDB ne désactive plus silencieusement SSL si la configuration est incorrecte.

  • Commandes et fonctions SQL : vous pouvez désormais utiliser la commande SHOW ANALYZE FORMAT=JSON et les fonctions ROW_NUMBER, SFORMAT et RANDOM_BYTES. SFORMAT autorise le formatage de chaîne et est activé par défaut. Vous pouvez convertir une partition en table et une table en partition en une seule commande. Il existe également plusieurs améliorations concernant les fonctions JSON_*(). Les fonctions DES_ENCRYPT et DES_DECRYPT ont été déconseillées pour les versions 10.10 et supérieures. Pour plus d'informations, consultez SFORMAT.

  • Améliorations InnoDB : ces améliorations incluent les éléments suivants :

    • Améliorations des performances dans le journal redo afin de réduire l'amplification d'écriture et améliorer la simultanéité.

    • Possibilité de modifier l'espace de table d'annulation sans réinitialiser le répertoire de données. Cette amélioration réduit le surcoût du plan de contrôle. Elle requiert un redémarrage, mais pas la réinitialisation après la modification de l'espace de table d'annulation.

    • Prise en charge de CHECK TABLE … EXTENDED et des index décroissants en interne.

    • Améliorations apportées à l'insertion en vrac.

  • Modifications du journal binaire : ces modifications incluent les éléments suivants :

    • Journalisation ALTER en deux phases pour réduire la latence de réplication. Le paramètre binlog_alter_two_phase est désactivé par défaut, mais peut être activé par le biais de groupes de paramètres.

    • Journalisation explicit_defaults_for_timestamp.

    • Plus de journalisation INCIDENT_EVENT si la transaction peut être annulée en toute sécurité.

  • Améliorations de la réplication : les instances de base de données MariaDB version 10.11 utilisent la réplication GTID par défaut si le maître la prend en charge. De plus, Seconds_Behind_Master est plus précis.

  • Clients : vous pouvez utiliser de nouvelles options de ligne de commande pour mysqlbinglog et mariadb-dump. Vous pouvez utiliser mariadb-dump pour vider et restaurer les données d'historique.

  • Gestion des versions du système : vous pouvez modifier l'historique. MariaDB crée automatiquement de nouvelles partitions.

  • DDL atomique : CREATE OR REPLACE est désormais atomique. Soit l'instruction réussit, soit elle est complètement inversée.

  • Écriture du journal redo : le journal redo écrit de manière asynchrone.

  • Fonctions stockées : les fonctions stockées prennent désormais en charge les mêmes paramètres IN, OUT et INOUT que dans les procédures stockées.

  • Paramètres déconseillés ou supprimés : les paramètres suivants sont devenus obsolètes ou ont été supprimés pour les instances de base de données MariaDB version 10.11 :

  • Paramètres dynamiques : les paramètres suivants sont désormais dynamiques pour les instances de base de données MariaDB version 10.11 :

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

  • Nouvelles valeurs valides pour les paramètres : les paramètres suivants ont de nouvelles valeurs valides pour les instances de base de données MariaDB version 10.11 :

    • Les valeurs valides pour le paramètre old ont été fusionnées à celles du paramètre old_mode.

    • Les valeurs valides pour le paramètre histogram_type incluent désormais JSON_HB.

    • La plage des valeurs valides pour le paramètre innodb_log_buffer_size est maintenant de 262144 à 4294967295 (de 256 Ko à 4 096 Mo).

    • La plage des valeurs valides pour le paramètre innodb_log_file_size est maintenant de 4194304 à 512GB (de 4 Mo à 512 Go).

    • Les valeurs valides pour le paramètre optimizer_prune_level incluent désormais 2.

  • Nouveaux paramètres : les paramètres suivants sont nouveaux pour les instances de base de données MariaDB version 10.11 :

Pour obtenir la liste de toutes les fonctionnalités et de la documentation, consultez les informations suivantes sur le site web de MariaDB.

Pour obtenir la liste des fonctions non prises en charge, consultez Fonctions MariaDB non prises en charge par Amazon RDS.

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 AWS Identity and Access Management (IAM) : vous pouvez utiliser l'authentification de base de données IAM pour une meilleure sécurité et une gestion centralisée des connexions à vos instances de base de données MariaDB. Pour de plus amples informations, veuillez consulter Authentification de base de données 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.3, 10.4 et 10.5). Vous pouvez également restaurer un instantané d'une instance de base de données MySQL 5.6 ou 5.7 existante sur une instance MariaDB 10.6. Pour de plus amples informations, veuillez consulter 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 de plus amples informations, veuillez consulter 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 :

    • La valeur par défaut des paramètres suivants est passée de utf8 à utf8mb3 :

      Bien que les valeurs par défaut aient changé pour ces paramètres, il n'y a pas de changement fonctionnel. Pour plus d'informations, consultez Supported Character Sets and Collations (Jeux de caractères et classements pris en charge) dans la documentation MariaDB.

    • La valeur par défaut du paramètre collation_connection est passée de utf8_general_ci à utf8mb3_general_ci. Bien que les valeurs par défaut aient changé pour ces paramètres, il n'y a pas de changement fonctionnel.

    • La valeur par défaut du paramètre old_mode est passé de non défini à UTF8_IS_UTF8MB3. Bien que les valeurs par défaut aient changé pour ces paramètres, il n'y a pas de changement fonctionnel.

Pour accéder à la liste complète des 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 MariaDB non prises en charge par 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: Performance Improvements etc. (InnoDB : Améliorations liées aux performances, etc.) dans la documentation MariaDB.

  • Mises à jour du schéma de performances – MariaDB version 10.5 inclut les mises à jour du schéma de performances. Pour plus d'informations, consultez Performance Schema Updates to Match MySQL 5.7 Instrumentation and Tables (Mises à jour du schéma de performances pour assurer la mise en correspondance avec l'instrumentation et les tables de MySQL 5.7) dans la documentation MariaDB.

  • Un seul fichier dans le journal redo d'InnoDB – Dans les versions de MariaDB antérieures à la version 10.5, la valeur du paramètre innodb_log_files_in_group était définie sur 2. Dans MariaDB version 10.5, la valeur de ce paramètre est définie sur 1.

    Si vous procédez à une mise à niveau vers MariaDB version 10.5 et que vous ne modifiez pas les paramètres, la valeur du paramètre innodb_log_file_size reste inchangée. Mais elle s'applique à un seul fichier journal au lieu de deux. En conséquence, votre instance de base de données MariaDB version 10.5 mise à niveau utilise la moitié de la taille du journal redo qu'elle utilisait avant la mise à niveau. Ce changement peut avoir un impact notable sur les performances. Pour résoudre ce problème, vous pouvez doubler la valeur du paramètre innodb_log_file_size. Pour 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 MariaDB non prises en charge par Amazon RDS.

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 MariaDB non prises en charge par Amazon RDS.

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 MariaDB non prises en charge par Amazon RDS.

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.

Préparation du cache pour MariaDB sur Amazon RDS

La préparation du cache InnoDB peut fournir des gains de performances pour votre instance de base de données MariaDB en enregistrant l'état actuel du pool de mémoires tampons lorsque l'instance de base de données est arrêtée, puis en rechargeant le pool de mémoires tampons à partir des informations enregistrées au démarrage de l'instance de base de données. Cette approche contourne la nécessité de « préparer » le pool de tampons à partir d'une utilisation normale de la base de données et précharge à la place le pool de tampons avec les pages des requêtes courantes connues. Pour plus d'informations sur la préparation du cache, consultez Vidage et restauration du pool de tampons dans la documentation MariaDB.

La préparation du cache est activée par défaut sur les instances de base de données MariaDB versions 10.3 et ultérieures. Pour l'activer, définissez les paramètres innodb_buffer_pool_dump_at_shutdown et innodb_buffer_pool_load_at_startup avec la valeur 1 dans le groupe de paramètres de votre instance de base de données. La modification de ces valeurs dans un groupe de paramètres affecte toutes les instances de base de données MariaDB qui utilisent ce groupe de paramètres. Pour activer la préparation du cache pour des instances de base de données MariaDB spécifiques, vous aurez peut-être à créer un groupe de paramètres pour ces instances de base de données. Pour plus d'informations sur les groupes de paramètres, consultez 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 :

Fonctions MariaDB non prises en charge par Amazon RDS

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

  • Moteur de stockage S3

  • Plug-in d'authentification – GSSAPI

  • Plug-in d'authentification – Socket Unix

  • 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

  • Plug-in Hashicorp Key Management

  • Exécution de deux mises à niveau en parallèle

Pour offrir une expérience de service géré, Amazon RDS ne fournit pas l'accès shell aux instances de base de données et limite l'accès à certaines tables et procédures système qui requièrent des privilèges avancés. Amazon RDS prend en charge l'accès aux bases de données sur une instance de base de données en utilisant toute application cliente SQL standard. Amazon RDS ne permet pas d'accès d'hôte direct à une instance de base de données via Telnet, Secure Shell (SSH) ou une connexion Bureau à distance Windows.