OVH Community, votre nouvel espace communautaire.

Réplication MySQL ou Rsync


Math33
26/06/2014, 16h16
J'ai eu quelques soucis de synchro/resynchro et pour le coup je suis aussi passé sur xtrabackup-v2, ça semble en effet bien plus fluide

starouille
26/06/2014, 16h02
Citation Envoyé par Math33
Ah tiens jamais fait attention à la SST, toujours utilisé Rsync de mon côté. De réelles différences ?

Sinon +1 avec starouille, dès qu'il y a du MyISAM Galera n'est plus opérant et ce moteur n'est par nature pas fait pour du cluster donc à oublier (malgré l'intégration expérimentale).

Après en soi passer des tables MyISAM en InnoDB est bien souvent assez simple et sans risque, au pire ça demande quelques modifications (certes bloquantes mais à moins de travailler sur des tables gigantesques ça se fait bien en heure creuse) et tests.
En général ça se passe sans problème, après, ça peut poser des problèmes de perfs selon l'usage... et certains incompatibilités (des index qui ne passent plus sur certains type de champs etc..). Mais bon rien de méchant.

j'ai commencé en rsync puis xtrabackup puis xtrabackup-v2.. l'avantage, c'est que t'as rien de bloquant lors qu'un synchro..

En rsync, même le noeud qui passe en "DONOR" est indispo. .. ça fait deux noeuds indispo pendant SST.

Ils ont grandement amélioré les perfs via la version 2 d'xtrabackup aussi. Y'a des buffers et tout, ça semble ultra robuste, encore plus qu'avant.

stormyboy
26/06/2014, 15h08
J'ai finalement mis en place une solution très classique master/ slave en restant en myisam, tout fonctionne très bien et ca me suffit pour l'instant. Je verrai + tard pour passer un cran au dessus, j'ai d'autres priorités... merci

Math33
18/06/2014, 00h42
Ah tiens jamais fait attention à la SST, toujours utilisé Rsync de mon côté. De réelles différences ?

Sinon +1 avec starouille, dès qu'il y a du MyISAM Galera n'est plus opérant et ce moteur n'est par nature pas fait pour du cluster donc à oublier (malgré l'intégration expérimentale).

Après en soi passer des tables MyISAM en InnoDB est bien souvent assez simple et sans risque, au pire ça demande quelques modifications (certes bloquantes mais à moins de travailler sur des tables gigantesques ça se fait bien en heure creuse) et tests.

starouille
17/06/2014, 20h07
J'ai déjà proposé Galera plus haut. Vu qu'il du MyIsam, c'est adieu Galera cluster (MyIsam est en expérimental et ne sera jamais vraiment supporté à priori).

Clustercontrol apporte une interface graphique un peu useless. L'intall de galera cluster (sans tuning), c'est un apt-get install (sous debian), et juste préciser 2-3 param dans le my.cnf.

Après ça dépend de la synchro que tu prends (xtrabackup-v2 est au top, :-))

Dga
17/06/2014, 10h36
Citation Envoyé par TBC_Ly0n
Là, Dga, tu me vends du rêve
C'est possible je l'utilise pas en production encore, c'est en test sur notre PCC et on en parle sur la ML PCC
L'installation est vraiment très simple et ça tourne bien.

Sysbench avec haproxy + 3 masters Galera, exécuté depuis une vm apache/php
J'utilise 5 VMs sur 2 hosts M intel du PCC :
sysbench --test=oltp --oltp-table-size=1000000 --oltp-test-mode=complex --oltp-read-only=off --num-threads=6 --max-time=60 --max-requests=0 --mysql-db=dbtest --mysql-host=10.19.87.31 --mysql-user=haproxy_root --mysql-password=........ run
sysbench 0.4.12: multi-threaded system evaluation benchmark

No DB drivers specified, using mysql
Running the test with following options:
Number of threads: 6

