MySQL slave maken of repareren met innobackupex

Door Heli0s op woensdag 29 juni 2016 17:45 - Reacties (3)
Categorie: -, Views: 764

Het is enige tijd geleden dat ik wat gepost heb, maar het was wat druk in huize heli0s. Tussen werk school en een tweeling had ik niet veel tijd meer over. Maar nu de 'vakantie' is begonnen heb ik wat meer tijd. In de hoop dat ik iemand kan helpen hierbij een post over mysql slaves.

Op de zaak draaien wij Percona, maar op MySQL werkt het ook, met een slave database. Voorheen starten wij een slave met mysqldump, maar dat locked de database. Als dus de slave kapot gaat, moet je wachten tot buiten kantoor uren om de slave te repareren. Dat is natuurlijk niet alleen vervelend, maar je zult altijd zien dat dan net je master ook de geest geeft.

Met Perconna innobackupex kan je een hot-backup maken van je database. Innobackupex is een Perl wrapper om xtrabackup en is afgeleid van innobackup van Oracle.

Op de Master
Draai op de master innobackupex om een backup te maken van de master. Dit kan gewoon overdag omdat innobackupex de database niet locked.

code:
1
TheMaster$ innobackupex --user=yourDBuser --password=MaGiCdB1 /path/to/backupdir


Na het maken van een backup moet het query log wat gemaakt word tijdens backup 'afgespeeld' worden over de backup:

code:
1
TheMaster$ innobackupex --user=yourDBuser --password=MaGiCdB1 --apply-log /path/to/backupdir/$TIMESTAMP/


rsync nu de backup naar de slave server.

Op de Slave
Stop mysql: /etc/init.d/mysql stop

Verplaats /var/lib/mysql naar /var/lib/mysql_old/

Verplaats of kopieer de backup naar /var/lib/mysql/

zet de rechten goed op de mysql dir:

code:
1
chown -R mysql:mysql /var/lib/mysql


start mysql weer

zet de slave settings nu goed, master_log_file en master_log_position staan in de xtrabackup_binlog_info file in de backup dir

code:
1
2
3
4
5
6
CHANGE MASTER TO
     MASTER_HOST='$master_ip',                  
     MASTER_USER='$repl_user',
     MASTER_PASSWORD='$password',            
     MASTER_LOG_FILE='mysql-bin.001345',                  
     MASTER_LOG_POS=455974220;


mocht je het password van de slave user niet meer weten kan je deze goed zetten op de master met:

code:
1
GRANT REPLICATION SLAVE ON *.*  TO '$repl_user'@'1$slave_ip' IDENTIFIED BY '$password';


start nu de slave met: START SLAVE;
je kan dan met SHOW SLAVE STATUS\G; controleren of de slave draait:

code:
1
2
Slave_IO_Running: Yes
Slave_SQL_Running: Yes


als deze alletwee op Yes staan dan is alles ok en heb je een werkende slave.

Volgende: Configuration Managment met Ansible 02-'15 Configuration Managment met Ansible

Reacties


Door Tweakers user analog_, donderdag 30 juni 2016 23:52

--single-transaction? edit: heeft edge-cases precies.

[Reactie gewijzigd op donderdag 30 juni 2016 23:57]


Door Tweakers user sfranken, vrijdag 1 juli 2016 00:48

hmm, /etc/init.d/ .. Tijd om eens te upgraden naar een modern OS? Sysvinit(/upstart) is oud, en de OS'en waar dit op draait (CentOS 5.x) ook. Of draait dit op RHEL? En zo ja: zijn die nog niet over op systemd?

Door Tweakers user Heli0s, vrijdag 1 juli 2016 09:44

sfranken schreef op vrijdag 01 juli 2016 @ 00:48:
hmm, /etc/init.d/ .. Tijd om eens te upgraden naar een modern OS? Sysvinit(/upstart) is oud, en de OS'en waar dit op draait (CentOS 5.x) ook. Of draait dit op RHEL? En zo ja: zijn die nog niet over op systemd?
Ik wil niet een hele flame war beginnen over SysV init vs Systemd, maar het is nogal een aanname dat we een oud OS draaien omdat we nog SysV init gebruiken. Daar naast zijn er nog heel veel andere Linux distros dan CentOS of RHEL.

Reageren is niet meer mogelijk