Datenbanksynchronisation zwischen 2 Servern funktioniert nicht mehr

[juser]

Moin,

wir haben 2 ispconfig-Server in unterschiedlichen IP Netzen. Der eine ist Master, der andere ist Client. Die Synchronisation der Datenbank zwischen Client und Master ist seit vergangenen Freitagmorgen gestört, seitdem können die Domain, die auf dem Client liegen nicht mehr aufgerufen werden, auch die Jobwarteschlange für den Client wird auf dem Master nicht mehr abgearbeitet.

Wir haben auf beiden Servern nach der Ursache geforscht. Auf beiden Rechnern haben wir die Firewall und fail2ban abgeschaltet, trotzdem keine Synchronisation. Ein Ping jeweils auf den anderen Server funktioniert nicht, der Pingbefehl bleibt auf beiden Servern bei der ersten Zeile hängen:

PING 80.77.xxx.xxx (80.77.xxx.xxx) 56(84) bytes of data.

oder

PING 62.138.xxx.xxx (62.138.xxx.xxx) 56(84) bytes of data.

nmap gab folgendes Ergebnis:

root@web:~# nmap 62.138.xxx.xxx
Starting Nmap 7.80 ( https://nmap.org ) at 2024-01-28 08:23 CET
Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn
Nmap done: 1 IP address (0 hosts up) scanned in 3.09 seconds
root@web:~#

web01:~# nmap 80.77.xxx.xxx
Starting Nmap 7.80 ( https://nmap.org ) at 2024-01-28 08:21 CET
Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn
Nmap done: 1 IP address (0 hosts up) scanned in 3.08 seconds
web01:~#

Wenn ich nmap aus einem anderem Netzwerk, z.B. aus dem Strato-Netzwerk ausführe bekomme ich folgendes Ergebnis:

root@h3005605:~# nmap 80.77.xxx.xxx
Starting Nmap 7.80 ( https://nmap.org ) at 2024-01-28 08:54 CET
Nmap scan report for z3host.de (80.77.xxx.xxx)
Host is up (0.011s latency).
Not shown: 989 filtered ports
PORT STATE SERVICE
20/tcp closed ftp-data
21/tcp open ftp
22/tcp open ssh
25/tcp open smtp
53/tcp open domain
80/tcp open http
443/tcp open https
3306/tcp open mysql
8080/tcp open http-proxy
10000/tcp open snet-sensor-mgmt
40193/tcp closed unknown

Nmap done: 1 IP address (1 host up) scanned in 8.53 seconds


root@h3005605:~# nmap 62.138.xxx.xxx
Starting Nmap 7.80 ( https://nmap.org ) at 2024-01-28 08:57 CET
Nmap scan report for loft24183.startdedicated.de (62.138.xxx.xxx)
Host is up (0.014s latency).
Not shown: 989 filtered ports
PORT STATE SERVICE
20/tcp closed ftp-data
21/tcp open ftp
22/tcp open ssh
25/tcp closed smtp
53/tcp open domain
80/tcp open http
443/tcp open https
3306/tcp open mysql
8080/tcp closed http-proxy
10000/tcp open snet-sensor-mgmt
40193/tcp closed unknown

Nmap done: 1 IP address (1 host up) scanned in 4.45 seconds


traceroute ergab:

web01:~# traceroute 80.77.xxx.xxx
traceroute to 80.77.xxx.yyy (80.77.xxx.yyy), 30 hops max, 60 byte packets
1 static-ip-62-138-xxx-yyy.inaddr.xxxxx.com (62.138.xxx.yyy) 0.425 ms 0.399 ms 0.461 ms
2 92.204.zzz.zzz (92.204.zzz.zzz) 6.794 ms 6.783 ms 6.793 ms
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *


root@web:~# traceroute 62.138.xxx.xxx
traceroute to 62.138.xxx.xxx (62.138.xxx.xxx), 30 hops max, 60 byte packets
1 80.77.xxx.yyy (80.77.xxx.yyy) 19.286 ms 19.258 ms 30.441 ms
2 ae0.300.mx240.fra1.xxxxx.net (80.77.xxx.xxx) 8.880 ms 1.792 ms 8.856 ms
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *


Der Support des Rechenzentrum hat folgende Antwort auf die Frage ob eine Firewall die IP und den Port 3306 blockiert:

Bitte beachten Sie, dass wir den Zugriff auf keine IP-Adressen und Ports von unserer Seite aus blockieren.
Ich habe auch einen nmap-Scan auf beiden Servern (loft24185 - 62.138..xxx.xxx, und der hinter 80.77..xxx.xxx) durchgeführt und festgestellt, dass beide Server ordnungsgemäß erreichbar sind und Port 3306 offen haben.
Was auch immer der Grund für die fehlgeschlagene Synchronisierung ist, es liegt nicht an einer Firewall auf unserer Seite, die den Datenverkehr blockiert.

Mir gehen jetzt die Ideen aus wo die Ursache zu finden ist und wie das behoben werden kann.

Hat das schonmal jemand gehabt und hat eine Lösung?

 

[nowayback]

die mysql verbindung ist prinzipiell verfügbar. du hast ja nur die ip adressen zensiert, nicht die hostnames da konnte ich das testen.

verbinde dich mal auf den client und dann teste mal die verbindung zum master auf der console mit dem command: mysql -u root -p -h hostnameOderIpVomMaster
das passwort steht in der /usr/local/ispconfig/server/lib/mysql_clientdb.conf wenn ich mich nicht täusche

 

[Till]

verbinde dich mal auf den client und dann teste mal die verbindung zum master auf der console mit dem command: mysql -u root -p -h hostnameOderIpVomMaster
das passwort steht in der /usr/local/ispconfig/server/lib/mysql_clientdb.conf wenn ich mich nicht täusche

In der datei steht das lokale root Passwort, damit kommt man nicht auf den Master. Aber die Vorgehensweise es mit dem MySQL client zu testen ist richtig, man muss dafür aber die dbmaster Zugangsdaten aus der /usr/local/ispconfig/server/lib/config.inc.php nehmen. Am besten die exakten daten, also IP oder Hostname so wie er da für den dbmaster steht, dann user ispcsrvX wobei X die ID des Servers ist und dann das Passwort, so wie es dort steht.

 

[juser]

Vielen Dank für die schnellen Antworten. Wir haben gestern noch einen schnellen Workaround gefunden so das die Webseite wieder online ist. Jetzt haben wir Zeit Eure Lösungsvorschläge auszuprobieren.

 

[juser]

Wir haben das jetzt mit den Daten vom Client die in der /usr/local/ispconfig/server/lib/config.inc.php stehen ausprobiert.

Ergebnis:
Nach der Passworteingabe passiert sehr lange nichts und dann kommt
ERROR 2002 (HY000): Can't connect to MySQL server on '80.77.xxx.xxx' (115)

Das gleiche passiert wenn statt der IP web.xxxx.de eingeben wird.

Parallel google ich nach dem oben genannten Fehler, aber bisher nichts erhellendes gefunden.

 

[Till]

Dann habt Ihr entweder eine Firewall zwischen den servern aktiviert oder mysql/mariadb auf dem master umkonfiguriert so dass er nur noch auf localhost lauscht und somit nicht mehr aus dem netz erreichbar ist. Da aber @nowayback geschrieben hat dass er den mysql erreichen konnte auf dem master, habt Ihr wohl eine Firewall zwischen den servern konfiguriert oder den slave geblocked. In Frage kommen da also firewall auf dem master, firewall auf dem slave, ban des slave durch den master via fail2ban oder einer ähnlichen software auf den master. oder aber die Netzwerkverbindungd es slave geht generell nicht, was ihr ja vermutlich schon geprüft habt.

Ansonsten, wenn Du nicht weiter kommst, kontaktier Thom vom ISPConfig Business Support: https://www.ispconfig.org/get-support/?type=ispconfig

 

[juser]

Hallo Till,
danke für die schnelle Antwort.
Ausschliessen können wir eine Firewall, Rechenzentrum sagt es wird nichts durch eine Firewall geblockt. Firewall UFW auf den Servern ist abgeschaltet, ebenso Fail2ban.
Wir können beide Server aus anderen Netzwerken wie z.B. aus dem Strato Netzwerk erreichen.

Zu Thom habe ich einen direkten Draht, das ist unsere letzte Option.

 

[Till]

Ich habe Dir ja auch andere Optionen genannt wenn es keine Firewall ist, müssstest Du mal alle checken.