Doing OLTP test.
Running mixed OLTP test
Using Special distribution (12 iterations, 1 pct of values are returned in 75 pct cases)
Using "BEGIN" for starting transactions
Using auto_inc on the id column
Threads started!
Time limit exceeded, exiting...
(last message repeated 5 times)
Done.

OLTP test statistics:
queries performed:
read: 281694
write: 100604
other: 40242
total: 422540
transactions: 20112 (335.14 per sec.)
deadlocks: 13 (0.22 per sec.)
read/write requests: 382298 (6370.51 per sec.)
other operations: 40242 (670.58 per sec.)

Test execution summary:
total time: 60.0106s
total number of events: 20112
total time taken by event execution: 359.9543
per-request statistics:
min: 8.48ms
avg: 17.90ms
max: 339.72ms
approx. 95 percentile: 36.74ms

Threads fairness:
events (avg/stddev): 3352.0000/51.07
execution time (avg/stddev): 59.9924/0.00
La même sur un SP 2013 E3-1245 V2 @ 3.40GHz
Mysql en local et disque à 7200/min en raid1
sysbench 0.4.12: multi-threaded system evaluation benchmark

No DB drivers specified, using mysql
Running the test with following options:
Number of threads: 6

Doing OLTP test.
Running mixed OLTP test
Using Special distribution (12 iterations, 1 pct of values are returned in 75 pct cases)
Using "BEGIN" for starting transactions
Using auto_inc on the id column
Threads started!
Time limit exceeded, exiting...
(last message repeated 5 times)
Done.

OLTP test statistics:
queries performed:
read: 39844
write: 14230
other: 5692
total: 59766
transactions: 2846 (47.35 per sec.)
deadlocks: 0 (0.00 per sec.)
read/write requests: 54074 (899.64 per sec.)
other operations: 5692 (94.70 per sec.)

Test execution summary:
total time: 60.1060s
total number of events: 2846
total time taken by event execution: 360.4905
per-request statistics:
min: 38.48ms
avg: 126.67ms
max: 960.01ms
approx. 95 percentile: 243.44ms

Threads fairness:
events (avg/stddev): 474.3333/3.99
execution time (avg/stddev): 60.0818/0.02

TBC_Ly0n
17/06/2014, 10h06
Là, Dga, tu me vends du rêve

Dga
17/06/2014, 09h36
Tu as le cluster Galera géré avec clustercontrol, il te faut 4 serveurs mini par contre (OS Vierge)
3 masters MySQL et 1 serveur avec clustercontrol (version community, gratuite).

