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)
BTRFS est-il adapté pour les bases de données d'analyse ? Non.
Intéressant benchmarking.
Shorter: l'utilisation du copy-on-write plombe les performances de 50%, quelque soit le système de fichier qui l'emploi. Mais en plus, BTRFS, à cause de sa popote interne obtient une variabilité impressionnante dans les perfs.
Moralité ? Si on veut faire du live-snapshot sans outil couteux (ou base de données très chère qui le gère en interne) il vaut mieux utiliser un autre système de fichier COW compatible ou directement du LVM Linux.
L'avantage de ce dernier, c'est aussi de pouvoir passer en COW que lorsque nécessaire, donc d'impacter les performances la nuit quand la base est à peu près au repos.
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 :
Ah tiens, je découvre que ce problème a un nom : Two General's Problem.
C'est notamment ce qu'il se passe dans les commit-à-deux-phases des bases de données distribuées (et ACID) ou plus fréquemment sur les négociations via TCP.
C'est un problème démontré comme non calculable.
Un super article pour décrire les capacités de PostgreSQL face à ses principaux concurrents (les RDBMS open-source). Beaucoup de ces features ne se retrouvent même pas dans Oracle, DB/2, …
via : https://twitter.com/brouberol/status/659466786069479424
Microsoft va sortir une version de SQL Server "Always Encrypted". C'est bien.
Je n'ai pas regardé dans les détails, donc je ne sais pas si elle opère l'arithmétique.
Connaissez-vous d'ailleurs ça ? J'en ai entendu quand j'étais en master, il y a une huitaine d'année. Des bases de données qui peuvent manipuler des objets toujours chiffrés, y compris en appliquant des opérateurs arithmétiques. En gros : a op b = dec(enc-a enc-op enc-b) = dec(en-c) = c
via : https://twitter.com/FranmerMS/status/606695465619488768
Très bon historique des technologies de stockage de données. Où l'on voit que tout n'est qu'un problème de performance et de bottleneck.
10gen, développeur de MongoDB, lève 150 m$ pour atteindre 1.2M$ en valorisation. Pas mal pour du NoSQL.
Oracle serait intéressé ?