If you mean to configure the system to replicate rows to different destinations (slaves) based on arbitrary qualifications, no. I had thought about it, but it does not really fit into the "datacenter and failover" picture, so it is not required to meet the goals and adds unnecessary complexity.
This sort of feature is much more important for a replication system designed for hundreds or thousands of sporadic, asynchronous multi-master systems, the typical "salesman on the street" kind of replication.
OK, thanks. This actually fits any kind of distributed application. We have one that lives in our datacenters, but needs to replicate across both fast LAN/MAN and slow WAN. It is multimaster in the sense that individual data rows can be originated anywhere, but they are read-only in nodes other than where they were originated. Anyway, I'm using a hacked copy of dbmirror at the moment.
First, it does not replicate single transactions. It replicates batches of them together. Since the transactions are already committed (and possibly some other depending on them too), there is no way - you loose Se.
OK, got it. Thanks.
Joe
---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings
