Tino Wildenhain wrote:
the standard approach for master-master replicated data is to use
an UUID-Datatype (see http://en.wikipedia.org/wiki/UUID )
Good point, although we only have space for 64 bits, so the chance of
collision would be higher than it usually is in a UUID system.
That is a se
Russ Ferriday wrote:
(You could get away with a byte for the server ID, leaving masses of
bits for the item ID.)
That's probably a good idea, but I'd prefer to use the least significant
byte for the server ID, effectively allocating OIDs modulo 256. :-)
Also, it's becoming clear that each ser
Hi,
Shane Hathaway wrote:
Stefan H. Holek wrote:
We have put up two boxes in a MySQL master-master replication setup
[1]. As long as we only write to one of the masters all is fine.
Writing to both masters (and expecting MySQL to sort it out) is
giving us trouble. We see things like:
Las
Stefan! This is like holding all your eyelids apart and shouting out
for somebody with a sharp stick! ;)
Watcha gonna do when you add a third server?
er.. lemme see... Multiply all OIDs by three and allocate new OIDs
modulo three?
Eeek!
Why not make the OID a composite of server ID and se
Stefan H. Holek wrote:
We have put up two boxes in a MySQL master-master replication setup
[1]. As long as we only write to one of the masters all is fine.
Writing to both masters (and expecting MySQL to sort it out) is giving
us trouble. We see things like:
Last_Errno: 1062
Last_Error: Er
Hi Russ,
This is correct. I should have mentioned that the two servers are
configured so that server A creates odd, server B even sequence
numbers. This makes the duplicate id error pretty mysterious, IMO ;-)
Stefan
On 22.05.2008, at 13:15, Russ Ferriday wrote:
I have not read the referen
Stefan,
Thanks for opening this thread here. I'm not actually doing anything
like this, but it's great to see you pushing the envelop. I have done
a lot of work on replicated data, over the years, that's where the
following comment comes from.
On 22 May 2008, at 10:36, Stefan H. Holek wrot
We have put up two boxes in a MySQL master-master replication setup
[1]. As long as we only write to one of the masters all is fine.
Writing to both masters (and expecting MySQL to sort it out) is giving
us trouble. We see things like:
Last_Errno: 1062
Last_Error: Error 'Duplicate entry '41
Stefan H. Holek wrote:
I am playing with database replication (MySQL) and have found the
following caveats:
- don't mix engine types (MyISAM, InnoDB)
- don't use temporary tables
Now, RelStorage does both and so I was wondering how to proceed with
replication. Would it be pr
Let me rephrase this. Would it be ok to change *all* tables to use the
InnoDB engine (except new_oid)?
Stefan
On 19.05.2008, at 10:55, Stefan H. Holek wrote:
I am playing with database replication (MySQL) and have found the
following caveats:
- don't mix engine types (MyISAM, Inno
Thanks Tino. I am aware of alternatives. I am however looking for an
answer for the specific case of MySQL master-master replication.
Exciting times!
Stefan
On 19.05.2008, at 12:04, Tino Wildenhain wrote:
Stefan H. Holek wrote:
I am playing with database replication (MySQL) and have found
Stefan H. Holek wrote:
I am playing with database replication (MySQL) and have found the
following caveats:
- don't mix engine types (MyISAM, InnoDB)
- don't use temporary tables
Now, RelStorage does both and so I was wondering how to proceed with
replication. Would it be prudent to a
I am playing with database replication (MySQL) and have found the
following caveats:
- don't mix engine types (MyISAM, InnoDB)
- don't use temporary tables
Now, RelStorage does both and so I was wondering how to proceed with
replication. Would it be prudent to assume that all
13 matches
Mail list logo
