Any issues with replication of ISPConfigdb?

[tester321]

Thanks again Falko, I have set it up on both Primary & Secondary to do every 5 minutes so all bases are covered in both environments.

Originally Posted by falko

Good point. Yes, I think creating the file every five minutes or so makes sense.

[tester321]

Falko, it is not working.

1) Replication is working fine (ispconfigdb and Drupal databases)

2) I have the cron job creating the .run file every 10 minutes and that is working fine

3) However, I created a new Drupal site tied to webXdb1, and created the replication database stub on the secondary, etc. But, ISPConfig never creates the User/Group/etc in the OS (I checked /etc/passwd)

4) What I get from Drupal is:

Site off-line
The site is currently not available due to technical problems. Please try again later. Thank you for your understanding.
If you are the maintainer of this site, please check your database settings in the settings.php file and ensure that your hosting provider's database server is running. For more help, see the handbook, or contact your hosting provider.
The mysqli error was: Access denied for user 'webXu1'@'localhost' (using password: YES).

(and that is not because of any error in the settings.php, it is because that User/Group does not exist at the OS level so it can't authenticate with mysql using the credentials that are in the settings.php).

5) Reminder that I am not replicating the "/var/lib/mysql" database -- could this have anything to do with it?

Any thoughts or suggestions?

Originally Posted by falko

Good point. Yes, I think creating the file every five minutes or so makes sense.

[falko]

Oh... I think that happens because the update status in the master database gets deleted after the backend has run, and that deletion of the update status gets replicated to the salve database before the backend on the slave server could do its job...

[tester321]

OK,

Can you suggest a Table within ISPConfigdb that should not be replicated then, so the Slave can act on the .run but not have the completion flag set via replication before it acts?

Thanks

Originally Posted by falko

Oh... I think that happens because the update status in the master database gets deleted after the backend has run, and that deletion of the update status gets replicated to the salve database before the backend on the slave server could do its job...

[falko]

No, because the update status is just a column in the respective table, not a table of its own.

[Grey]

Just a quick thought: perhaps it could work like this if your replication slave is doing its work with a delay time, so it gets the changes a bit later (i.e. the update flag ist still there)

Another thing may be to rsync passwd and shadow files. As you said, the machines were originally cloned from the same VM so it should always stay in sync and besides the database replication and the whole directory tree under /var/www that is the only thing together with the VHost file of apache2 to keep in sync.

So perhaps it would be a possibility to do a full replica of the DB, sync /var/www, /etc/apache2/vhost/ & /etc/passwd, /etc/shadow, /etc/groups

Just a quick one, but I think the better way for staying in sync is to use ISPConfig3s multiple server configuration. v2 wasn't exactly made for that.