MyBB

Ive just tested this with a new forum install.
and see there, the usergroups will have IDs: 1 3 5 7 9 and so on, so ether there not hardcoded on insert, or this just doesnt work on a master-master setup.

ive just tested hardcoded inserts on a master server, you CAN add any value you like, so even or uneven, and it doesnt matter what offset that server has.

so this issue is still valid, and i would say its related to mysql replication where you need the auto increment offset. (and thus i also think (haven't looked it up yet) that the inserts of the groups are therefor not hardcoded with ids? else it should have worked.

Yeah if I'm understanding it correctly they're not hardcoded in the queries.

foreach($tree['usergroups'][0]['usergroup'] as $usergroup)
{
    // usergroup[cancp][0][value]
    $new_group = array();
    foreach($usergroup as $key => $value)
    {
        if($key == "gid" || !is_array($value))
        {
            continue;
        }

        $new_group[$key] = $db->escape_string($value[0]['value']);
    }
    $return_gid = $db->insert_query("usergroups", $new_group);        
    // If this group can access the admin CP and we haven't established the admin group - set it (just in case we ever change IDs)
    if($new_group['cancp'] == 1 && !$admin_gid)
    {
        $admin_gid = $return_gid;
    }
    $group_count++;
}

It ignores the gid when adding to the $new_group array. I guess if you remove the $key == "gid" check it'd get added to the $new_group array and be used in the query. I assume there's a reason for doing it like this though, I imagine so the auto_increment works properly for adding new groups (i.e. it would start at 8), but I've always wondered what causes this issue.

Oh, I missed that "continue"... A developer has to check this.
Well, MyBB supports master-slave so I see no reason for supporting master-master.

Master master is NOT the issue here, if the IDs are inserted hardcoded on the values needed by the code there wouldn't be a issue. however this is not just limited by master master setups. ANY other starting auto-increment value then 1 would cause this problem. so it has nothing to do with supporting master master or not, yes you will notice it here, (sooner then anywhere else) but this issue is not exclusive to master-master.
And why would people running a high-available solution be excluded from using this 'software'?
the actual code is far from hard to implement, and wont be any issues later on by adding groups and all, this is purely a installer issue. it wont take much coding to fix this (since its only in the installer and the "standard" groups).

When the install runs, the table is dropped and readded so the auto increment value is reset.

It will always be the same IDs unless you have a modified unsupported MyBB setup.

If you're master-master settup doesn't work like this then you have an obvious bug in MySQL. Maybe you should contact them?

Why do we unset the gid-value? I think Marcel is right and this would solve the problem.

Ryan, you seem to miss the point. auto-increment-offset IS a mysql config option, no bug! search google for mysql master master replication and you will see this option in every single situation (http://www.howtoforge.com/setting-up-master-master-replication-on-four-nodes-with-mysql-5-on-debian-etch-p2) its in all of those big text boxes. anyways, thats why this is a bug in mybb and not SQL im using normal SQL features, and like i said if you infact DO hardcode the id's of the auto generated groups in the queries there wont be any problem..

for mysql docu on it: http://dev.mysql.com/doc/refman/5.0/en/replication-options-master.html#sysvar_auto_increment_increment

Oh if you want to reproduce this and you got a test SQL server be sure its a test server cause this is a server wide option! :
in the config:
look for: [mysqld]
inside it past:
auto-increment-increment = 2
auto-increment-offset = 2

restart your mysql server
this will cause your autoincrement to start on 2 and up it by 2 every increment (so that you can never get the same AI value on your second server, because you will set that one to start on 1 and up by 2 (so: 1 3 5 7 9.. and server 2: 2 4 6 8)
so test it with a test DB or better yet, install mybb.. and you will get the same issues, group IDs are off, newly registers users will be supermod (loved that one tho :P) and so on.. admin panel wont get what type of users they are (group wise).
and THATS why i get this issue...

And why would you have any reason for changing auto-increment-offset?

like i said in my post, its for a master master mysql Replication setup, that way you can never have inserts on both masters that happen at the exact same time (the chance is remote but it could happen!) thats why you use it.. if you set one on even numbers and the other on uneven you can NEVER have the same autoincrement number, and as i stated in my last post, its a common feature used by a lot of people.

but this is still besides the point, this is a regular mysql function, and the forum shouldnt rely on the IDs being those numbers if you dont force them in there! because clearly they do not have to be the values you expect. so just add them into the install with the auto-increment forced on the numbers you expect it to be to resolve this whole issue.

it feels like mysql functions are questioned here, its a regular function, im not using anything exotic or off standard here. and its only the setup that needs to be changed, nothing else... just take a look at the links i gave, documentation from mysql itself, and a example on how to setup a master master setup.

I guarantee you're wasting resources running a master-master setup. Setup a master-slave setup and you'll be much better off.

Reads are always multiples > then writes.

i think i know how to setup my own database environment thank you, we are getting quite offtopic here. this bug report is still on rejected, and the issue still remains.. regardless if my setup is the right one in your opinion (its a HIGH-AVAILABLE setup, master-slave is NOT).
and for your info: master-master can be used as master-slave aswel so its not a waste..
and besides that point.. why would you think I'm only running this forum on my cluster? that would be a waste of resources.
I've done a thesis on mysql clustering and replication, so i think i know what I'm doing. and you shouldn't give people advice on how to setup there servers if you don't know the situation. for all you know I could be running a multi master, multi slave setup with a website that generated over 1 million hits a year.

And to be honest I'm getting a bit tired of having to defend a standard mysql option, and a bug thats not that hard to fix. I'm just trying to help here but it feels like I'm getting shot down for doing so.

Ryan, why do we unset the gid when we insert the groups?
I don't think we should support master-master but this problem could be solved easily.

Marcel Bikker wrote:

I'm just trying to help here but it feels like I'm getting shot down for doing so.

That's quite normal around here. Better get used to it. You reported the issue, you provided a solution - whether they want to improve their software or not is up to them. Arguing about it is a waste of time.

Hi Marcel,

So if you remove

$key == "gid" || 

Dennis

Marcel,

It is not my intent to discourage you; Simply to diagnose if this really is indeed a bug in MyBB. It is very unusual to see this as a bug in MyBB, so are we not allowed to have a discussion and iterate through the logic until I am able to successfully reach the same conclusion as you? I obviously have not written a thesis on master-master setups and I have no idea who you are or what your qualifications are. We get everyone between Ph.D's, IT Administrators, all the way to those who have a hard time finding the power button on their computer or who can barely write their bug reports in legible English.

The point is, we just aren't going to randomly throw in fixes that we don't fully understand. So just work with us until we can understand. MyBB is a stable software because we are careful in our coding practices. In our code we don't just "do" we ask and answer "why" as well.

i can confirm that this fixes the issue!

(sorry for the late response, i could only test this at the office, and i only got back here today).

In fact, there's other areas where PgSQL looks up insert_id, and an invalid session warning appears. I wonder if changing currval to next in the db class would be a better idea?

PostgreSQL is a pretty bad SQL language imo. It makes us do stupid things to keep everything working when half of it should be maintained within the DB software itself.

Sigh

Ok, I see where this bug happens now.

It happens if we manually insert the primary key ID.

You need to make a separate bug report for the other instances in MyBB where this is an issue.