Below are two aspects of the presentation: 1. A text outline of the slides
2. Bill Moran's minutes (many thanks!) Agenda - What is Slony-I? (Hence, what are we trying to do...) - What are some things we won't do? - What's good; what's new for 1.2? - Known ToDo items - Brainstorming ideas... What is Slony-I ? Slony-I is an asynchronous single master to multiple slave replication system for PostgreSQL supporting multiple database releases, cascaded replication, and slave promotion. Roads Not To Be Taken - Slony-I won't be heading to become a multimaster replication system - If someone takes a release, and uses parts of it to implement that, that's fine (cbb: It looks like the Skype folks have taken parts of Slony-I to implement parts of their partitioning system, and learned some things; I look forward to seeing their code release...) - Drawing it into “core” PostgreSQL seems undesirable, as that ties it to specific releases - Lack of triggers on pg_catalog tables rules out much smarter DDL behaviour - Some things are good already - The notion of replication via applying SYNCs seems good, something not to change - Performance has been improving; 1.2 should offer “mo betta,” and there are some ideas for beyond that New for 1.2 - Win32 support - slon process much less fragile - slon process uses less RAM - numerous performance improvements that should help behaviour with large systems - no more OID consumption - less usage of resources needing vacuums Known ToDos - Open extra thread to start drawing data for next SYNC while present one is being applied - Move project to pgFoundry - More regression tests - Build Farm??? - Better stability --> easier to have pgAdmin support More ToDo (which amounts to "brainstorming") - Slonik “EVENT PING” - akin to ping (cbb: Gavin Sherry was quite keen on this) - Use 2PC for safer DDL updates, “synchronous” actions? - Synchronizing of other sorts of objects - Security attributes: grant,role,group,user - Functions, aggregates, users, comments - EXECUTE SCRIPT without locking??? - CLONE NODE – use PITR to duplicate a node - Promoting/demoting log shipped nodes - Split cluster? - Per-node STORE TRIGGER - Have sets be “advisory”; replicate table by table Minutes Taken by Bill Moran ------------------------------------------------------ These are the "minutes" I took at Sunday's Slony talk. I hope I captured everything useful that was mentioned. (Chris has added a few cbb: comments..) * To assure synchronization of schema: assign a version number to schema (cbb: Darcy Cain brought this up as a method he has used; this would presumably be an application "assurance" as opposed to something Slony-I could do for you...) * Is it within Slony's scope to replicate system tables: Not exactly clear what a trigger on a DDL is? * Statement level triggers: Call functions on GRANT/REVOKE/ALTER/etc – hooks into the DDL statements: This is liable to require changes to PostgreSQL, which doesn't fit with Slony's model (breaks backwards compatibility). Supporting new features in new versions of PostgreSQL could break “downgrading” capability. (cbb: Unfortunately, the "nebulousness" of this points to this being something that doesn't lead us to any answers as to what could be done next.) * Transient or temporary sets could be useful for the purpose of merging new tables. * There is interest in the perl tools to keep a buffer for the general community between admin and the guts of Slony. (cbb: Is there interest in *working on* the Perl tools? As an OSS project, there is a need for volunteers. In the case of the Perl tools, past volunteers have stepped away, so we kind of need new ones...) * Error messages are awful. (cbb: That seems to overstate it a bit, to me :-). What I heard was that there were cases where people would get pretty raw error messages about violations of unique constraints. It would doubtless be pretty useful to have Slony-I detect the conditions *before* the violation so that we could generate an error message explaining what went wrong. This has been improving, over time; if people can point out instances that they hit, on the mailing list, or as bug reports, that would help us find and address "offenders" of this sort...) _______________________________________________ Slony1-general mailing list [email protected] http://gborg.postgresql.org/mailman/listinfo/slony1-general
