Debian Wheezy - Problem mit der Replikation der SQL Datenbanken

mrzs2k · 27. Juni 2013

Hallo allerseits!

Habe mich letzte Woche eine 6-Monats Subscription bei Howtoforge.com gegönnt und bin von den Inhalten, HowTo's und Lösungen absolut begeistert.
So habe ich für mein neues Zukunftsprojekt mit ISPConfig 3 jetzt auch das dazu passende Manual.

Habe bereits vor einem Jahr - mit Hilfe meines eigenen wissen und auch dort schon mit dem einen oder anderen Lösungsvorschlag 2 redundante Webserver aufgesetzt, die bis heute stabil und problemlos laufen (allerdings ohne Frontend bzw. ISPConfig)

Jetzt - aufgrund der Veröffentlichung von Debian Wheezy möchte ich natürlich noch einen weiteren schritt wagen - scheitere aber bereits bei den vorbereitenden Schritten.

Grundsätzlich spreche ich vorerst mal von den 2 redundanten Webservern mit den replizierten SQL Datenbanken:

Mein Aufbau ähnelt in diesem Bereich grundsätzlich folgendem Tutorial:
HowtoForge Linux Tutorials » Installation eines Web, E-Mail & MySQL Datenbank Clusters unter Debian 6.0 mit ISPConfig 3

Ich bereite die my.cnf für die Replikation vor, wie auf Seite 2 beschrieben. Nach dem Stoppen und Starten des MySQL Servers erhalte ich aber immer
"Starting MySQL database server: mysqld . . . . . . . . . . . . . . failed!"

Syslog:
Jun 27 18:12:59 web1 mysqld_safe: Starting mysqld daemon with databases from /var/lib/mysql
Jun 27 18:12:59 web1 mysqld: 130627 18:12:59 [Note] Plugin 'FEDERATED' is disabled.
Jun 27 18:12:59 web1 mysqld: 130627 18:12:59 InnoDB: The InnoDB memory heap is disabled
Jun 27 18:12:59 web1 mysqld: 130627 18:12:59 InnoDB: Mutexes and rw_locks use GCC atomic builtins
Jun 27 18:12:59 web1 mysqld: 130627 18:12:59 InnoDB: Compressed tables use zlib 1.2.7
Jun 27 18:12:59 web1 mysqld: 130627 18:12:59 InnoDB: Using Linux native AIO
Jun 27 18:12:59 web1 mysqld: 130627 18:12:59 InnoDB: Initializing buffer pool, size = 128.0M
Jun 27 18:12:59 web1 mysqld: 130627 18:12:59 InnoDB: Completed initialization of buffer pool
Jun 27 18:12:59 web1 mysqld: 130627 18:12:59 InnoDB: highest supported file format is Barracuda.
Jun 27 18:12:59 web1 mysqld: 130627 18:12:59 InnoDB: Waiting for the background threads to start
Jun 27 18:13:00 web1 mysqld: 130627 18:13:00 InnoDB: 5.5.31 started; log sequence number 1595685
Jun 27 18:13:00 web1 mysqld: 130627 18:13:00 [ERROR] /usr/sbin/mysqld: unknown variable 'master-host=10.0.0.2'
Jun 27 18:13:00 web1 mysqld: 130627 18:13:00 [ERROR] Aborting
Jun 27 18:13:00 web1 mysqld:
Jun 27 18:13:00 web1 mysqld: 130627 18:13:00 InnoDB: Starting shutdown...
Jun 27 18:13:01 web1 mysqld: 130627 18:13:01 InnoDB: Shutdown completed; log sequence number 1595685
Jun 27 18:13:01 web1 mysqld: 130627 18:13:01 [Note] /usr/sbin/mysqld: Shutdown complete
Jun 27 18:13:01 web1 mysqld:
Jun 27 18:13:01 web1 mysqld_safe: mysqld from pid file /var/run/mysqld/mysqld.pid ended
Jun 27 18:13:13 web1 /etc/init.d/mysql[7231]: 0 processes alive and '/usr/bin/mysqladmin --defaults-file=/etc/mysql/debian.cnf ping' resulted in
Jun 27 18:13:13 web1 /etc/init.d/mysql[7231]: #007/usr/bin/mysqladmin: connect to server at 'localhost' failed
Jun 27 18:13:13 web1 /etc/init.d/mysql[7231]: error: 'Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)'
Jun 27 18:13:13 web1 /etc/init.d/mysql[7231]: Check that mysqld is running and that the socket: '/var/run/mysqld/mysqld.sock' exists!
Jun 27 18:13:13 web1 /etc/init.d/mysql[7231]:

