Comment OVH gère le backup de dizaines de milliers de bases de données (MySQL et PostgreSQL) ?
TL;DR:
- répartition homogène des backup dans le temps grâce à une fonction de hachage sur le nom de la base ;
- dump avec verrouillage de tables si présence de tables MyISAM ;
- dump avec transaction si 100% InnoDB ;
- backup en sus au format SGBD (avec XtraBackup) si base volumineuse (temps de restore > 10 minutes) ;
- mysqlcheck pour réparer au préalable les tables, mais en prenant soin de doubler la RAM temporairement ;
- backup exportés et dédupliqués (cluster Ceph, disques locaux si prod externe, Cloud Storage)
Comment configurer sa base de données avec un SSD ?
Réponse rapide (pour InnoDB mais généralisable) :
- Sur disque rotatif (HDD) : REDO logs, BIN logs, tablespace (system ou general), buffer data
- Sur disque solide (SSD) : UNDO logs, table files (donc les table-space si on utilise separate table-space)
C'est assez dingue en soit : ça veut dire que les bases de données sont largement optimisées pour fonctionner sur disque classique, et que seule une petite partie du traitement est à accès aléatoire (donc déplaçable sur SSD).
Random i/o oriented:
- Table files (*.ibd)
- UNDO segments (ibdata)
Sequential write oriented:
- REDO log files (ib_logfile*)
- Binary log files (binlog.XXXXXX)
- Doublewrite buffer (ibdata)
- Insert buffer (ibdata)
- Slow query logs, error logs, general query logs, etc
D'ailleurs, fait intéressant dans l'article : il obtient une perf meilleure en HDD + SDD que en dual SSD. Peut-être parce que les SSD sont en bus SATA commun et que ce dernier sature, alors que ses HDD sont en bus SAS (donc séparé).
Pour aller plus loin, et configurer proprement la base :
Une bonne page pour l'optimisation générale de MySQL (dont InnoDB). Ça liste un peu toutes les variables importantes et ce qu'il faut faire.
Une rainbow table distribuée accessible en ligne. Marche aussi avec les pass MySQL :) = sha1(sha1_bin())
Si réel… c'est d'ailleurs un truc qui est arrivé à mon travail.
Un conseil : MySQL avec innodb, désactiver l'autocommit pour les utilisateurs en shell (ceux qui bidouillent quoi)
Putain… l'égalité avec <=> en MySQL quand des membres peuvent être NULL…
Bon à savoir. Injection possible si les chaînes en entrée sont échappés via mysql_real_escape_string.
Intéressant : connexion mysql sécurisée sans mot de passe. J'avais besoin de faire ça depuis longtemps !
Malheureusement, je n'ai pas réussi à utiliser en plus l'option de proxy de mysql (pour qu'un utilisateur soit reconnu comme un autre) en se basant sur l'utilisation de ce plugin.
TT-RSS, c'est vraiment un très bon agrégateur.
Cependant, le moteur est vraiment super mal foutu : le schéma SQL n'est pas du tout optimisé (au niveau des index notamment, mais pas que : toute la logique de lecture/écriture est à refaire)
Si bien que j'ai des valeurs totalement aberrantes dans l'analyseur de MySQL. Exemple, depuis 12 jours, j'ai obtenu 206 millions de lecture de "l'élément suivant" d'une table… 40 millions de lectures basées sur une position fixe…
Bref, comme solution temporaire, je joue avec les tables temporaires et la taille des différents caches d'InnoDB/MySQL. Mais il reste que le schéma est vraiment pas terrible => pas de passage à l'échelle.
P.S : l'auteur indique lui-même sur son site qu'il a fait ça dans son coin, pour lui au départ, et qu'il n'a pas envisagé de faire un truc performant au départ. Si je maitrisais le SQL + le back en PHP, je lui filerais bien un coup de main pour refondre ça au propre. Parce que c'est vraiment un très bon boulot à part ces quelques soucis.
EDIT : WOUAH !!! Les IO de mes disques ont littéralement chuté rien qu'en augmentant des caches. J'entendais un bruit de disque permanent, il a disparu tout d'un coup… Punaise.
Chez OVH, on ne paye pas en fonction de la taille des bases de données qu'on gère, mais en fonction des performances qu'on souhaite (ici, corrélé à la taille de la mémoire vive)
C'est une approche originale, qui du coup peut devenir vraiment très intéressante pour des cas d'usage particuliers.