Orders incrementing by 2

Hi, I am not a newbee to zen cart and have set up many stores but I have found a problem that I do not know how to resolve.

I am setting up a new store and set the order number to 5001. I then placed 3 orders to test various bits and the order confirmation emails read

Order confirmation No: 5001
Order confirmation No: 5003
Order confirmation No: 5005

Can anyone tell me why they are not sequential?

Thanks

Contact your hosting provider and have them check the setting on the auto increment increment for your databases and ensure that it is set to 1 vs 2 ...

Out of curiosity, if you add new products or customers, are they also being added in twos?

I will ask them

Have just checked and new customers is also incrimenting by 2, does that prove anything?

To me that most likely means that you need to speak with your hosting provider to correct the setting of the:
auto increment increment

from 2 to 1 ...

I am not sure if you have accesses to that for yourself and suggest let them fix it up for you ... perhaps they will also be able to determine what changed it from 1 to 2 in the first place ...

I will contact them and post back here. Thanks for the advice

Got this from my hosts ( Heart Internet) I don't believe them

"Thanks for waiting. After discussing this with our systems administrators this is happening because the database is on our shared MySQL servers so it automatically increments by 2 instead of 1; this cannot be changed I'm afraid."

Time for a new hosting provider ... that is silly ... :blink:

Now they say this will happen to everyone

" Apologies for that I should have mentioned the recent server upgrades; we have been working through our servers to load balance them and this site is on a load-balanced server now. The load-balancing on servers using the shared MySQL server causes the auto-increment value to be set as '2'. Once the rolling upgrades are completes and all servers are load balanced, this will become standard behaviour on all of them."

Trouble is that I am a reseller and I have over 300 sites that would have to be moved to a new reseeler host Arrggggggg

Thanks for your help in pointing me in the right direction though. Would there be a switch or setting within my actual MySql to change this or is it definately their server settings that influence it?

Update Now making a bit of sense Blaa why don't they give you the whole story at the start

"Thanks for getting back. This is actually common practice with a multi-master MySQL setup as it prevents a primary key clash. If a row is added to both of the load balanced servers at the same time, they'd both try to insert the row with the same auto_increment ID, and you'd get an error and replication would break. In a two-server setup, server 1 inserts 1, 3, 5, 7, etc. and server 2 inserts 2, 4, 6, 8, etc.

Auto-increments should never be specifically designed to increase by 1 only as this cannot always be guaranteed."

Off the top of my head ... I believe they need to change the setting ...

OK Many thanks

What version of Zen Cart are you using?

You said that your host implied that they're using 2 servers, with one set to use odd numbers and the other to use even numbers, for the purpose of load-balancing .... but if they're truly doing load-balancing then why are all your numbers odd and none even? It suggests that they're not actually "using" the load-balancing.

using 1.50

They say " In a two-server setup, server 1 inserts 1, 3, 5, 7, etc. and server 2 inserts 2, 4, 6, 8, etc."

They now suggest that i buy a dedicated server to overcome the problem Sales tactique or what?

Ya, great sales tactic. Not.

Dump them.

Doesn't explain why you're only getting odd-numbered records. If you were truly getting load-balanced traffic, as in actually using both servers, then you should be at least getting "some" even-numbered records as well.
Sounds like they've set up their "load balancing" to not actually "balance" the load, but instead to only "offload" traffic to the 2nd server only when the 1st server is deemed "busy" according to some arbitrary threshold.
Poorly architected plan IMO.

In time you'll find that other customers of your host will also complain, and get the same response back. And probably just get the up-sell, instead of getting their server architects to rebuild things in a way that works best for the customers.

Agreed

Why did you ask my zen version?

While one could fudge the ZC code to force auto-incrementing by 1 regardless of the server's global setting, in your multiple-master situation, that is indeed likely to cause replication conflicts ... and then you'll have an even uglier mess on your hands later.

They probably think that multiple-master is the "safest" way to do things because it doesn't require that customers rewrite all their PHP code to work in a master-slave format. And, while it's true that there's no PHP code rewriting needed to use their multiple-master-solution-by-fudging-autoincrementing, there IS a BIG downside: the very problem you've reported ... gaps in record numbers when the code is designed to work with database-driven incrementing dependent on using auto-increment values instead of more complex methods like building custom triggers and stored procedures.
It also means your Zen Cart tables can only store half as many "maximum number of records" as they're designed to hold. So, you may have to eventually alter the db schema to allow for much larger field types on the fields using auto-increment properties.

It would be MUCH safer to have a proper master-slave setup. But that requires rewriting the PHP code to do SELECT statements from "slave" servers, and do INSERT or UPDATE statements on the "master" server only. And rely on scheduled replication cycles to keep both servers updated in "almost-real-time" (which is adequate for almost everything).

Zen Cart v1.x is written to assume a single-master-only MySQL server configuration. And, IT DOES WORK FINE in your host's odd autoincrement situation, but you will have to put up with the gaps in numbers all over the place. (order numbers, customer numbers, zone numbers, product numbers, category numbers, order-status-numbers, etc.)

Zen Cart v2.x (currently under development, not ready for viewing) is written to support master-slave configurations, and also has a number of things built-in to insulate against things like your auto-increment anomaly ... well, for order-numbers anyway, but not yet for other data records.
We'll add a task to explore handling those differently for cases such as what your hosting company has chosen. But it won't likely get backported to v1.x because it would require sweeping code changes on both catalog and admin sides.

Congerman:

Why did you ask my zen version?I was toying with an idea to force an override of the global configuration. But unless you can find a way to guarantee that your site will not actually use the 2nd server (the one that is set to issue "even" numbers), I suspect it'll be dangerous to do such an override, lest you end up with replication conflicts that will make you and your hosting company have to talk regularly and sort out duplicate records.
And, since duplicate records could mean that you could have two customers both legitimately get the same order number, and even the same customer number, that would all be very bad.

Sounds like vs 2 will be the way to go if it will get around this as I presume other hosting agents will be going this way as well.

out of interest what are the maximum allowed records in the zen database?

As it stands will vs 1.5 be able to upgrade to vs 2 easilly or will it require a complete reinstall and re customisation and database transport

Congerman:

out of interest what are the maximum allowed records in the zen database?The maximum allowed is based on the field definitions for each table. And some tables have different structures.

Congerman:

will vs 1.5 be able to upgrade to vs 2 easillyAnswers about v2 would be premature. As with any upgrade, there will be some need to redo things in templates and customizations. And, like any major version number upgrade, it is likely that some plugins will also need refining.

Congerman:

will vs 1.5 be able to upgrade to vs 2 easilly or will it require a complete reinstall and re customisation and database transport
Like all ZC upgrades, data will be preserved.
Your question suggests that you view upgrades differently than I do. Even current-version upgrades don't require any complete reinstall nor do they require any database transport if you do them the way I recommend: http://www.zen-cart.com/entry.php?3-How-do-I-rebuild-my-site-on-the-new-version-instead-of-upgrading

Many thanks for all your imput, Looks like I will be using vs 2 as and when it is available

about the true dual server and incrimenting they say this about the numbering and always getting odd but no evens

That would be true in the case of web-traffic balancing, which uses normal multi-master balancing, however the setup of MySQL server means it doesn't dynamically swap between them. I'm sorry that this has interfered with the ordering setup of your Zen sites, but as I have said previously this is a common occurrence on any servers that are load-balanced.