- hello blablub - who am I/where do I work - lots of it happened while I worked for 2ndQ, and is still happening there - others (like me) are also working on it now - cool demo - clone via SRF - clone via basebackup - delayed - conflict - short overview over existing (9.4) infrastructure - logical decoding - background workers - overview over new (9.5) infrastructure - replication origin/progress tracking - DDL replication stuff - what's missing to get BDR without patches - sequence AM - WAL messaging - full extension for DDL replication - Where to go from here - could go into lots of details - different talk - Path A: continue developing UDR/BDR outside core - more solutions can prosper - less risk/work for core - Path B: integrate logical rep into core - users complain about upgrades - users complain about complicated failover/failback - users complain about needing too many extra pieces - What to integrate exactly? - unidirectional first, but forsee expansion - subscriber model - physical/logical clone - replication sets - which type of objects? - optional DDL replication - critical for ease of use/reliability - but also not always desired - integrate server knowledge with FDW servers? - Possibly: CREATE SERVER upstream [FOR] LOGICAL REPLICATION OPTIONS (...); SUBSCRIBE TO REPLICATION SETS (...) USING SERVER upstream WITH (...); -- SUBSCRIBE TO GROUP OF REPLICATION SETS (...) USING ...? - or just use UDR like functions? - continue making things extensible - reusable apply / output plugin - What's the biggest missing piece otherwise? - Reliable (automated) failover/failback - Q: Who's been asked to implement that? - Q: Who has asked? - All the cool kids have it - Voting + timeouts - Probably variant of raft (or paxos, but less popular these days) - Should work both with SR/HS and logical rep - complexities: - testing - state management on SR standbys (no writes) - Questions - UDR/BDR: - pgsql-general - bdr-project.org/docs - slides are at ...