MariaDB 10.5 a été publiée en tant que GA en juin 2020. Dans la version, la prise en charge d'Amazon S3 ou de tout cloud public ou privé tiers prenant en charge l'API S3 a été ajoutée. Il propose également une gestion sophistiquée des privilèges étendant sa granularité, ce qui permet à un DBA, par exemple, de fournir des privilèges limités à un utilisateur de base de données particulier pour une sécurité renforcée de votre base de données.
MariaDB 10.5 a également vanté ses améliorations avec le moteur de stockage InnoDB pour ses performances et certaines nouvelles variables sont également présentées mais les principales variables obsolètes ont été marquées obsolètes ou totalement supprimées. Par exemple, notez que dans MariaDB 10.5, innodb_buffer_pool_instances a déjà été marqué comme obsolète alors qu'il est configuré pour être supprimé dans la version 10.6. Si vous êtes curieux de connaître la raison qu'ils disent, veuillez consulter MDEV-15058.
Avec tous ces changements, il est préférable de publier ce blog pour fournir un guide sur la mise à niveau de MariaDB 10.4 vers MariaDB 10.5. Nous allons détailler étape par étape les éléments à prendre en compte pour la mise à niveau.
Ce dont vous avez besoin avant la mise à niveau
Ce n'est pas toujours la meilleure méthode pour mettre à jour votre base de données en production sans faire de test. Ce jargon simple définit le terme que nous appelons SNAFU. Vous pouvez cliquer sur Google pour trouver le terme, mais fondamentalement, il est toujours préférable de ne pas toucher à la santé normale, en particulier les systèmes fonctionnant normalement. Cependant, votre système ne doit pas toujours rester constant, il doit être mis à niveau pour bénéficier des correctifs de sécurité, des corrections de bogues et des fonctionnalités avancées présentes sur les versions les plus récentes. Ainsi, dans ce cas, vous avez toujours un mécanisme de restauration planifié et configuré avant la mise à niveau. Si la mise à niveau du système rencontre des problèmes qui n'ont pas été observés, cela peut avoir un impact sur votre entreprise.
Toujours créer une sauvegarde de votre base de données
Dans ce cas, toujours fournir une sauvegarde de vos données. Vous pouvez utiliser des outils tels que mariabackup ou mydumper ou, si vous êtes un utilisateur de ClusterControl, utiliser l'outil Database Backup Management. Si vous n'êtes pas encore préparé au type de sauvegarde dont vous avez besoin, vous devrez peut-être vérifier les meilleures pratiques lors de la sauvegarde.
Testez... Testez… et retestez
Alors que la sauvegarde fournit des données à alimenter au cas où vous auriez besoin de restaurer son état initial en cas de problèmes imprévus, la mise à niveau vers une version majeure doit d'abord être testée sur une machine de développement ou de préproduction. Pour les grandes entreprises, il est courant de toujours effectuer un test de régression sur un environnement QA ciblé ou un environnement intermédiaire où la mise à niveau des serveurs de base de données vers sa version majeure doit d'abord être appliquée. Tous les systèmes de l'application et de la base de données doivent procéder à un test de régression ou à une série de tests d'assurance qualité jusqu'à ce que tout soit passé. Ce n'est pas une bonne idée de simplifier un cas de test de votre application allant aux systèmes de base de données et d'exclure simplement que tout va bien tant que la base de données ne plante pas ou qu'elle n'a été prouvée que pendant une courte période où le test est Bref, un test très simple qui ne couvre qu'un petit pourcentage de votre système global. Le test de votre mise à niveau d'abord sur un environnement de test ou d'assurance qualité doit être priorisé de manière à ce qu'il doive atteindre la forme parfaite de votre application sans affecter le côté commercial et également les utilisateurs qui vont utiliser votre application, plutôt que de se rendre compte tard que la mise à niveau de la base de données entraîne un comportement anormal de votre système en raison de changements que vous n'avez pas encore découverts.
Préparer une procédure de restauration
Tout doit être planifié lors de la mise à jour de votre base de données. Chaque fois que la sauvegarde est disponible et que les tests révèlent des résultats solides et prometteurs, elle se sent toujours sécurisée et prévisible en cas de problèmes inattendus lors de la mise à niveau de vos serveurs de base de données MariaDB de production. Dans ce cas, écrivez et préparez toujours une procédure qui ramène les choses à la normale de manière fluide et transparente.
Si votre fenêtre de maintenance n'est pas trop longue, la préparation d'une procédure de restauration à l'aide d'outils automatisés tels que Ansible, Chef, Puppet, SaltStack ou Terraform peut être un bon choix pour la procédure de restauration. Il minimise les erreurs humaines et offre rapidité et agilité pour effectuer des tâches vitales. Bien que cela puisse endommager le cas où une seule erreur surviendrait si le script d'automatisation échoue, cela signifie également que vous ne pouvez pas ignorer la possibilité que cela se produise. Par conséquent, cela indique également que la restauration doit être transparente et a été correctement testée pour pouvoir être restaurée dans une procédure valide.
Procédures de mise à niveau de MariaDB
La mise à niveau de votre version MariaDB 10.4 vers 10.5 n'est pas un problème, mais simple. Vous trouverez ci-dessous les étapes à suivre pour mettre à niveau vers la dernière version de MariaDB 10.5.
Préparez votre référentiel
Il est compréhensible que vous ayez MariaDB 10.4, il est donc supposé qu'il existe un référentiel présent dans vos nœuds de serveur MariaDB actuels. Sinon, vous pouvez quand même ajouter un référentiel et c'est tout simple.
Ubuntu/Debian
Pour les systèmes basés sur Ubuntu/Debian, pour un référentiel mariadb existant, vous pouvez modifier le référentiel. Vous pourrez peut-être vérifier si les référentiels existants se trouvent sur votre hôte ou trouver s'il existe un référentiel MariaDB existant quelque part. Pour ce faire, il vous suffit de
$ grep ^[^#] /etc/apt/sources.list /etc/apt/sources.list.d/*Généralement, vous disposez d'un dépôt mariadb.list. Dans ma configuration dans Ubuntu 18.0 (Bionic), cela se présente comme suit :
[email protected]:/vagrant# cat /etc/apt/sources.list.d/mariadb.list
deb [arch=amd64] http://ftp.osuosl.org/pub/mariadb/repo/10.4/ubuntu bionic mainExécutez simplement la ligne de commande suivante pour ajouter le référentiel MariaDB 10.5,
. /etc/os-release
sudo echo "deb [arch=amd64] http://ftp.osuosl.org/pub/mariadb/repo/10.5/${ID} ${VERSION_CODENAME} main" >> /etc/apt/sources.list.d/mariadb.listAvant que les packages MariaDB puissent être installés, il faut que les packages à installer soient importés avec la clé publique GPG qui est utilisée pour vérifier les signatures numériques des packages dans leur référentiel. Vous pouvez vérifier vos clés apt avec ce qui suit,
$ apt-key list |grep -C2 -i 'mariadb'Si les clés ne sont pas importées,
$ sudo apt-key adv --recv-keys --keyserver hkp://keyserver.ubuntu.com:80 0xcbcb082a1bb943dbou pour les nouvelles versions basées sur Ubuntu/Debian, c'est-à-dire à partir de Debian 9 (Stretch), et Debian Unstable (Sid) et Ubuntu 16.04 LTS (Xenial),
$ sudo apt-key adv --recv-keys --keyserver hkp://keyserver.ubuntu.com:80 0xF1656F24C74CD1D8Une fois terminé, il suffit de lancer
$ sudo apt updateCentOS/RHEL
Pour CentOS/RHEL, si vous avez un référentiel existant, vous pouvez simplement ajouter ou modifier le fichier. Sinon, ajouter les lignes ci-dessous pour le référentiel MariaDB 10.5 suffira aux exigences du référentiel (voir mariadb.repo). Par exemple, j'ai le mariadb.repo suivant dans mon hôte CentOS 8.0.
[[email protected] ~]# cat /etc/yum.repos.d/mariadb.repo
[mariadb]
name = MariaDB Repository
baseurl = http://yum.mariadb.org/10.4/centos8-amd64
enabled = 1
gpgkey = https://yum.mariadb.org/RPM-GPG-KEY-MariaDB
gpgcheck = 1
[mariadb_10.5]
name = MariaDB Repository For 10.5
baseurl = http://yum.mariadb.org/10.5/centos8-amd64
enabled = 1
gpgkey = https://yum.mariadb.org/RPM-GPG-KEY-MariaDB
gpgcheck = 1Vous pouvez vérifier que si le référentiel MariaDB est activé et fonctionne correctement :
[[email protected] ~]# dnf --disablerepo=* --enablerepo=mariadb_10.5 repolist
repo id repo name status
mariadb_10.5 MariaDB Repository For 10.5 83Mettre à niveau vos packages MariaDB
La mise à niveau avec MariaDB est très simple. Assurez-vous d'abord d'avoir correctement arrêté le serveur MariaDB.
Pour un serveur de production occupé et en direct, assurez-vous que vous n'avez aucune connexion entrante et que les pages modifiées sont correctement vidées sur le disque. Avant d'arrêter le serveur, vous pouvez définir le vidage des pages sales avec votre moteur de stockage Innodb de manière agressive afin que toutes les pages sales soient toutes vidées et accélèrent le processus d'arrêt,
set global innodb_max_dirty_pages_pct = 0;Ensuite, surveillez les pages sales avec ce qui suit,
$ mysqladmin ext -i10 | grep dirty
| Innodb_buffer_pool_pages_dirty | 0 |
| Innodb_buffer_pool_bytes_dirty | 0 |Une fois bon, arrêtez l'instance MariaDB,
systemctl stop mariadbPour un cluster de bases de données maître/réplica, il est recommandé de toujours démarrer votre mise à niveau sur la ou les répliques. Donc, avant la mise à niveau et après l'arrêt, assurez-vous d'avoir ajouté les éléments suivants dans votre fichier de configuration my.cnf,
[mysqld]
….
skip-slave-startCela vous permet d'éviter de démarrer automatiquement les threads de réplication au démarrage du serveur MariaDB. Cela vous donne plus de sécurité et évite d'autres erreurs dans la réplication. Ne démarrez les threads de réplication manuellement qu'une fois prêts avec l'instruction suivante,
START SLAVE;Ubuntu/Debian
La mise à niveau avec des systèmes basés sur Ubuntu/Debian est assez simple,
sudo apt install --only-upgrade mariadb-server mariadb-client mariadb-backup mariadb-commonBien sûr, ne fournissez pas l'option -y afin que vous puissiez revoir les packages suivants à mettre à jour.
Centos/RHEL
Comme avec les systèmes basés sur Ubuntu/Debian, CentOS/RHEL ne montre également aucun problème pour mettre à niveau votre version actuelle de MariaDB 10.4. Vous pouvez exécuter la commande suivante ci-dessous pour suffire au processus,
$ dnf --disablerepo=* --enablerepo=mariadb_10.5 upgrade Mariadb-server MariaDB-client MariaDB-backup MariaDB-common Mariadb-sharedPost-installation/mise à niveau du package
Une fois les packages mis à jour. Puisqu'il s'agit d'une mise à jour majeure, n'oubliez pas de recharger le démon pour systemd. Courez,
$ systemctl daemon-reloadMaintenant que vous êtes prêt, démarrez le service mariadb
$ systemctl start mariadbet exécutez mysqld_upgrade,
$ mysql_upgrade Lors de l'exécution de mysql_upgrade, surveillez toujours le journal des erreurs afin de détecter toute erreur avant d'exécuter et de tout démarrer pour vos opérations normales :
tail -5f /var/log/mariadb/mariadb.logConseils de mise à niveau pour les utilisateurs de ClusterControl
Étant donné que ClusterControl ne fournit pas de mise à niveau des versions majeures, lors de la mise à niveau d'un package, n'oubliez jamais de désactiver les modes de récupération automatique pour votre cluster MariaDB. Définissez les nœuds en mode maintenance afin que les alertes soient silencieuses et qu'aucune fausse alerte ne soit notifiée.
