Sauvegardes MySQL intemporelles sur un budget

Mon scénario de sauvegarde MySQL actuel consiste à répliquer notre base de données sur un deuxième serveur et à exécuter mysqldump sur ce serveur pour supprimer tout temps d'arrêt du verrouillage de table ou de ligne. Cela fonctionne bien mais coûte 150 $ par mois pour le deuxième serveur (l'hébergement australien est beaucoup plus cher qu'aux États-Unis.)

J'ai lu beaucoup de questions ici à ce sujet, la plupart des gens ont besoin d'aide pour les sauvegardes planifiées et ainsi de suite, ce qui n'est pas ce dont j'ai besoin. J'ai besoin de mysqldump (de préférence toutes les 4 heures) sans temps d'arrêt. La base de données est ~ 7 Go non compressée, donc le mysqldump peut prendre un certain temps en fonction du serveur.

J'ai envisagé de répliquer sur la même machine, mais je ne voulais pas que l'esclave mange dans la mémoire dont il avait tant besoin. Je ne suis pas sûr de pouvoir limiter l'utilisation de la mémoire par base de données? Quoi qu'il en soit, cela mettra la charge sur le serveur pendant qu'il vide la base de données.

Je viens de lire ce http://www.zmanda.com/quick-mysql-backup.html et ça a l'air bien, 300 $ par an, c'est ok, ça me fait économiser beaucoup.

Malheureusement, je ne peux pas répliquer sur le RDS d'Amazon mais je pourrais répliquer sur une instance micro RC2 mais la réplication aurait lieu sur le net et le ping est ~ 220 ms.

J'ai vu quelques personnes ici parler d'instantanés LVM, ce qui pourrait être une bonne option. Je ne connais pas grand-chose à cette option.

Les opinions seraient grandement appréciées.

Si vous utilisez des tables innodb, vous pouvez utiliser

http://www.percona.com/docs/wiki/percona-xtrabackup:start

Cela nécessitera un vidage de votre base de données qui peut être importé par leurs outils également sans verrouillage. Je crois que si vous avez des tables myisam, cela les verrouille.

Si vous utilisez innodb ou un autre backend entièrement transactionnel, vous pouvez l'utiliser mysqldump --single-transaction .... Je l'ai utilisé sur des bases de données assez grandes (~ 100 Go) avec de bons résultats; si la base de données est sous forte charge, cela peut prendre des heures mais cela fonctionne sans verrouiller vos tables. La réplication est généralement meilleure mais parfois vous voulez un joli fichier de vidage solide. Gardez à l'esprit que vous pouvez également vider un esclave de réplication mysql.

À partir de la page mysqldump (notez les mises en garde concernant les opérations susceptibles de fuir dans la transaction):

 ·   --single-transaction

   This option sends a START TRANSACTION SQL statement to the server
   before dumping data. It is useful only with transactional tables
   such as InnoDB, because then it dumps the consistent state of the
   database at the time when BEGIN was issued without blocking any
   applications.

   When using this option, you should keep in mind that only InnoDB
   tables are dumped in a consistent state. For example, any MyISAM or
   MEMORY tables dumped while using this option may still change
   state.

   While a --single-transaction dump is in process, to ensure a valid
   dump file (correct table contents and binary log coordinates), no
   other connection should use the following statements: ALTER TABLE,
   CREATE TABLE, DROP TABLE, RENAME TABLE, TRUNCATE TABLE. A
   consistent read is not isolated from those statements, so use of
   them on a table to be dumped can cause the SELECT that is performed
   by mysqldump to retrieve the table contents to obtain incorrect
   contents or fail.

Je ne vois pas beaucoup de problème de réplication sur une connexion à latence élevée vers un VPS bon marché aux États-Unis. La latence élevée ne devrait pas vraiment être un gros problème. La réplication est conçue pour être en mesure de rattraper son retard rapidement même lorsqu'un esclave est en retard de plusieurs heures , c'est-à-dire qu'elle peut fonctionner de manière asynchrone.

Tant que vous pouvez supporter autant de bande passante sortante sur votre plan d'hébergement australien.

Voici une réponse beaucoup plus détaillée pour savoir si la latence élevée importerait

De façon réaliste, seul le temps nécessaire pour exporter réellement la base de données sera un temps d'arrêt. Faites-le pendant une période suffisamment lente et il ne devrait y avoir AUCUN problème. À quoi s'attend vraiment un service informatique sur ce budget?

Vous devriez pouvoir mysqldump une base de données de 7 Go en 5-10 minutes MAX, retirer le verrou de lecture / écriture et le temps d'arrêt sera terminé. Vous pouvez alors trouver le moyen le plus efficace de bande passante pour le fichier de 7 Go vers le nouveau serveur (lire: HAUTE COMPRESSION). Vous avez beaucoup de temps pour transférer et importer le fichier dans MySQL sur le nouveau serveur. Entrez ensuite les informations du journal principal et lancez la réplication. Devrait être un morceau de gâteau!

La documentation MySQL est fantastique : http://dev.mysql.com/doc/refman/5.0/en/replication.html

Je ne suis pas sûr de pouvoir limiter l'utilisation de la mémoire par base de données

Bien sûr, vous pouvez - vous avez juste besoin d'exécuter l'esclave avec un autre /etc/my.cnf

Vous pouvez même faire des choses pour manipuler la priorité de planification / l'affinité CPU sur le maître et l'esclave en utilisant nice / renice et tasket (en supposant que c'est un serveur Linux).

mais la réplication aurait lieu sur Internet et le ping est ~ 220 ms

La latence est à peu près hors de propos - l'important est la bande passante - et la bande passante de la base de données (en supposant que vous ne répliquez pas les données de session) est de plusieurs ordres de grandeur inférieure à la bande passante HTTP.

J'ai besoin de [créer une sauvegarde cohérente de la base de données] (de préférence toutes les 4 heures) sans temps d'arrêt

Mais les stratégies dont vous discutez ne permettent pas de récupération à un moment pareil.

Je pense que l'option la moins chère serait un esclave sur la même machine - et si cela affecte négativement les performances au-delà de ce que vous pouvez reconfigurer, mettez à niveau le package d'hébergement actuel.

Vous pouvez également envisager d'exécuter un esclave déconnecté: activez les journaux bin sur le serveur actuel. Obtenez une sauvegarde, restaurez la sauvegarde sur une machine locale, puis copiez les journaux de bacs au fur et à mesure de leur rotation et faites-les avancer sur le SGBD local .

Ma suggestion:

1 - conservez votre deuxième compte / serveur et implémentez la réplication vers une base de données dans votre compte / serveur d'origine.

2 - arrêtez la réplication sur le deuxième compte / serveur.

3 - surveiller les performances pendant quelques jours. Assurez-vous de le surveiller suffisamment longtemps pour inclure vos périodes les plus occupées.

4 - soyez prêt à passer à votre ancienne configuration en cas de problème majeur de performances. C'est la raison pour laquelle vous avez conservé le deuxième compte.

5 - Achetez plus de capacité / serveur de mise à niveau dans votre compte d'origine. Cela devrait être moins cher que de payer pour deux serveurs, je crois.

6 - annuler le deuxième compte.

Bonne chance!