Re: Batch replication ordering (was Re: [GENERAL] 32/64-bit
От | Ed L. |
---|---|
Тема | Re: Batch replication ordering (was Re: [GENERAL] 32/64-bit |
Дата | |
Msg-id | 200304131006.35190.pgsql@bluepolka.net обсуждение исходный текст |
Список | pgsql-general |
On Sunday April 13 2003 9:48, Steven Singer wrote: > > > > nothing wrong with that necessarily, unless you wanted to update the > > master bookkeeping on every new xid as well, in which case it would > > defeat my purpose in the master batch. > > Why do you need to update the master after every commit on the slave? If > your storing the last seqid sent to the slave on that slave(you would > have to update this during every transaction on the slave but I don't see > this as a big deal) and you use that value as the authoratative value for > deciding what next to send to the slave. Agreed, I don't think you need to update the master after every commit on the slave. On the contrary, I was simply making the observation that it would not be useful to do so with respect to performance and traffic. > You would have to periodically update the master to tell it that a > tranaction can be removed form the replication_queue but this can be done > periodically(every x transactions). If dbmirror goes down in between a > commit on the slave and the master being updated then the transactions > will stay on the master in the queue until dbmirror comes back up at > which point it will see from the slave that the transactions have been > sent and they don't need to be resent. Then the master can be updated so > those rows can be cleaned from the queue. Agreed, exactly. Ed
В списке pgsql-general по дате отправления: