I have created a cluster by following https://www.howtoforge.com/tutorial...abase-cluster-on-debian-8.4-with-ispconfig-3/ but with Ubuntu 18.04. Has worked great for a month or so. Yesterday suddenly the dns server on the slave was no longer up to date. I checked the MariaDb slave status and it was stalled. Then I did a slave reset and restart. Is now almost done syncing and I see the latests record in the dbispconfig database, but the dns server on the slave still has old data. Will the dns server update itself after a while? How does Ispconfig update things like dns and mailboxes on the slave, once they are changed on the master? I also notice there are 2 databases on the slave: dbispconfig and dbispconfig2. dbispconfig is (almost) up to date, but dbispconfig2 does not have the updates for the last 2 days. Why are there 2 databases? When and how does Ispconfig update dbispconfig2? Thank you very much for any help!
Also I noticed the master server (server1) does not have the dbispconfig2 database, even though I have master-master replication. Not sure if dbispconfig2 was there before.
Normally both servers should have both databases, but it should work even if dbispconfig2 is not on the master. dbispconfig is the database of the first node and dbispconfig2 is the database of the second node. ispconfig server process on the second node connects to the first node and fetches changes from sys_datalog table and inserts these changes into dbispconfig2 and runs the scripts to do the actual config changes. when databse content of both databases differs, then server2 is probably not able to connect to the first server anymore or the changes have been added to dbispconfig2 originally and now get lost by the resync by overwriting a newer dbispconfig2 version on server2 with a older version from server1. You can use debug mode to find out if server2 is able to connect to server1: https://www.faqforge.com/linux/debugging-ispconfig-3-server-actions-in-case-of-a-failure/ enable debug mode for server2 in ispconfig ui on server one, then run server.sh script on server2.
Thank you Till! Somehow the slave suddenly switched to trying to connect to mysql master via IPv6, which is fire-walled. The master-master replication failure was a separate issue which I solved like this: https://www.barryodonovan.com/2013/03/23/recovering-mysql-master-master-replication And I now understand how the cron script work and what server uses what database(s) and how those are updated. So your answer was really helpful... as usual!