Bei Debian Squeeze hatte ich aber an dieser Stelle mehr oder weniger keine Probleme...

Kennt das Problem wer?

Danke für eure Antworten!

Le-Seaw · 27. Juni 2013

[ERROR] /usr/sbin/mysqld: unknown variable 'master-host=10.0.0.2'

How to configure MySQL 5.5 Server as Replication Slave: | Tapas Mishra
http://www.linuxdict.com/2012-01-mysqld-unknown-variable-master-host/

florian030 · 29. Juni 2013

Ich würde sämtliche Werte für die Replikation nicht direkt in die Config schreiben, sondern durch

Code:

CHANGE MASTER TO MASTER_HOST='127.0.0.1', MASTER_PORT=3307, MASTER_LOG_FILE='xxx', MASTER_LOG_POS=4711; MASTER_USER='user, MASTER_PASSWORD='password'

... übergeben.

mrzs2k · 3. Juli 2013

Danke für eure schnellen Antworten - war jetzt allerdings spontan ein paar Tage weg - sorry!

Habs mit oben-stehenden Links und diversen anderen Inhalten aus der MySQL 5.5 Dokumentation dann endlich geschafft.

Arbeite an einem Multiserver Setup - allerdings nicht wie im Tutorial beschrieben, sondern zusätzlich mit völlig redundanten Webservern (Da kommen wieder Inhalte vom Cluster-Tutorial vor

Habe ähnliches bereits stable seit über einem Jahr auf Basis von Debian Squeeze am laufen, allerdings ohne ISPConfig.

Jetzt werde ich mein Projekt mit Debian Wheezy und ISPConfig fortsetzen und bin dann gerne bereit das ganze auch als HowTo einzureichen.

Danke!

Till · 4. Juli 2013

Jetzt werde ich mein Projekt mit Debian Wheezy und ISPConfig fortsetzen und bin dann gerne bereit das ganze auch als HowTo einzureichen.

Das wäre super!

Abigail20131 · 10. Aug. 2013

Ich häng mich hier auch mal dran und hätt gleich ein paar Fragen.
Hab mich ebenfalls an die Squeezy Cluster Anleitung gehalten, bei mir starten auch mysql wieder nur verbinden sich die beiden nicht. Bekomme die ganze Zeit nur error connecting to master '********' retry-time:60 ........ Fehlermeldung.
Slave_IO_Running steht die ganze Zeit auf connecting
Slave_SQL_running auf YES.

Was mich ein bischen verwirrt.
MASTER -> SLAVE telnet user root funktioniert
MASTER -> SLAVE telnet user 'slaveuser' Access denied
SLAVE -> MASTER telnet (egal welcher user) Error 1130 Host ****** is not allowed to connect to this MySQL Server

Vielleicht sagt euch das etwas da ich aber schon die ganze Nacht seit gestern (oh es ist ja schon Nachmittag) dran bin glaub ich das ich ein klein wenig Betriebsblind bin. DANKE

nowayback · 10. Aug. 2013

hi,

SLAVE -> MASTER telnet (egal welcher user) Error 1130 Host ****** is not allowed to connect to this MySQL Server

schau mal nach ob der mysql slave user auf dem master server auch die richtige ip drinstehen hat

grüße
nwb

mccyberix · 5. Okt. 2013

try this, remove the:

Code:

master-host = xxx            
master-user = xxx            
master-password = xxx        
master-connect-retry = xxx

directives from my.cnf, they are not needed anymore for replication, you may also need to move the ibdata files out of the way from /var/lib/mysql folder

Brainfood · 17. Nov. 2013

Mini-HowTo: MySQL Master/Master Replikation

Fall: Sync ist kaputt:

Code:

mysql -h localhost -u root -p

Code:

mysql> SHOW SLAVE STATUS \G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 127.0.0.1
                  Master_User: slaveuser
                  Master_Port: 3307
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000164
          Read_Master_Log_Pos: 8607676
               Relay_Log_File: mysqld-relay-bin.000488
                Relay_Log_Pos: 768697
        Relay_Master_Log_File: mysql-bin.000154
             Slave_IO_Running: Yes
            Slave_SQL_Running: No
              Replicate_Do_DB: 
          Replicate_Ignore_DB: 
           Replicate_Do_Table: 
       Replicate_Ignore_Table: 
      Replicate_Wild_Do_Table: 
  Replicate_Wild_Ignore_Table: 
                   Last_Errno: 1062
                   Last_Error: Error 'Duplicate entry 'domain.de-2013-08-17' for key 'PRIMARY'' on query. Default database: 'dbispconfig1'. Query: 'insert into web_traffic (hostname, traffic_date, traffic_bytes) values ('domain.de', '2013-08-17', '2356')'
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 18085421
              Relay_Log_Space: 146656393
              Until_Condition: None
               Until_Log_File: 
                Until_Log_Pos: 0
           Master_SSL_Allowed: No
           Master_SSL_CA_File: 
           Master_SSL_CA_Path: 
              Master_SSL_Cert: 
            Master_SSL_Cipher: 
               Master_SSL_Key: 
        Seconds_Behind_Master: NULL
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error: 
               Last_SQL_Errno: 1062
               Last_SQL_Error: Error 'Duplicate entry 'domain.de-2013-08-17' for key 'PRIMARY'' on query. Default database: 'dbispconfig1'. Query: 'insert into web_traffic (hostname, traffic_date, traffic_bytes) values ('domain.de', '2013-08-17', '2356')'
1 row in set (0.00 sec)

mysql> quit
Bye

Situation: Server 1 (funktioniernde DB) - Server 2 kaputt

1. Mini Backup

Code:

cd /var/lib
service mysql stop
tar cvfz mysql_bla_backup.tar.gz mysql

2. Server 1 - DB sichern + übertragen

Code:

service mysql start
mysql -h localhost -u root -p
SHOW SLAVE STATUS \G
STOP SLAVE;
RESET SLAVE;
---> Server1: RESET MASTER;
---> Server1: quit
mysqldump -h localhost -u root -p --all-databases --master-data > /var/lib/mysql_bla1_dump_24.08.2013.sql
scp mysql_bla1_dump_24.08.2013.sql root@server2:/var/lib

3. DB in Server 2 wiederherstellen + sync reset + backup (der neuen Datenbank)

Code:

---> Server2: quit
mysql -h localhost -u root -p < /var/lib/mysql_bla1_dump_24.08.2013.sql
---> Server2: mysql -h localhost -u root -p
---> Server2: RESET MASTER;
---> Server2: quit
service mysql stop
tar cvfz mysql_bla2_24.08.2013.tar.gz mysql
service mysql start
mysql -h localhost -u root -p
STOP SLAVE;
RESET MASTER;
SHOW MASTER STATUS;

4. MASTER STATUS Positionen vergleichen (server 1 vs server 2)

Code:

mysql> SHOW MASTER STATUS;
+------------------+----------+--------------+------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000001 |      106 |              |                  |
+------------------+----------+--------------+------------------+
1 row in set (0.00 sec)

5. Neuen Sync auf beiden Servern erstellen

Code:

CHANGE MASTER TO MASTER_HOST='127.0.0.1', MASTER_PORT=3307, MASTER_USER='slaveuser', MASTER_PASSWORD='GEHEIM', MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=107;
SHOW SLAVE STATUS \G
START SLAVE;
SHOW SLAVE STATUS \G

6. paar Minuten warten ... dann sollte der Sync funktionieren

Code:

mysql> SHOW SLAVE STATUS \G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 127.0.0.1
                  Master_User: slaveuser
                  Master_Port: 3307
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000001
          Read_Master_Log_Pos: 158869
               Relay_Log_File: mysqld-relay-bin.000002
                Relay_Log_Pos: 159014
        Relay_Master_Log_File: mysql-bin.000001
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              Replicate_Do_DB: 
          Replicate_Ignore_DB: 
           Replicate_Do_Table: 
       Replicate_Ignore_Table: 
      Replicate_Wild_Do_Table: 
  Replicate_Wild_Ignore_Table: 
                   Last_Errno: 0
                   Last_Error: 
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 158869
              Relay_Log_Space: 159170
              Until_Condition: None
               Until_Log_File: 
                Until_Log_Pos: 0
           Master_SSL_Allowed: No
           Master_SSL_CA_File: 
           Master_SSL_CA_Path: 
              Master_SSL_Cert: 
            Master_SSL_Cipher: 
               Master_SSL_Key: 
        Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error: 
               Last_SQL_Errno: 0
               Last_SQL_Error: 
1 row in set (0.00 sec)

mysql>

127.0.0.1 ist in meinen Fall ein Sync über sTunnel

ispconfig3-debian-6-squeeze-auf-debian-7-wheezy-upgrade

In Deb 7 sind folgende /etc/mysql/my.cnf Optionen rausgeflogen:

Code:

!!!DEPRECATED!!! ###---> master-host = 8XX.XXX.XXX.XXX
!!!DEPRECATED!!! ###---> master-user = slaveuser
!!!DEPRECATED!!! ###---> master-password = GEHEIM
!!!DEPRECATED!!! ###---> master-connect-retry = 60

Viel Erfolg

florian030 · 18. Nov. 2013

Code:

CHANGE MASTER TO MASTER_HOST='127.0.0.1', MASTER_PORT=3307, MASTER_USER='slaveuser', MASTER_PASSWORD='GEHEIM', MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=107;
SHOW SLAVE STATUS \G
START SLAVE;
SHOW SLAVE STATUS \G

Das Master-Password muss nicht mit übergeben werden.

Dein Vorgehen setzt Voraus, dass auf beiden Servern das Master-Log und die Position identisch ist. Davon würde ich aber nicht ausgehen ( bzw. es deutlicher machen). Besser ist es, auf jedem Server SHOW MASTER STATUS zu verwenden und diese Werte dann auf dem anderen Server zu setzen.

Ich mache das (und das Erstellen eines Dumps) eher per Script:

Code:

#!/bin/bash
LOCAL=idefix
REMOTE=obelix
/usr/bin/mysql -e "stop slave;"
FILE=`/usr/bin/mysql -h $REMOTE -e "show master status\G"|grep File|cut -d\: -f2|cut -d" " -f2`
POSITION=`/usr/bin/mysql -h $REMOTE -e "show master status\G"|grep Position|cut -d\: -f2|cut -d" " -f2`
mysql -e "CHANGE MASTER TO MASTER_HOST='127.0.0.1', MASTER_USER='slave_user-$LOCAL', MASTER_PORT=3307, MASTER_LOG_FILE='$FILE', MASTER_LOG_POS=$POSITION;"
/usr/bin/mysql -e "start slave;"

Brainfood · 18. Nov. 2013

@florian

4. MASTER STATUS Positionen vergleichen (server 1 vs server 2)

dachte wäre eindeutig genug

ein RESET MASTER; setzt dir immer die Positionen auf 000001 / 106 zurück

MySQL :: MySQL 5.0 Reference Manual :: 13.4.1.2 RESET MASTER Syntax

PS: Bei mir laufen solche M/M Replics ca. seit 2 Jahre sehr zuverlässig, mit Postgresql ist das ganze sehr schmerzhaft

Mit freundlichen Grüßen Brain

florian030 · 18. Nov. 2013

Du brauchst kein RESET MASTER, wenn Du den Dump mit --master-data erstellt. Problematisch wird es aber dann, wenn auf beiden Servern geschrieben wird ehe Du die Log-Werte neu gesetzt hast. Für gewöhnlich läuft eine Replikation aber eh ohne Probleme.

Brainfood · 18. Nov. 2013

Ich geh dennoch mit RESET MASTER; (mit dem purgen der LOG_files) auf Nummer sicher und da ich mit clusterssh die paar befehle parallel auf beiden Kisten ausführe, resette ich den gesamten Sync innerhalb von paar Sekunden ... Der "Ausfall" hält sich mit dem sync_reset script von mir (was zuvor alle kritischen Dienste runterfährt (apache,postfix/dovecot..bla) resettet, den 1GB dump per ssh auf die andere Kiste, ins andere RZ, schiebt und wieder alles startet ... bei unter 1 Minute ... in grenzen

Die Punkte waren auch nur exemplarisch bei mir, es kann ja jeder selbst entscheiden, ob mit weiteren "lock" Optionen, stupidem (direkten) /var/lib/mysql verzeichnis_kopieren oder was ach immer gearbeitet wird

PS: Ich würde in dein bash_script_beispiel zum Schluss noch ein "exit 0" dranhängen

Debian Wheezy - Problem mit der Replikation der SQL Datenbanken

mrzs2k

New Member

Le-Seaw

Member

florian030

Well-Known Member

mrzs2k

New Member

Till

Administrator

Abigail20131

New Member

nowayback

Well-Known Member

mccyberix

New Member

Brainfood

Member

florian030

Well-Known Member

Brainfood

Member

florian030

Well-Known Member

Brainfood

Member

Werbung

Wir schützen deine Privatsphäre