<\/p>\n
Prenons l\u2019exemple d\u2019une installation classique d\u2019eXo Platform, les \u00e9tapes pour effectuer la sauvegarde sont les suivantes :<\/p>\n
- \n
- Stopper eXo Platform;<\/li>\n
- Sauvegarder le r\u00e9pertoire
EXO_DATA_DIR<\/em><\/code>;<\/li>\n- Effectuer un dump sql de la base donn\u00e9es;<\/li>\n
- Relancer eXo Platform.<\/li>\n<\/ul>\n
Cette proc\u00e9dure a l\u2019avantage d\u2019\u00eatre facilement impl\u00e9mentable quelle que soit l\u2019architecture en place mais est d\u00e9pendante du volume de donn\u00e9es \u00e0 sauvegarder.
\nL\u2019\u00e9volution dans le temps de vos dur\u00e9es de sauvegarde et de restauration pourrait alors fortement ressembler au graphique suivant :<\/p>\n![\"Sauvegarde](\"https:\/\/www.exoplatform.com\/blog\/wp-content\/uploads\/2016\/06\/Sauvegarde-et-restauration-1.png\")
<\/a><\/p>\nSelon vos engagements en terme de disponibilit\u00e9, la dur\u00e9e d\u2019interruption peut vite devenir probl\u00e9matique pour une sauvegarde r\u00e9guli\u00e8re.<\/p>\n
Que faire lorsque le volume de donn\u00e9es augmente ?<\/h2>\n
Chaque installation \u00e9tant diff\u00e9rente, il n\u2019existe pas un moyen unique pour am\u00e9liorer vos sauvegardes, mais autant que d\u2019installations. [Appel \u00e0 un consultant en cas de besoin ? ;)]<\/p>\n
Dans la suite de cet article nous allons aborder comment nous avons r\u00e9solu ce probl\u00e8me sur la Tribe eXo<\/a>.
\nCe site communautaire permet \u00e0 qui le souhaite de tester et d’\u00e9changer autour des fonctionnalit\u00e9s d’eXo Platform. Les employ\u00e9s d\u2019eXo Platform l’utilisent \u00e9galement dans le cadre de leur travail quotidien car nous sommes adeptes du dogfooding.
\nL\u2019accroissement du nombre d\u2019utilisateurs enregistr\u00e9s (environ 90 000 aujourd\u2019hui) entra\u00eene une augmentation constante du volume de donn\u00e9es \u00e0 sauvegarder.
\nLa dur\u00e9e de sauvegarde<\/strong> a ainsi pu prendre jusqu\u2019\u00e0 3 heures<\/strong> et la restauration plus d\u2019une journ\u00e9e, d\u00e9lais peu compatibles avec nos engagements de service.<\/p>\nCela nous a oblig\u00e9 \u00e0 revoir notre strat\u00e9gie de sauvegardes.<\/p>\n
L\u2019infrastructure (simplifi\u00e9e) utilis\u00e9e est la suivante:<\/p>\n
- \n
- Infrastructure mono serveur Linux;<\/li>\n
- Base de donn\u00e9es MySQL;<\/li>\n
- Documents sur disque.<\/li>\n<\/ul>\n
Changer de strat\u00e9gie<\/h3>\n
Les bases de donn\u00e9es support\u00e9es par eXo Platform poss\u00e8dent toutes une section relative \u00e0 la sauvegarde dans leur documentation :<\/p>\n
- \n
- MySQL : http:\/\/dev.mysql.com\/doc\/refman\/5.7\/en\/backup-and-recovery.html<\/a><\/li>\n
- PostreSQL : https:\/\/www.postgresql.org\/docs\/9.1\/static\/backup.html<\/a><\/li>\n
- Oracle : http:\/\/docs.oracle.com\/database\/121\/BRADV\/toc.htm<\/a><\/li>\n
- SQLServer : https:\/\/msdn.microsoft.com\/en-us\/library\/ms187510.aspx<\/a><\/li>\n<\/ul>\n
La m\u00e9thode choisie d\u00e9pendra de votre architecture et de vos priorit\u00e9s.<\/p>\n
Pour MySQL, le tableau suivant r\u00e9sume les diff\u00e9rentes possibilit\u00e9s :<\/p>\n
![\"2\"](\"https:\/\/www.exoplatform.com\/blog\/wp-content\/uploads\/2016\/06\/2.png\")
<\/a><\/p>\nPour eXo Tribe<\/strong>, notre priorit\u00e9 \u00e9tant de minimiser le d\u00e9lai d\u2019interruption ainsi que le temps de restauration<\/strong>, la combinaison Physique\/Online\/Snapshot est id\u00e9ale.<\/p>\n
Le snapshot permettant de garder une image d\u2019un syst\u00e8me de fichier prise \u00e0 un instant T tout en autorisant sa modification en parall\u00e8le, nous pouvons alors effectuer la sauvegarde de la mani\u00e8re suivante :<\/p>\n
- \n
- Arr\u00eat d\u2019eXo Platform;<\/li>\n
- Snapshot de la base de donn\u00e9es et des donn\u00e9es d\u2019eXo Platform;<\/li>\n
- Red\u00e9marrage d\u2019eXo Platform;<\/li>\n
- Copie et sauvegarde des donn\u00e9es depuis le snapshot;<\/li>\n
- Suppression du snapshot.<\/li>\n<\/ul>\n
L\u2019impl\u00e9mentation<\/h3>\n
Puisque chez eXo Platform, LVM (Logical Volume Manager<\/a>) est utilis\u00e9 sur l\u2019ensemble de nos serveurs pour g\u00e9rer nos volumes disques, nous l\u2019avons naturellement choisi pour la gestion des snapshots.<\/p>\n
La commande
lvscan<\/em><\/code> permet d\u2019afficher les volumes logiques d\u2019un syst\u00e8me :<\/p>\n# lvscan\n...\n ACTIVE '\/dev\/vg\/lvsrv' [1.64 TiB] inherit\n...\n<\/pre>\n
Dans notre cas, nous souhaitons effectuer un snapshot du volume
\/dev\/vg\/lvsrv<\/em><\/code>.
\nSa cr\u00e9ation sera instantan\u00e9e mais il faudra r\u00e9server un espace au moins aussi important que la taille des \u00e9critures qui seront faites pendant son existence. Si cet espace venait \u00e0 \u00eatre insuffisant, LVM d\u00e9truira le snapshot afin de ne pas p\u00e9naliser le volume principal.
\nLa commandepvscan<\/em><\/code> permet de v\u00e9rifier l\u2019espace disponible :<\/p>\n# pvscan\n PV \/dev\/sda5 VG vg lvm2 [2.00 TiB \/ 300.00 GiB free]\n Total: 1 [2.00 TiB] \/ in use: 1 [2.00 TiB] \/ in no VG: 0 [0 ]<\/pre>\n
Il reste ici 300Go d\u2019espace libre sur notre volume. Nous r\u00e9serverons une taille empirique de 200Go ce qui devrait \u00eatre suffisant par rapport \u00e0 l\u2019activit\u00e9 qui aura lieu pendant le temps de copie des donn\u00e9es.<\/p>\n
# sudo lvcreate -s -L 200G -n lvsrv-snapshot \/dev\/vg\/lvsrv\n Logical volume \"srv-snapshot\" created<\/pre>\n
Si nous affichons de nouveau la liste des volumes, nous constatons l\u2019apparition du volume de snapshot
\/dev\/vg\/srv-snapshot<\/em><\/code> :<\/p>\n# lvscan\n ACTIVE Original '\/dev\/vg\/lvsrv' [1.64 TiB] inherit\n ACTIVE Snapshot '\/dev\/vg\/lvsrv-snapshot' [200.00 GiB] inherit<\/pre>\n
Il peut \u00eatre utilis\u00e9 comme un volume LVM classique, il nous donnera alors acc\u00e8s aux donn\u00e9es du volume
lvsrv<\/em><\/code> au moment de la cr\u00e9ation du snapshot. Nous l\u2019utiliserons en lecture seule afin de s\u2019assurer que les donn\u00e9es ne puissent \u00eatre modifi\u00e9es :<\/p>\n# mkdir \/mnt\/srv-snapshot\n# mount -o ro \/dev\/vg\/lvsrv-snapshot \/mnt\/srv-snapshot<\/pre>\n
Pour v\u00e9rifier \u00e0 tout moment la consommation de l\u2019espace r\u00e9serv\u00e9, nous utiliserons la commande lvs :<\/p>\n
# lvs\n LV VG Attr LSize Pool Origin Data% Move Log Copy% Convert\n lvsrv vg owi-aos-- 1.64t\n lvsrv-snapshot vg swi-aos-- 200.00g lvsrv 2.39<\/pre>\n
2.39% des 200G allou\u00e9s sont utilis\u00e9s, cela nous permet de sauvegarder les donn\u00e9es sans risque de suppression du snapshot.<\/p>\n
Les snapshots et MySQL<\/h4>\n
Avant de cr\u00e9er le snapshot, nous devons nous assurer que MySQL ait bien persist\u00e9 sur le disque toutes ses donn\u00e9es en m\u00e9moire. En proc\u00e9dant ainsi, nous pouvons \u00e9viter un red\u00e9marrage de la base de donn\u00e9es et s\u2019affranchir d\u2019un rechargement des donn\u00e9es depuis le disque.
\nIl faut \u00e9galement s\u2019assurer qu\u2019aucune \u00e9criture ne sera faite au moment de la cr\u00e9ation du snapshot (warm backup<\/a>). Les instructions suivantes permettent cela :<\/p>\n# Ecriture sur le disque et v\u00e9rouillage\nFLUSH TABLES WITH READ LOCK;\n# D\u00e9v\u00e9rouillage\nUNLOCK TABLES;<\/pre>\n
Point important, la session ayant servi \u00e0 cr\u00e9er le verrou doit \u00eatre maintenue ouverte pendant la cr\u00e9ation du snapshot sinon le verrou sera supprim\u00e9. Dans le cadre d\u2019une sauvegarde automatique, l\u2019utilisation d\u2019un tube nomm\u00e9 (ou named pipe<\/a>) permet de r\u00e9soudre ce point :<\/p>\n
# Prepare les instructions sql\ncat << EOF > ${LOCK_CMD}\nSET AUTOCOMMIT=false;\nFLUSH TABLES WITH READ LOCK;\nEOF\n\ncat << EOF > ${UNLOCK_CMD}\nUNLOCK TABLES;\nEXIT;\nEOF\n\n# Cr\u00e9ation du tube nomm\u00e9\nmkfifo ${PIPE_PATH}\n\n# Cr\u00e9ation de la connection \u00e0 mysql\n# Elle restera active pendant la cr\u00e8ation du snapshot\n# pour \u00e9viter la suppression du verrou\ncat ${PIPE_PATH} | mysql &\n\n# V\u00e9rouillage des tables\ncat ${LOCK_CMD} > ${PIPE_PATH}\n\n# Cr\u00e9ation du snapshot\n\u2026\n\n# D\u00e9verouillage des tables et fermeture de la session\ncat ${UNLOCK_CMD} > ${PIPE_PATH}<\/pre>\nRed\u00e9marrage d\u2019eXo platform et copie des donn\u00e9es<\/h3>\n
Une fois le snapshot cr\u00e9\u00e9, le service peut \u00eatre red\u00e9marr\u00e9 et la copie des donn\u00e9es effectu\u00e9e.<\/p>\n
Les prochaines \u00e9tapes seront:<\/p>\n
- \n
- Copie du r\u00e9pertoire de donn\u00e9es mysql;<\/li>\n
- Copie des donn\u00e9es d\u2019eXo Platform;<\/li>\n
- D\u00e9montage du snapshot;<\/li>\n
- Suppression du snapshot.<\/li>\n<\/ul>\n
Et voil\u00e0 ! La sauvegarde est maintenant termin\u00e9e ! Le travail de copie se faisant maintenant en arri\u00e8re plan, application d\u00e9marr\u00e9e, le temps d\u2019interruption se r\u00e9duit au temps de red\u00e9marrage<\/strong> du service quelque soit la taille des donn\u00e9es \u00e0 sauvegarder.<\/p>\n
Pour la Tribe eXo, cela repr\u00e9sente environ 6 minutes<\/strong>. Des am\u00e9liorations arriveront dans la prochaine version 4.4 d\u2019eXo Platform qui devraient permettre de r\u00e9duire encore ce d\u00e9lai.<\/p>\n
D\u2019ici l\u00e0, s\u2019il vous arrive d\u2019\u00eatre dirig\u00e9 vers la page de maintenance du site vers 05:00 UTC, patientez, le service ne tardera pas \u00e0 \u00eatre r\u00e9tabli.<\/p>\n
- PostreSQL : https:\/\/www.postgresql.org\/docs\/9.1\/static\/backup.html<\/a><\/li>\n
- MySQL : http:\/\/dev.mysql.com\/doc\/refman\/5.7\/en\/backup-and-recovery.html<\/a><\/li>\n
![\"Rejoignez](\"https:\/\/www.exoplatform.com\/blog\/wp-content\/uploads\/2016\/02\/tribe.png\")
<\/div>\n