pas besoin d'arrêter la base ou de mettre en place des mécanisme complexe de snapshot
format de dump interopérable et pérenne
Mais de par son fonctionnement, il a des limites.
monopolise une transaction en lecture tout le temps de la lecture des tables.
doit générer du SQL ce qui est lent par rapport à une copie de fichier
la restauration elle aussi est très longue comparée à une copie de fichier car le SQL doit être interprété.
crée un fichier au moins aussi gros mais en pratique plutôt 2x plus gros que la base à sauvegarder car le SQL est plus verbeux que le binaire
n'est pas incrémentale, donc toute la base à scanner et tout la volumétrie à stocker à chaque sauvegarde
Pour une base un peu conséquente et sollicitée, il devient rapidement impossible de s'en servir pour un sauvegarde horaire. la prochaine horaire sera lancée avant même que la précédente ne soit finie. et le coût en S3, bien que bon marché, est loin d'être optimisé.
Les moyens de contournement de ces limitations seraient d'utiliser les binlogs pour l'incrémental et de la déduplication pour la full, le tout sur un slave.
C'est ce que suggère la documentation mysql d'ailleurs (ils ne parlent pas de déduplication mais de binlogs et de slave).
[^] # Re: Information sur le volume cible
Posté par steph1978 . En réponse à la dépêche Arkiv : Sauvegarde de fichiers et bases MySQL + archivage sur Amazon S3 et Amazon Glacier. Évalué à 2.
mysqldump a des atouts :
Mais de par son fonctionnement, il a des limites.
Pour une base un peu conséquente et sollicitée, il devient rapidement impossible de s'en servir pour un sauvegarde horaire. la prochaine horaire sera lancée avant même que la précédente ne soit finie. et le coût en S3, bien que bon marché, est loin d'être optimisé.
Les moyens de contournement de ces limitations seraient d'utiliser les binlogs pour l'incrémental et de la déduplication pour la full, le tout sur un slave.
C'est ce que suggère la documentation mysql d'ailleurs (ils ne parlent pas de déduplication mais de binlogs et de slave).