Le 5 mars 2019 à 13:10, Benoit Garcia benoit.garcia@gmail.com a écrit :
On Tue, Mar 5, 2019 at 10:26 AM Olivier Meyer via FRsAG frsag@frsag.org wrote:
Le mardi 5 mars 2019 à 10:08:39 UTC+1, Benoit Garcia benoit.garcia@gmail.com a écrit :
Si il n'y a pas besoin d'accéder aux données depuis l'extérieur de ton container (et ça devrait être le cas pour une base de données), je partirais sur des container volumes. Mais ce n'est que théorique, les seuls MySQL que je fais tourner dans du Docker sont pour des tests (restauration de backups, exécution de migration de données, etc). ah tu m'intéresses, tu backup ta base comment ? Tu sauvegardes le volume ? Tu fait un dump ta base en dehors de ton volume ? Tu intégres un client de backup dans ton container ?quid des performances ? Je ne pense pas que la sauvegarde du volume MySQL (ou de son contenu) ne puisse garantir la consistance de la base de données (pb des transactions en cours, etc). Donc pour moi c'est à éviter.
+1000, le snapshot d’un volume pour un SGBD(R) me fait toujours un peu peur, mais ça dépend du soft.
Si je devais réaliser les sauvegardes de MySQL dockerisé, je ne changerais pas des masses par rapport à ce que je fais aujourd'hui sur un serveur(/vm) dédié: Je lancerais ma sauvegarde via un outils qui pourrait se connecter à mon instance, que ce soit un outil genre Commvault ou des plus simples genre Mysqldump ou Xtrabackup. Éventuellement j’exécuterais ça dans un conteneur éphémère qui irait créer le jeu de sauvegarde sur un volume externe. J'archiverais ensuite le contenu de ce volume (bande, s3, glacier, whatever).
+2000
Reste à voir comment se feraient les restauration de données…
La plupart des (bonnes) images publiques intègre un mécanisme dans le script d'entrypoint pour importer des dumps sql (ou autre) que l’on peut passer via un volume.
Pour MySQL : https://github.com/docker-library/mysql/blob/a7a737f1eb44db467c85c8229df9d886dd63460e/8.0/docker-entrypoint.sh#L197
La convention est de placer les fichiers d'init dans /docker-entrypoint-initdb.d/