Das Problem war recht Simpel, ein MySQL Server Paar in einer Master-Master Replikation braucht ein Backup. Leider reicht der Festplattenplatz auf beiden Servern nicht mehr aus um dieses laufen zu lassen.
Also musste ein Slave mit mehr Plattenplatz an das paar gehangen werden um auf diesem die Backups zu fahren. Aber das System steht unter Dampf, ist Produktiv und darf nicht runtergefahren werden.
Hier hilft jetzt das wunderbare percona xtrabackup (welches eigentlich in jedem professionellem Umfeld genutzt werden sollte). Es bietet die Option --stream=tar an, welche es ebenfalls ermöglicht via ssh bzw. nc auf einen anderen host zu sichern und ganz wichtig, dabei konsistent zu sein.
Damit das Backup auch richtig schnell ist, also via netcat auf einen anderen Server, das schaut dann wie folgt aus:
innobackupex --defaults-file=/etc/my.cnf --no-timestamp
--ibbackup=xtrabackup_51 --slave-info --socket=/data/mysql.sock
--stream=tar ./ | nc ZielSystem 9999
Natürlich muss vorher auf dem Zielsystem noch ein netcat lauschen um das ganze entgegen zu nehmen.
nc -l -p 9999 | cat - > /data/temp/backup.tar
Wenn das ganze gelaufen ist, sendet xtrabackup ein Backup OK und nach beenden der beiden netcat Prozessen auf den Systemen kann es weiter gehen mit dem vorbereiten des Backups. Das tar auf dem Zielsystem kann jetzt entpackt (tar -ixvf backup.tar) werden und das Backup muss vorbereitet werden.
innobackupex --defaults-file=/etc/my.cnf --apply-log
--ibbackup=xtrabackup_51 /data/
Wenn das ganze durchgelaufen ist, muss evtl. noch etwas an den rechten des Verzeichnisses geändert werden chown -R mysql. /data und danach kann der MySQL Server hochgefahren werden.
Davon Abhängig an welchen der beiden Server man sich hängen will, findet sich entweder in der xtrabackup_slave_info oder xtrabackup_binlog_pos_innodb die passenden Werte für das CHANGE MASTER TO statement, was genau in welcher steht kann man am besten direkt bei percona nachlesen.
Man kann vieles damit machen, man muss sich nur trauen!