Um ... if it "doesn't dynamically swap between them", then when does the 2nd server actually get used?

I'm asking the question because I'm calculating the risk of overriding their skip-by-two configuration.

If the 2nd server is never actually used, then there'd be no risk.

So ... can they give you a highly-technical detailed explanation of when the 2nd master is ever used?

I will ask them

Their reply

Thanks for getting back. I'm afraid that I cannot give you a full technical breakdown of the process involved as this is a core procedure used on our platform and as such it is protected information by the company. I was able to inform you of the process that was used to load-balance the system but the technical specifics cannot be divulged.

Congerman:

as I have said previously this is a common occurrence on any servers that are load-balanced.

Congerman:

it is protected information by the company.

"this is a common occurrence on any servers that are load-balanced" ... but yet "it is protected information by the company".

Nice.

Clearly they don't want to be helpful.

Another host to add to the "don't use them" list.

Hi,

I've just set up our new store with Register365/Namesco, one of the biggest providers in the UK. I've got exactly the same thing happening. Here's the tech support response:

Thank you for getting in touch with us about Hosting.

1: The script you are trying to run does not work as our Database server is pre-configured, unfortunately we cannot install, remove or change any software/settings for you (including modifications to the php.ini file or changing the IIS security settings) as you are on a shared hosting platform and the software/configuration settings in place apply to the entire user base.

2: The new Database servers are of a high-availablilty pair for resiliency, with master-master replication, so that if one goes offline, the other comes straight up.
Auto-increment is set server-side to go up in 2s - odd on one server, even on the other. This prevents data collisions in auto-increment fields.

For this reason we cannot modfiy the settings unfortunately.

=====

I really need to stay with these people for a while, at least in terms of the website. Are there any significant issues we will have to watch for? Is there anything I can do with our code to prevent them? I've never looked into running the website on one host and the database on another, but should we be looking at that?

Thanks, as always.

Hi, After a couple of months the incrementing by 2 each time was rectified on my shops. I do not know if my hosting agent changed their settings but all is good now. Sorry I cannot help with your situation. Good luck. I use myhostingcompany.co.uk

David R:

Hi,

I've just set up our new store with Register365/Namesco, one of the biggest providers in the UK. I've got exactly the same thing happening. Here's the tech support response:

Thank you for getting in touch with us about Hosting.

1: The script you are trying to run does not work as our Database server is pre-configured, unfortunately we cannot install, remove or change any software/settings for you (including modifications to the php.ini file or changing the IIS security settings) as you are on a shared hosting platform and the software/configuration settings in place apply to the entire user base.

2: The new Database servers are of a high-availablilty pair for resiliency, with master-master replication, so that if one goes offline, the other comes straight up.
Auto-increment is set server-side to go up in 2s - odd on one server, even on the other. This prevents data collisions in auto-increment fields.

For this reason we cannot modfiy the settings unfortunately.

=====

I really need to stay with these people for a while, at least in terms of the website. Are there any significant issues we will have to watch for? Is there anything I can do with our code to prevent them? I've never looked into running the website on one host and the database on another, but should we be looking at that?

Thanks, as always.

My thought is that if the even entries of one server are seen on the server that provides odd entries and then the odd entries of the one appear back on the other server then the only time of trouble would be activity occurring during the transition from one server to the other where a new autonumber was being generated/retrieved.

Overall it affects more than just the order number as there are several tables that record an autonumber. Generally speaking it will mean that the highest autonumber available by the server will be reached twice as fast, but the quantiity of those are already significantly high.

Thanks, our volume is low enough that I'm not worried about hitting the limits. In the earliest posts to this thread it sounded as if there might be more serious issues caused by it. But we can certainly cope with missing order numbers if we understand the source.