Je ne sais pas ce que tu veux dire quand tu parles de contrepartie. Il n'y a pas de limite au volume. C'est sûr que si tu as de grosses bases de données et/ou des fichiers volumineux, la sauvegarde risque de prendre du temps. Mais c'est difficile de faire autrement. Comme il est possible d'exécuter plusieurs instances d'Arkiv en parallèle, avec des fichiers de configuration différent, on peut imaginer faire des sauvegardes séparées pour que les données les plus légères soient archivées plus fréquemment.
Le dump de la base se fait dans une transaction, donc il n'y a pas besoin de mettre quoi que ce soit en pause à la condition que les tables soient toutes en InnoDB. La chose est détaillée dans un article de mon blog.
Ensuite, il est possible de mettre en place une stratégie de réplication maître-esclave, pour que la sauvegarde des bases se fasse sur un esclave (afin de ne pas impacter le serveur maître, que ce soit en consommation CPU ou mémoire). Il est aussi possible d'utiliser les logs binaires ; c'est alors une sauvegarde classique de fichier. Mais il vaut quand même mieux avoir un dump complet de temps en temps.
Pour la question du partitionnement des tables, c'est quelque chose que je n'ai jamais vu mis en œuvre uniquement pour la sauvegarde (je l'ai déjà vu pour faire du sharding par exemple). Sur quel genre de volumétrie as-tu eu besoin de faire ça ?
Les seules limites pour le moment concernent Amazon :
- Les fichiers peuvent faire jusqu'à 5 TO sur Amazon S3 (source)
- Les fichiers peuvent faire jusqu'à 40 TO sur Amazon Glacier (source)
Je ferai peut-être une évolution pour découper les fichiers dont la taille est supérieure à ces limites. Je n'en ai personnellement pas le besoin, donc si ça peut être utile à quelqu'un, ce serait bien de me faire signe :)
[^] # Re: Information sur le volume cible
Posté par Amaury Bouchard (site web personnel) . En réponse à la dépêche Arkiv : Sauvegarde de fichiers et bases MySQL + archivage sur Amazon S3 et Amazon Glacier. Évalué à 3.
Merci pour les remerciements :)
Je ne sais pas ce que tu veux dire quand tu parles de contrepartie. Il n'y a pas de limite au volume. C'est sûr que si tu as de grosses bases de données et/ou des fichiers volumineux, la sauvegarde risque de prendre du temps. Mais c'est difficile de faire autrement. Comme il est possible d'exécuter plusieurs instances d'Arkiv en parallèle, avec des fichiers de configuration différent, on peut imaginer faire des sauvegardes séparées pour que les données les plus légères soient archivées plus fréquemment.
Le dump de la base se fait dans une transaction, donc il n'y a pas besoin de mettre quoi que ce soit en pause à la condition que les tables soient toutes en InnoDB. La chose est détaillée dans un article de mon blog.
Ensuite, il est possible de mettre en place une stratégie de réplication maître-esclave, pour que la sauvegarde des bases se fasse sur un esclave (afin de ne pas impacter le serveur maître, que ce soit en consommation CPU ou mémoire). Il est aussi possible d'utiliser les logs binaires ; c'est alors une sauvegarde classique de fichier. Mais il vaut quand même mieux avoir un dump complet de temps en temps.
Pour la question du partitionnement des tables, c'est quelque chose que je n'ai jamais vu mis en œuvre uniquement pour la sauvegarde (je l'ai déjà vu pour faire du sharding par exemple). Sur quel genre de volumétrie as-tu eu besoin de faire ça ?
Les seules limites pour le moment concernent Amazon :
- Les fichiers peuvent faire jusqu'à 5 TO sur Amazon S3 (source)
- Les fichiers peuvent faire jusqu'à 40 TO sur Amazon Glacier (source)
Je ferai peut-être une évolution pour découper les fichiers dont la taille est supérieure à ces limites. Je n'en ai personnellement pas le besoin, donc si ça peut être utile à quelqu'un, ce serait bien de me faire signe :)