/var/log/greg.log - MySQL

Réplication MySQL multiple sources

Greg — Sun, 24 Jan 2010 20:10:00 +0100

Trop de données, trop d'écritures, la solution la plus rapide et facile à mettre en place consiste à déplacer des tables sur d'autres serveurs. Ainsi, on s'est retrouvé avec plusieurs "bulles" composées d'un master et de N slaves. Ce qui complique un peu quand même.

Déjà, les backups. Maintenant, il faut un slave supplémentaire par bulle pour le backup. Rappel: il faut arrêter la réplication pour avoir un bon backup capable de repartir, de reconfigurer un slave from scratch.

Autre problème, bien plus complexe: souvent, notamment pour les statistiques, il faut faire de grosses requêtes avec des JOINs inter tables et inter base de donnée.

Il existe des solutions à ces problèmes, rajouter des slaves, faire de la consolidation de donnée par batch pour les stats... et le multiple source replication. Cette fonctionnalité est hyper demandé chez MySQL, comme on peut le voir sur le worklog, il est d'ailleur en 1ère position !

Ca fait quelques semaines que je suis sur un script pour émuler le multiple source. En fait, plutôt que de me taper le protocole, j'utilise directement le binaire mysqlbinlog fournit avec mysql, qui permet de se connecter à un master, de lui demander les logs. On peut même lui demander les logs à partir d'un fichier précis, d'une position précise, et jusqu'à ce qu'il en ai plus !! Ce script utilise une base de donnée MySQL pour stocker les informations relatives à la réplication: position en cours, position suivante, fichier de log, erreurs... Il est capable de répliquer depuis plusieurs master (pas vraiment de limite, si ce n'est les performances du slave), mais attention, il se contente de lire les logs et de les executer, il est donc super préférable d'avoir des noms de base de données distinctes sur chaque master !

slave A ------- db a, b, c -------> \
slave B ------- db d, e ---------->  > msr slave
slave C ------- all db -----------> /

Vous trouverez les sources sur Rubyforge. Ce script tourne en environnement de production répliquant 3 slaves et 5 bases de données. J'ai fais quelques tests d'intégrité de données et n'ai pas constaté d'erreurs !

Restorer plus rapidement un dump MySQL

Greg — Tue, 25 Aug 2009 21:39:00 +0200

Mon backup comprend un dossier par base de donnée, un fichier SQL compressé par table. Voici une astuce pour restaurer ce backup plus rapidement, surtout sur un serveur multi-cores.

find -print0 | xargs -0 -n 1 -P 4 -I {} sh -c "zcat '{}' | mysql mydatabase"

Je n'ai pas fais de tests comparatifs, je sais juste que ça va vraiment beaucoup plus vite !!

Ca bouge chez MySQL !

Greg — Sun, 08 Feb 2009 08:42:00 +0000

Ces 2 dernières semaines ont été bien mouvementées chez MySQL !

Sortie de la 5.1.31

Cette version est importante car elle corrige de nombreux bugs critiques de la version GA 5.1.30, qui n'était tout simplement... pas stable. Cette nouvelle version est sortie le 19 janvier mais n'est apparu sur le site que bien plus tard... Il faut mieux surveiller les mirroirs FTP. En prod sur 6 serveurs depuis fin janvier, pour l'instant aucun crash à signaler, le bug semble donc bien corrigé.

Le père de MySQL, Monty, quitte SUN

Monty quitte SUN en bon terme, et monte sa société Monty Program AB, basée sur un modèle idéaliste ou tous les employés sont actionnaire (voir le détail), et surtout, ou l'open-source a toute son importance. Monty n'abandonne pas MySQL et va se consacrer à son moteur crash safe MariaDB. Mixer MariaDB, le moteur XtraDB de Percona, le tout dans Drizzle, et on a la base de donnée la plus performante du monde :)

Marten Mikos aussi !

Marten Mikos, directeur de MySQL, vice president de la section base de donnée chez SUN, quitte SUN à son tour.

Un an après le rachat par Sun de MySQL, les départs commencent... Avaient-ils un contrat leur obligeant de rester 1 an ? Une rumeur (à prendre comme tel) parle d'un départ d'une 20ène de développeurs MySQL pour Monty Program AB.

MySQL 5.1.31

Greg — Wed, 14 Jan 2009 19:52:00 +0000

MySQL devrait sortir ce mois-ci la version 5.1.31, qui corrigera entre autre le bug #38883 concernant InnoDB, qui cause des crashs aléatoires, lors de l'interrogation du status innoDB du serveur:

SHOW INNODB STATUS
innodb-status-file=1
MySQL enterprise monitor

Performances MySQL 5.1: 2nd round

Greg — Sun, 04 Jan 2009 09:38:00 +0000

Dans le billet précédent, j'ai eu un premier aperçu de MySQL 5.1.30 au niveau des performances, à comparaison égale avec 5.0.76, où on peut constater une nette dégradation des performances, notamment au niveau des accès disques (IO).

J'ai voulu profiter de cet environnement de prod en test un peu plus, parce que c'est pas tous les jours qu'on a ce genre d'occasion ! Parce que la prod, comme son nom l'indique, n'est pas un environnement de tests.... passons, je sais que c'est mal, mais je sais que si ça crash, rien ne se verra, les applications continueront de fonctionner sans erreurs, vive le web 2.0 !!

J'ai donc pu tester une des nouvelles feature de 5.1: le partitionnement. En terme de performance (toujours, toujours...) ça donne quoi ?

Ce graph CPU représente la phase de partitionnement: 3 tables de ~100 millions d'enregistrements chacunes. 99% des requêtes SQL concerne un status: WHERE status=1, j'ai donc partitionné ces tables par HASH sur cette colonne: la partition interrogé ne fait plus qu' 1/3 !!

L'impact sur les perfs est sans appels, et là MySQL 5.1 devient plus performant que 5.0. Sur le graph CPU suivant, on peut distinguer 3 périodes :

MySQL 5.0.76
MySQL 5.1.30
MySQL 5.1.30 avec tables partitionnées

Au niveau stabilité, le serveur n'a jamais planté, que ce soit lors du partitionnement, avant ou après. Cependant j'ai quelques problèmes avec son master qui est aussi en 5.1.30 et qui a crashé 2x en 1 mois... Un ticket est ouvert chez mysql.

MySQL 5.1 en prod: impact sur les performances

Greg — Tue, 23 Dec 2008 13:47:00 +0000

MySQL 5.1 GA est sortie en grande pompe, et tout le monde y va de son billet, pour ou contre. J'ai pu le mettre en environnement de production en mode master/slave et slave: le premier est slave d'un 5.0.56, et master d'un 2ème serveur en 5.1.30.

On peut nettement apercevoir sur le graph CPU suivant, la mise en prod de la version 5.1.30, avec une très nette augmentation des IO disques ! Le slave (22), en 5.0, prenait parfois du délais lors de la regénération de tables, en 5.1 il prend nettement plus de délais. Je n'ai même pas testé les nouvelles fonctionnalités comme le partitionnement, ayant lu sur plusieurs articles que cette version était encore trop buguée si on les utilisait...

Ah oui, et c'est pas tout... Le master/slave (21) a lamentablement crashé, après 6 jours seulement d'utilisation ! Un ticket est ouvert chez MySQL, qui n'a pas de solution, et attend le prochain crash avec cette fois les core dump d'activés. En espérant que ce crash n'arrive pas pendant les fêtes !