Re: Batch replication ordering (was Re: [GENERAL] 32/64-bit
От | Jim C. Nasby |
---|---|
Тема | Re: Batch replication ordering (was Re: [GENERAL] 32/64-bit |
Дата | |
Msg-id | 20030412105458.Z31861@flake.decibel.org обсуждение исходный текст |
Ответ на | Re: Batch replication ordering (was Re: [GENERAL] 32/64-bit ("Ed L." <pgsql@bluepolka.net>) |
Ответы |
Re: Batch replication ordering (was Re: [GENERAL] 32/64-bit
|
Список | pgsql-general |
On Fri, Apr 11, 2003 at 07:32:15PM -0600, Ed L. wrote: > I appreciate your pointing that out. It is pretty undesirable for data to > appear on the slave in an order different from the one in which it appears > on the master. I guess that's another downside to batching. I'm not sure > this approach can do any better than approximating the order since there is > no knowledge of the commit order. I know this will probably require more work than you'd like, but it seems like it might be very useful/important for the replication queue to have definitive information about when commits occur. BTW, I don't know how this would apply to pgsql, but both DB2 and Oracle handle replication via the transaction logs. AFAICT they don't keep seperate replication tables or anything; they just ship whole transaction logs off to the slaves (a bit of a simplification, but my point is that all the data the slaves get is in the form of the transaction logs that are normally kept by the master anyway). -- Jim C. Nasby (aka Decibel!) jim@nasby.net Member: Triangle Fraternity, Sports Car Club of America Give your computer some brain candy! www.distributed.net Team #1828 Windows: "Where do you want to go today?" Linux: "Where do you want to go tomorrow?" FreeBSD: "Are you guys coming, or what?"
В списке pgsql-general по дате отправления: