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.4
-
MariaDB 10.3
-
MariaDB 10.2
-
MariaDB 10.1
-
MariaDB 10.0
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
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. |
|
|
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. |
|
|
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 |
|
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 |
|
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. |
|
|
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. |
|
|
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). |
|
|
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. |
|
|
Fichiers journaux Vous pouvez accéder aux fichiers journaux de votre instance 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é majeur si le numéro de version majeure change. Par exemple, en allant de la version 10.0 à 10.1. Un changement de version sera considéré mineur seulement si le numéro de version mineure change. Par exemple, en allant de la version 10.0.17 à 10.0.24.
Amazon RDS prend actuellement en charge les versions de MariaDB suivantes :
| Version majeure | Version mineure |
|---|---|
|
MariaDB 10.4 |
|
|
MariaDB 10.3 |
|
|
MariaDB 10.2 |
|
|
MariaDB 10.1 |
|
|
MariaDB 10.0 |
|
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.2), puis 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-versionmajor-engine-version--regionregion--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 :
Rubriques
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.4 sur Amazon RDS
Amazon RDS prend en charge les nouvelles fonctions suivantes pour vos instances de base de données exécutant MariaDB version 10.4 ou versions ultérieures :
-
Améliorations de la sécurité des comptes utilisateur – Améliorations de l'expiration des mots de passe
et du verrouillage des comptes -
Améliorations de l'optimiseur – Fonction Optimizer Trace
-
Améliorations InnoDB – Prise en charge de l'opération DROP COLUMN instantanée
et extension VARCHARinstantanée pourROW_FORMAT=DYNAMICetROW_FORMAT=COMPACT -
Nouveaux paramètres – Notamment : tcp_nodedelay
, tls_version et gtid_cleanup_batch_size
Pour obtenir la liste de toutes les fonctions MariaDB 10.4 et leur documentation,
veuillez consulter Changes and Improvements in MariaDB 10.4 (Modifications et améliorations dans MariaDB 10.4)
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)
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)
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)
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)
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 :
-
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_checketcracklib_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
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
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
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_tablela valeur1dans 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_tablela valeur0dans 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,REVOKEetSET PASSWORDfonctionnent 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 -
reloadCe 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
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.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.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
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
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.
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
Vidage et chargement du pool de tampons à la demande
Vous pouvez enregistrer et charger le cache à la demande à l'aide des procédures stockées suivantes :
-
Pour vider l'état actuel du pool de mémoires tampons sur le disque, appelez la procédure stockée mysql.rds_innodb_buffer_pool_dump_now.
-
Pour charger l'état enregistré du pool de mémoires tampons à partir du disque, appelez la procédure stockée mysql.rds_innodb_buffer_pool_load_now.
-
Pour annuler une opération de chargement en cours, appelez la procédure stockée mysql.rds_innodb_buffer_pool_load_abort.
Paramètres de base de données pour MariaDB
Par défaut, une instance de base de données MariaDB utilise un groupe de paramètres DB qui est spécifique à une base de données MariaDB. Ce groupe de paramètres contient certains, mais pas la totalité, des paramètres du groupe de paramètres de base de données Amazon RDS du moteur de base de données MySQL. Il contient également un certain nombre de nouveaux paramètres propres à MariaDB. Pour plus d'informations sur les paramètres disponibles pour le moteur de base de données 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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
