Skip to content

adminsys

MariaDB, plugin-load et la table mysql.plugin

Bonne journée à tous en ce début de semaine et de mois :)
Bonne nouvelle, le futur album #Drones de MUSE va paraître en Juin 2015 ; et un single #Psycho risque de sortir dans quelques semaines.

Le problème

Avec MariaDB <=10.0.16 ; lorsque vous utilisez des “storage engine” reposant sur des plugins (comme Spider, TokuDB) vous pouvez être confrontés à ce genre de message d’erreur dans mysqld.err lors du démarrage de mysqld :

150302 9:09:58 [Note] Plugin 'FEEDBACK' is disabled.
150302 9:09:58 [ERROR] Function 'TokuDB' already exists
150302 9:09:58 [Warning] Couldn't load plugin named 'TokuDB' with soname 'ha_tokudb.so'.
150302 9:09:58 [ERROR] Function 'TokuDB_trx' already exists
150302 9:09:58 [Warning] Couldn't load plugin named 'TokuDB_trx' with soname 'ha_tokudb.so'.
150302 9:09:58 [ERROR] Function 'TokuDB_lock_waits' already exists
150302 9:09:58 [Warning] Couldn't load plugin named 'TokuDB_lock_waits' with soname 'ha_tokudb.so'.
150302 9:09:58 [ERROR] Function 'TokuDB_locks' already exists
150302 9:09:58 [Warning] Couldn't load plugin named 'TokuDB_locks' with soname 'ha_tokudb.so'.
150302 9:09:58 [ERROR] Function 'TokuDB_file_map' already exists
150302 9:09:58 [Warning] Couldn't load plugin named 'TokuDB_file_map' with soname 'ha_tokudb.so'.
150302 9:09:58 [ERROR] Function 'TokuDB_fractal_tree_info' already exists
150302 9:09:58 [Warning] Couldn't load plugin named 'TokuDB_fractal_tree_info' with soname 'ha_tokudb.so'.
150302 9:09:58 [ERROR] Function 'TokuDB_fractal_tree_block_map' already exists
150302 9:09:58 [Warning] Couldn't load plugin named 'TokuDB_fractal_tree_block_map' with soname 'ha_tokudb.so'.

Cela est du au fait que mysqld tente une seconde fois de charger le même plugin (ici tokudb).

Fort probable, vous avez dans votre my.cnf une configuration comme :

plugin-load=ha_tokudb

La première fois que vous avez démarré mysqld avec ces instructions, et jusqu’à que MariaDB l’installe dans ses tables systèmes, rien à signaler dans le mysqld.err

Mais aussitôt que vous aurez – par exemple – instancié une table TokuDB, alors MariaDB ajoute TokuDB dans sa table mysql.plugin pour charger automatiquement l’extension au prochain chargement de mysqld (ce qui fera doublon à la configuration du my.cnf) :

MariaDB [mysql]> select * from mysql.plugin where dl = 'ha_tokudb.so';
+-------------------------------+--------------+
| name                          | dl           |
+-------------------------------+--------------+
| TokuDB                        | ha_tokudb.so |
| TokuDB_trx                    | ha_tokudb.so |
| TokuDB_lock_waits             | ha_tokudb.so |
| TokuDB_locks                  | ha_tokudb.so |
| TokuDB_file_map               | ha_tokudb.so |
| TokuDB_fractal_tree_info      | ha_tokudb.so |
| TokuDB_fractal_tree_block_map | ha_tokudb.so |
+-------------------------------+--------------+
7 rows in set (0.00 sec)

La solution court-terme

Retirer “plugin-load=ha_tokudb” de votre my.cnf

Le problème de la solution

Que se passera-t’il le jour où vous démarrerez mysqld avec un datadir complètement vide, dans le but, par exemple, de restaurer une sauvegarde ?

L’import échouera lorsque il rencontrera une table TokuDB, parce qu’il ne connaitra pas le “storage engine” (le plugin correspondant n’aura pas été chargé).

