That's what ISPConfig is doing already. Your problem was not that several jobs were running at the same time.
Well, something was eating all my RAM and swap file. Although, I'm now thinking that it might have been more to do with the error emails being sent out. Because, thinking about it, postfix tries to access the database too, in order to look up emails. So could it possibly have been a vicious circle in my setup? That is, the database can't be accessed, so the system tries to send an error email. To send the error email, postfix tries to access the database. But the database can't be accessed, so the system tries to send an error email. And round and round that goes, until all memory is consumed. Anyway, it has been fixed by changing the password. But, as always, I still like to try to understand why things went wrong to ensure that I don't mess it all up again.
A virtual machine should not be able to crash the host, no matter what happens inside the VM. The VM should not be able to request more RAM from the host than the host has physically available. Maybe you overcommitted your virtual machines so that the sum of ram in the VM's exceeds the RAM size of the host?
I don't get it. Through PhpMyAdmin, I can see that the DNS records are there in the master database. They are attributed to server_id "4" and that is, indeed, the correct server id of "ns1" (and the db user is "ispcsrv4" which seconds that). And "ns1" is definitely able to read the master DB fine, as the zone files are there. But "ns2" - which is the ISPC master, so it can definitely read its own "localhost" database - just isn't picking up these DNS changes, as the zone files are not there in "/etc/bind". But it's set as a DNS server, it's set as a mirror of "ns1" and the BIND plugin and DNS mods do have the symlinks in their respective "-enabled" directories. I've turned on debugging in the log and it says "found XX changes, staring update process" - where XX is going up when I make changes - but then it simply says "remove lock" and there are no errors reported. The next log entry simply says "found XX changes" again - and XX is the same number - so it's finding the changes, but somehow they're not being applied and so it finds those changes again and again. Yet no error is reported, as far as I can see.
I'm not quite sure if the ISPConfig master can be a mirror of a slave. Never tried that out. It might be a problem because of the "local" and the "master" database being the same.
Ah. That's going to be an issue for me. You see, the reason for doing it that way around is that I'm crisscrossing load balancing and DNS. "lb1" is "ns2" and "lb2" is "ns1". The idea is that, when both nodes are up, "lb1 / ns2" does all the load balancing and "lb2 / ns1" does all the DNS. Separation of duties. But each node is capable of both jobs, so should one node fail, then the other - either of them - can take over both duties (until I get the chance to fix the failed node and restore full operations). A way to make an active / passive HA configuration not have a machine that's just sitting there passively, doing nothing at all. Crisscross the active / passive with the secondary / primary then, in normal operations, all the machines have their active duties, but we do have fail over as well. I guess, though, that it can still be done. I just need to do it the other way around. So the master is primary DNS / passive load-balancer and the other machine is secondary DNS / active load balancer. As the load balancing has nothing to do with ISPConfig, so it shouldn't matter which way around I do that. Though that will slightly offend my sense of symmetry, as the first machine physically in the rack will now be the secondary load balancer. But, yes, I can see that with the crisscrossing, I've ended up with the master being a slave of itself. And whilst that might logically still work - a master being a slave of itself simply reduces to the master consulting its own master DB - that's just not how the implementation logic works (ISPConfig does not reduce the logic of "master is the mirror of a slave, which is slave to the master" to just simply "localhost" for you). Okay, I can just swap their roles around, I guess. Then it should logically work. (Also, this is, in the end, a temporary problem. Once we have more nodes in our cluster, I'll want to separate duties further and so won't be loading both load balancing and DNS on the same nodes, but would have separate DNS machines - devoted to the purpose - and separate load balancers - devoted to the purpose. But, you know, currently, our budget doesn't stretch that far, so I've got to make do with what I've got. Can't afford, with so few nodes to begin with, to have any just sitting idle. At least for the time being, until we generate enough money to pay for another set of nodes to add to the cluster.)
I think the problem is that each slave fetches it's to dos from the master's database and it is checked if that one differs from the local db. See this code in the core: PHP: function processDatalog() { global $app, $conf; //* If its a multiserver setup if($app->db->dbHost != $app->dbmaster->dbHost || ($app->db->dbHost == $app->dbmaster->dbHost && $app->db->dbName != $app->dbmaster->dbName)) { if($conf['mirror_server_id'] > 0) { $sql = "SELECT * FROM sys_datalog WHERE datalog_id > ? AND (server_id = ? OR server_id = ? OR server_id = 0) ORDER BY datalog_id LIMIT 0,1000"; This if will only match on a set up slave that has joined the master. So I believe this is the reason why you did get shown the number of changes but those remained because the code block is never executed. Obviously we should prevent users from being able to assign the master being a mirror of anything.
That does make sense. Oh, well. As long as I know why it's going wrong, then I can work out how to fix it. I just need to swap around the roles. And, for you, you can consider this an implicit "bug report" that, yes, it probably shouldn't be possible to set the master as a mirror of anything, if that's not actually supported. Though make that clear in the manual as well, so that users like me don't invent weird configurations like this.
That's exactly what it was. When I swapped "ns1" <--> "ns2", it worked just fine. Now comes the fun of swapping "lb1" <--> "lb2", to get back the crisscross. Funnily enough, the trickiest bit here is undoubtedly going to be changing the hostnames around to reflect the changed roles (which, granted, I don't strictly have to do, but that sense of symmetry I've got will nag me otherwise).
