On Mar 22, 2010, at 7:10 PM, Steve Singer wrote: > Ben Chobot wrote: >> Hey guys, >> I have a database I'm currently replicating with slony. Most tables are in >> the same set. I've recently been given the requirement that a few of my >> tables need to be replicated to an additional slave. I'm new to Slony, but I >> believe this means I'll need to create a new set, subscribe the current >> slave and the new, lesser slave to that new set, and then move those tables >> into the new set. Is that correct? >> If so, then I have a concern with the minimum amount of tables I actually >> need to put into my new set. There is a very specific list of tables I want >> to replicate to my new slave. However, the documentation leads me to believe >> that I don't want foreign keys to cross set boundaries, and that means I >> would need to put more tables into my new set than I wish. Can somebody >> explain why foreign keys crossing sets is bad? I *think* it might be because >> slony might not apply updates from multiple sets in a single transaction - >> but if that was the case, then it seems that having foreign keys span set >> boundaries wouldn't merely be undesirable, but rather unworkable. So.... I >> must have something wrong? > > So you currently have sets 1 replicating to nodes A and B. You then create > your set 2 that replications from A to B but also to node C. > > There is nothing stopping your from issuing a move set command to move the > set 2 origin to be node C. Now node B is receiving updates for set 1 from > node A and updates for set 2 from node B. Node A might even see set of > changes from node C before those changes make it to node B. Someone might > then insert a row on node A that references the foreign key. That chance can > also be sent from node A to node B before node B receives the original chance > from node C.
Right, if we make the origins on different nodes, that's clearly asking for problems. But if we keep all set origins to be on the same node? I understand slony doesn't enforce that, but assuming I don't try so hard to shoot my foot, might I referential integrity problems? > When does something cross the line from being unmanageable to unworkable? > Rather than debating that point you are probably better off spending time > trying to find a way to do what you want without having foreign keys that > cross set boundaries. Any suggestions on a better way to go about it? _______________________________________________ Slony1-general mailing list [email protected] http://lists.slony.info/mailman/listinfo/slony1-general