Il faudra alors soit :

  • remettre la configuration dans le my.cnf ; re-démarrer mysqld ; retirer la configuration du my.cnf ; et faire l’import de votre sauvegarde
  • penser à charger le plugin – manuellement – avant l’import – avec l’instruction suivante :
INSTALL SONAME 'ha_tokudb'

Des idées de solutions long-terme

MariaDB

MariaDB devrait accepter que my.cnf et mysql.plugin fassent référence au même plugin, et que MariaDB soit assez intelligent pour ignorer la situation, en se basant à minima sur le nom du fichier, ou un checksum du .so

MyDumper / MysqlDump

Les outils de sauvegarde (notamment ceux cités) devraient s’assurer qu’en tête des instructions qui seront exécutés pour restaurer un “backup” ; des routines soient présentes pour charger – si nécessaire – les plugins qui seront ultérieument nécessaire, notamment pour des tables et leurs “storage engine”.

 

Conclusions

J’ai poussé les idées en question auprès du support de MariaDB.

Voir aussi : https://mariadb.com/kb/en/mariadb/enabling-tokudb/

 

gentoo atom regexps (ebuild name and versions)

Working on the Ansible Gentoo Portage emerge module, i’m testing some regexp for matching an atom string.

Atom is a Gentoo Portage pkgcore term.
An atom is a string representing a package name, and, optionally, it version range or version, the ebuild revision, the slot or slot and subslot.

To permit the future ansible module to handle the atom to be a parameter, i have to write some regexp for matching different atom alternative.

The first cases are simply to list, by parsing /usr/portage for avaiables packages, and atom : (here a simple bash/gawk/perl script to check the regexp)

#!/bin/bash

reg_ebuild_without_version='/^([a-z0-9\-]+)\/([a-zA-Z0-9\_\+\-]+)$/'
reg_ebuild_with_version='/^=?([a-z0-9\-]+)\/([a-zA-Z0-9\_\+\-]+)\-([^\-]+(\-r\d+)?)$/'

# this re
find /usr/portage/ -mindepth 2 -maxdepth 2 -type d | \
        gawk -F '/usr/portage/' '{ print $2; }' | \
        perl -pi -e "while(){ next if(${reg_ebuild_without_version}); print; }"

# this regexp must match a app-category/ebuild-name-X.Y.Z-rN
find /usr/portage/ -mindepth 3 -maxdepth 3 -type f -name '*.ebuild' | \
        perl -pi -e 's/\.ebuild$//g;' | \
        gawk -F '/usr/portage/' '{ print $2; }' | \
        gawk -F '/' '{ printf "%s/%s\n",$1,$3 }' | \
        perl -pi -e "while(){ next if(${reg_ebuild_with_version}); print; }"

Thoses regexp are not enougth to match any differents atom.

Some on the missing ones are already testing in the non-finished first version of the emerge module :

davixx/ansible/library/emerge (2013-01-20 version)

I hope, within 7 days, to finish the emerge_parse_atom function for handling successfully  almost 5-6 atom string cases.

ansible – sysctl module

The first version of my sysctl module for ansible have been merged to the devel tree of the mainstream ansible projet (on github) by mpdehaan.

You can now use easily this sysctl module :

  • by using git pull, if you have installed ansible by a simple git clone
  • by downloading manually sysctl in the library subdirectory of your playbooks :
cd /path/to/my/playbooks
[ -d "library" ] || mkdir -v library
wget https://raw.github.com/ansible/ansible/devel/library/sysctl -O library/sysctl
Ansible Servers Orchestration
Ansible is the easiest way to deploy, manage, and orchestrate computer systems you’ve ever seen. You can get started in minutes

After that, you can now use the sysctl module in your playbooks (extracted from the embedded documentation) :

  • Set vm.swappiness to 5 in /etc/sysctl.conf
    (first, check if /proc/sys/vm/swappiness file exist and is writteable, and after change, call sysctl -p and verify if /proc/sys/vm/swappiness file content is now 5) :
sysctl: name=vm.swappiness value=5 state=present
  • Remove kernel.panic entry from /etc/sysctl.conf
