Sun Sep 9 14:27:23 PDT 2007
- Previous message: [Slony1-general] different masters for different tables
- Next message: [Slony1-general] different masters for different tables
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 9/8/2007 9:07 PM, Tim Bowden wrote: > Hi, > > I'm looking at using slony for the first time. I'd like to know if it's > possible to have different tables in a slave db replicated from > different master db's. It was part of the initial concept and the initial implementation. If it doesn't work now, that'd be a bug. > Just to outline the setup I'm looking at, I have (proposed) master db's > that are distributed in various geographical areas for performance > reasons that need to be replicated back to a central slave. The > critical table in each master db (the only table needing to be > replicated) would have an identical data structure and RI model (except > for a constraint limiting the pk to that properly belonging to that > particular master db). > > If possible the slave tables would actually be partitions of a "whole of > system" slave db (ie, children in a table inheritance relationship) in > order to provide a view of all the data in one slave table, though from > a first reading of the docs I suspect this is not possible as the table > schemas would be different from master to slave. As of right now, slon itself cannot change the table or namespace on the fly during replication. So every table that is actually replicated inside of your cluster must have a unique fully qualified name. This could in your case be achieved by creating a partition structure where even on the different origin servers, the table in question has an (always empty) master and just the one, location specific child partition. The central slave then would have all those partitions and replicate into them. That way, the application would see the same table name everywhere, containing the site specific data. As another idea, if any site only ever updates its own key range, nothing would prevent you from having all partitions everywhere. Each location would be origin of one partition while every other location would subscribe to it. That way, the "local" data is read/write and all remote data is available readonly. Slony doesn't distinguish between master and slave nodes. Since every table can have a different "origin", each node can actually be master and slave at the same time, with respect to different tables, that is. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck at Yahoo.com #
- Previous message: [Slony1-general] different masters for different tables
- Next message: [Slony1-general] different masters for different tables
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Slony1-general mailing list