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)

via : http://sebsauvage.net/links/?8vhoGw

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.