organiser un backup régulier vers l'ancien serveur

[Fil]

appelé en cron chaque nuit sur alan /var/shim/BASE/backup.sh

il se connecte en ssh et utilise le mot de passe mysql défini dans le .my.cnf de l'utilisateur toto

#! /bin/bash

tables="spip_me_block spip_mots_articles spip_articles spip_me_follow_mot spip_mots_breves spip_auteurs_articles spip_me_follow spip_mots_documents spip_me_follow_tag spip_me_follow_url spip_auteurs spip_me_mot spip_mots spip_breves spip_documents_liens spip_me_share spip_oc_uri spip_urls spip_documents spip_me spip_me_tags spip_meta spip_rubriques spip_me_auteur spip_me_texte"

for i in $tables; do
    echo $i
    ssh toto@server "mysqldump --opt -uUSER BASE "$i | gzip - > "/var/shim/BASE/backup/$i.sql.gz"
    sleep 10
done

[brunob]

Reporté dans le wiki https://github.com/seenthis/hebergement/wiki/Backup-depuis-alan

[tech-nova]

Pour info cela crée des requêtes super longues de type

# Time: 2016-07-02T21:18:38.672241Z
# User@Host: seenthis[seenthis] @ localhost []  Id: 143372
# Schema: seenthis  Last_errno: 0  Killed: 0
# Query_time: 37.422769  Lock_time: 0.000000  Rows_sent: 494497  Rows_examined: 494497  Rows_affected: 0
# Bytes_sent: 332264523
SET timestamp=1467494318;
SELECT /*!40001 SQL_NO_CACHE */ * FROM `spip_me_texte`;

il faudrait soit faire des backups depuis une base slave en read-only, soit utiliser une solution de backup plus aboutie. Percona propose une solution open source gratuite qui semble recommandée : https://www.percona.com/doc/percona-xtrabackup/2.4/index.html

• Create hot InnoDB backups without pausing your database
• Make incremental backups of MySQL
• Stream compressed MySQL backups to another server
• Move tables between MySQL servers on-line
• Create new MySQL replication slaves easily
• Backup MySQL without adding load to the server

[Fil]

Ah oui il suffirait sans doute d'ajouter nô lock tables pour que ce pose pas de problème. Pour les solutions plus compliquées bof car la maintenance doit rester simple

On Sunday, July 3, 2016, tech-nova notifications@github.com wrote:

Pour info cela crée des requêtes super longues de type

Time: 2016-07-02T21:18:38.672241Z

User@Host: seenthis[seenthis] @ localhost [] Id: 143372

Schema: seenthis Last_errno: 0 Killed: 0

Query_time: 37.422769 Lock_time: 0.000000 Rows_sent: 494497 Rows_examined: 494497 Rows_affected: 0

Bytes_sent: 332264523

SET timestamp=1467494318; SELECT /!40001 SQL_NO_CACHE / * FROM spip_me_texte;

il faudrait soit faire des backups depuis une base slave en read-only, soit utiliser une solution de backup plus aboutie. Percona propose une solution open source gratuite qui semble recommandée : https://www.percona.com/doc/percona-xtrabackup/2.4/index.html

• Create hot InnoDB backups without pausing your database
• Make incremental backups of MySQL
• Stream compressed MySQL backups to another server
• Move tables between MySQL servers on-line
• Create new MySQL replication slaves easily
• Backup MySQL without adding load to the server

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/seenthis/hebergement/issues/4#issuecomment-230157264, or mute the thread https://github.com/notifications/unsubscribe/AAAbWTGsZdnHChsVHKVARHelqqRRiUl3ks5qR8yugaJpZM4JDPAW .

-- Fil

[tech-nova]

Non, le problème à régler c'est surtout la durée des requêtes. En faisant un backup table par table, on n'est pas certain d'avoir un ensemble cohérent pour une restauration. Maintenant, ce n'est peut-être pas une grande contrainte pour seenthis.

[Fil]

Non, surtout à 4h du mat, où le risque est encore plus faible. L'idée ici c'est de pouvoir repartir en cas de crash majeur chez toi, c'est tout. J'ai rajouté --lock-table=false --quick et on regarde si ça te va ?

(Je n'ai rien contre le fait d'avoir de meilleurs outils mais je crois que comme ça c'est déjà pas mal.)

[tech-nova]

Remarques, tant que ça tourne, ça me va très bien :)

2016-07-03 18:15 GMT+02:00 Fil notifications@github.com:

Non, surtout à 4h du mat, où le risque est encore plus faible. L'idée ici c'est de pouvoir repartir en cas de crash majeur chez toi, c'est tout. J'ai rajouté --lock-table=false --quick et on regarde si ça te va ?

(Je n'ai rien contre le fait d'avoir de meilleurs outils mais je crois que comme ça c'est déjà pas mal.)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/seenthis/hebergement/issues/4#issuecomment-230161212, or mute the thread https://github.com/notifications/unsubscribe/AAkoj7SOFWKDfvsoHlJkczWebBrWXA0Lks5qR-AUgaJpZM4JDPAW .

[Fil]

--lock-table=false ne marche pas, je l'ai enlevé mais il faudrait trouver la bonne syntaxe

[brunob]

@Fil le --lock-tables=false ne passe peut-être pas à cause du --opt cf : https://dev.mysql.com/doc/refman/5.6/en/mysqldump.html#mysqldump-option-groups

Du coup --skip-lock-tables semble être la bonne option cf https://dev.mysql.com/doc/refman/5.6/en/mysqldump.html#option_mysqldump_lock-tables

[Fil]

j'ai ajouté l'option --skip-lock-tables dans mon script et il n'a pas l'air de couiner. Merci mignon !

[brunob]

Cool, de rien, @tech-nova devrait pouvoir nous dire si ça améliore les perfs du backup.