2013UnconfReplicationWishlist

Minutes: Replication Features Wishlist

- Replication features to replicate individual columns. It was mentioned that Bucardo does something for column replication

- In systems like Slony, duplicating the names of tables that get replicated to multiple nodes, setting it up can be a pain, so ways to rename tables

- Discussion to replicate to a totally different database. Example mongo->mysql etal are available. Postgres->Redis? There's a logical difference between multiple databases and even something completely different

- Instantaneous switching of roles from master to a slave. Single command to switch the roles. Christopher Browne mentioned that "slony move" does something of this sort already.

- Sharding based replication logic: In EC2 kinds of cases the replication set to send to nodes should be based on some partitioning logic. But in this case the hard part is to handle re-allocation when a row moves from a partition to another. Chris opined that sharding if it should be done should be based on "dates". It's more natural and non-changing.

- Event triggers could already be useful in handling deletion of tables that are Slony replicated. You could disallow that or if "CASCADE", think of doing it on the replica setup as well.

- DDLs pushing through to replicas is a pain point. So DDL and corresponding locking needs to be handled appropriately. Discussion specific to Slony and locking pains when trying to push DDL changes. Maybe a wrapper can be written which can identify which objects are involved and CHECK on all replicas if they are available. So a probable solution is out there.

- Wonder if we can convert Slony, Londiste, Bucardo into custom background workers. We need to restart PG to do something like this though.

- Discussion about if some features can be put into the core to handle monitoring requests from HA agents

- Slony still useful for upgrades and partial replication cases. Streaming replication is not going to handle those cases