sysctl: name=kernel.panic state=absent sysctl_file=/etc/sysctl.conf
  • Set kernel.panic to 3 in /tmp/test_sysctl.conf, check if the sysctl key seems writable, but do not reload sysctl, and do not check kernel value after (not needed, because it is not the real /etc/sysctl.conf updated) :
sysctl: name=kernel.panic value=3 sysctl_file=/tmp/test_sysctl.conf check=before reload=no

gentoo fcron and system crontab

After a new install of gentoo with fcron-3 :

  • there is no /etc/crontab file ; and is it wanted (by default).
  • also, system crontab must not be setup in root crontab’s, but in systab  crontab, using the check_system_crontabs tool.
  • finally, note that by default, /etc/cron.* is not handled by fcron.

So, if you wanna to add support for /etc/cron.* you can :

  • Add this line in a new /etc/crontab (or in an existing if there is no equivalent lines already) :
%hourly * /bin/run-parts /etc/cron.hourly
%daily * * /bin/run-parts /etc/cron.daily
%weekly * * /bin/run-parts /etc/cron.weekly
%monthly * * * /bin/run-parts /etc/cron.monthly
  • Last point do nothing, just a file is updated, not any crontab.
  • Now you call the tool :
check_system_crontabs -v -i -f
  • This command will create or update dynamically the crontab of the systab user (needed by fcron for system crontab, created by the gentoo ebuild)
  • You can after check that the generated systab crontab is the concatenation of your /etc/crontab, any /etc/cron.d/ entry, and a call to the check_system_crontabs tool himself to update – if needed – the crontab – every ten minutes (in fact, for this laspoint, he use the content of /etc/fcron/fcrontab file) :
fcrontab -usystab -l

Découverte d’ansible – Orchestration de serveurs

Bonjour !

Je viens de découvrir ansible, et j’ai décidé de tenter de l’utiliser, pendant quelques mois, pour mes besoins personnels et pour certains clients.

Pourquoi ansible au lieu de Opscode Chef  ou Puppet ou CFEngine pour gérer le parc de configuration, le déploiement de logiciels, et autres ?

Sincèrement je n’ai pas de raisons majeures à ce stade, je fais les choses au feeling, je n’ai pas assez d’expérience dans les alternatives citées pour les juger.

Ansible Servers Orchestration powerfull tools
Ansible Servers Orchestration powerfull tools

Par contre, voici les premiers plus qui m’ont attirés et qui m’ont menés là : (sans pour autant sous-entendre que les alternatives ne peuvent pas, dans certains cas, en faire autant)

  • une architecture reposant sur ssh, l’installation d’aucun agent sur chacun des nodes n’est nécessaire.
  • une architecture modulaire, dans laquelle un script bash, python, php, ou encore un binaire peuvent être utilisés de manière transparente.
  • un mode had-hoc, avec lequel je peux – par exemple – déployer en une seule ligne de commande, propager un nouveau réglage pour la conntrack sur un pool de 45 serveurs.
  • un mode playbook, avec lequel je modélise des configurations idempotentes partielles et/ou totales de serveurs que je peux ensuite appliquer sans avoir la nécessité d’être un développeur, le playbook ressemble plus à une documentation rédigé au format yaml plutôt qu’un script en ruby.
  • pas d’abstraction sur le système d’exploitation des nodes et de son gestionnaire de paquets ; et cela volontairement ; pourquoi ? la pluralité des OS fait que certaines distributions Linux par exemple, ont des particularités qui sont valorisables. Reposer sur un outil qui ne retiendrait que le plus petit dénominateur de chaque distribution serait une sorte de gaspillage.

Et donc ?

Le projet ansible est récent (environ 1 an) initié – entre autres – par Michael DeHaan (un développeur ayant un historique dans les outils d’orchestration/industrialisation)

Ansible est disponible sur GitHub, je l’ai forké pour pouvoir contribuer en développant le module sysctl en un premier temps, et pour le module emerge (gestionnaire de paquet de Gentoo) en un second temps.