Avec leur configurateur, tu as ton cluster opérationnel en 10 minutes (http://www.severalnines.com/New-Gale...tor/index.html) tu renseignes les IP des 3 master et du clustercontrol, tu ajoutes ta clé SSH et leur script installe le tout sur les 4 machines, si tu veux ajouter un master au cluster, il te suffira juste de renseigner l'ip depuis l'interface web de clustercontrol et d'ajouter la clé SSH sur la machine et il installera tout et synchronisera les différentes DB.

L'avantage c'est que tu as une synchro sur les 3 masters et tu peux répartir la charge sur ces 3 masters avec haproxy (par exemple, clustercontrol peut te l'installer), par contre si tu as beaucoup de write il faut mieux dédié un master à cette tache pour éviter quelques soucis de synchro.

C'est magique cette solution je trouve

TBC_Ly0n
16/06/2014, 10h03
show slave status

stormyboy
15/06/2014, 16h52
je n'ai pas le temps en ce moment pour changer vers innodb, ma priorité est plutot de mettre en service définitivement le serveur de secours avec donc plutot une solution de réplication plus standard, je verrai plus tard...

J'ai mis en place une réplication master/master, mais les données insérées/delete/update sur le principal ne le sont pas sur le secours.
Sur le master j'ai notamment fait
grant replication slave, replication client on *.* to repl@"ip_secours" identified by "pass";

puis CHANGE MASTER TO MASTER_HOST='ip_secours', MASTER_PORT=3306, MASTER_USER='repl', MASTER_PASSWORD='pass';

idem sur le secours avec l'ip principal.

Dans les my.cnf j'ai activé les lignes
server-id = 1 (et 2)
log-bin
binlog-do-db bases concernées
replicate-do-db bases concernées

start slave; etc...

mais pas moyen d'avoir les modifs sur le serveur secours. Si on pouvait m'éclairer sur cette méthode ca m'aiderait bien, merci

starouille
15/06/2014, 11h56
Citation Envoyé par stormyboy
Ok je découvre ca...
ca fonctionne avec myisam?
Sur les tuto ca parle tjrs de minimum 3 "nodes", dans mon cas je n'en ai que 2.
Yep faut idéalement trois nodes (même si deux sont sur le même serveur au pire). C'est pas une limitation technique, c'est pour le Quorum car c'est du master/master. Mais rien ne t'empêche d'en avoir deux et de bloquer la synchro dans un sens (pour éviter une synchro dans le mauvais sens en cas de split brain).

Faut migrer vers InnoDB effectivement

stormyboy
15/06/2014, 02h05
Ok je découvre ca...
ca fonctionne avec myisam?
Sur les tuto ca parle tjrs de minimum 3 "nodes", dans mon cas je n'en ai que 2.

starouille
15/06/2014, 01h45
En 2014, utilise Galera Cluster (sorti en version finale début 2013).

Fonce, tu vas voir comme c'est simple et que ça fonctionne bien...

stormyboy
14/06/2014, 01h43
Bonjour,
Je déterre ce sujet car je cherche des infos justement. Je veux mettre en place un serveur de secours avec IPFO, mon site devient en effet de + en + important et pour moi il serait dommageable qu'une panne x s'attarde trop longtemps sur le serveur principal actuel (EG64 SSD de 2013).

J'ai vu ceci http://www.it-connect.fr/replication...ysql%EF%BB%BF/

Est ce que cette solution est du genre à bouffer pas mal de ram ou espace disque ou cpu? Le site fait parfois 2000 connectés en live (analytics) et j'ai des tables de plusieurs Go pour certaines.
Certaines tables sont fixes et ne sont pas appelées à être modifiées, possible de les zapper de la réplication?
Quid en cas de reboot d'un des 2 serveurs? Sur le slave il faut entrer le fichier binaire + position, s'il le master est rebooté est ce que ces infos changent?

Loup Artic
06/01/2011, 22h00
La taille en ram de MySQL dépend d'une grosse optimisation de la et surtout de ta/tes bases.
J'ai un peu moins de 2400 bases pour 20 go, le process mysql tire entre 1,8 à 2,5Go de ram et a priori ca Qcache bien.
Après tu peux avoir une base de 4 ou 5Go qui va demander un max de ram. Ca dépend beaucoup de ton utilisation sur le long terme.

Colette
06/01/2011, 21h36
Merci beaucoup pour tous ces conseils, cela m'est très utile.

jwhosting
06/01/2011, 21h21
Hello,
Une distro de 32 bits ne sait gérer que 4Go de Ram (2^32)
Tu dois donc absolument avoir du 64 bits.
Ton dump risque de prendre un tout petit peu de temps, donc à ta place j'en ferai un toutes les nuits sur le master et plus régulièrement sur le slave tout en monitorant la réplication
Le dump nécessite de faire des LOCK, donc sur ton master en fonction de ton projet ça peut être gênant (ou pas)
Tu n'auras à mon avis pas de gain si tu passes de 12 à 24Go de Ram. Tu pourras augmenter le query cache et tout, mais je vois mal comment tu peux rentabiliser 24Go de ram.

Colette
06/01/2011, 19h30
La soluce de jwhosting me semble pas mal du tout (sauf si je me trompe : réplication Mysql Maître => Esclave avec en plus des Dumps complets sur Esclave). Par prudence, je me verrai bien faire des Dumps (3/4 par jour) en plus sur le Maître, au cas où la réplication Mysql n'aurait pas fonctionné.

J'ai donc une nouvelle question : pour sauvegarder ma base de données qui tourne aux alentours de 1,5 GO non compressée, avec la méthode mysqldump, est-ce qu'il est plus intéressant de prendre un serveur MG avec 24GO RAM qu'un EG avec 12GO RAM ? En clair, est-ce qu'un MG avec 24GO de RAM permettra de faire les Dumps plus rapidement ? Et avez-vous aussi une idée du temps que ça pourra prendre ? Autre question (je sors un peu du sujet là), est-ce qu'il faut absolument une distrib. 64 bits pour profiter vraiment de toute cette RAM ? Merci encore

jwhosting
05/01/2011, 17h44
Tu peux faire un master/slave avec le slave promu master en cas de down du master.
et en temps normal faire tes backups depuis le slave

TBC_Ly0n
05/01/2011, 17h30
Pas de rsync sur une base Mysql à chaud.
Soit tu utilises un snapshot LVM (avec un flush tables with read lock), soit tu utilises autre chose.

Au risque de me répéter, la réplication n'est pas un mécanisme de sauvegarde. C'est l'équivalent d'un RAID... Si tu fais un rm sur tes données, tu n'as plus de données.

Loup Artic
05/01/2011, 17h23
Oubli rsync, c'est pas un outil fait pour ce genre d'utilisation.
A moins que tu souhaites down ton mysql le temps de la copie via rsync, ce dont je doute. Rsync n'est qu'un outil pour sync des fichiers. Hors sync ton répertoire des bases de mysql à chaud cassera tout.

TBC_Ly0n est le grand pro des solutions MySQL, à lui de parler .

Colette
05/01/2011, 16h39
En fait, c'est plutôt de la haute dispo et puis un peu de sauvegarde quand même. Je m'explique : ma base comprend les données d'articles et surtout d'un forum de discussions. Si mon serveur crame intégralement (avec les 2 disques durs), je souhaite pouvoir remettre en ligne mon site rapidement avec toutes les données du forum sur un serveur temporaire (un peu moins gros, genre Kimsufi, qui servira le temps de retrouver mon serveur principal réparé par l'équipe OVH). Je sais basculer sur un serveur de secours avec une IPFailover et j'ai déjà pu mettre en place la réplication Mysql (en test), mais je me demandais si cette solution est vraiment fiable et si l'utilisation se Rsync (que je ne maîtrise pas du tout actuellement ) serait plus adaptée. Est-ce vous pouvez me donner votre avis là-dessus ?

jwhosting
05/01/2011, 14h25
Tu peux faire un mysqlhotcopy périodiquement mais ça loque les tables le temps de la copie.
Si tu veux éviter cela, tu peux effectivement mettre un slave SQL et faire des backups très réguliers à partir du slave
mais cela suppose que tu monitoes continuellement la réplication, car si pour une raison ou pour une autre elle saute, tes backups ne seront pas à jour
Bref, il y a plusieurs solutions envisageables, tout dépend de tes besoins.

TBC_Ly0n
05/01/2011, 13h30
1 - Une réplication n'est pas une sauvegarde. Un truncate sera fidèle répliqué de l'autre coté. Tu veux améliorer ta dispo ou faire une sauvegarde ?
2 - Les fichiers ne peuvent pas être copiés à chaud, ils sont incohérents
3 - Ce qu'il est possible de faire est des snapshots LVM par mylvmbackup et récupérer les logs binaires sur une autre machine. Là, on aura une vraie sauvegarde.

Colette
05/01/2011, 12h47
Bonjour,
J'ai besoin de sauvegarder ma base de données en temps réels sur un serveur de secours. Entre utiliser la Réplication MySQL (http://dev.mysql.com/doc/refman/5.0/fr/replication.html) ou RSync, laquelle de ces 2 solutions vous semble la mieux adaptée ? Quelles sont les différences et les atouts de chacune ? Merci