Sat Apr 12 05:55:43 PDT 2008
- Previous message: [Slony1-general] Re: Small tool to make Slony management easier
- Next message: [Slony1-general] Re: Small tool to make Slony management easier
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Dane Miller <dane at greatschools.net> wrote: > > Bill Moran wrote: > > I've been putting this together over the last couple weeks for > > the reasons listed on the HTML page: > > http://people.collaborativefusion.com/~wmoran/PostgreSQL/slony_switchover.html > > > > I'm interested to hear how useful this is to others, and of course > > suggestions for improvement are welcome. [snip] > You put a 'wait for event' command after 'lock set' *and* 'move set'. > slonik_move_set only waits after 'lock set'. Is this extra wait > necessary? If so, should it be fixed in slonik_move_set? I'm using > this version: > slonik_move_set.pl,v 1.1.4.1 2006-10-27 17:54:21 The rationale behind that is that the shell script doesn't exit until the move set() is complete. I _believe_ the slonik move set() command can return once the event is submitted, even though the operation is not complete. I don't want this -- I want the operation to feel confident that the operation is complete when the command returns. If I'm wrong about move set()'s behaviour, then this last wait is unneeded. I'll try to make time to test this next week. > you state here > http://people.collaborativefusion.com/~wmoran/PostgreSQL/slony_switchover.html that... > > Our network topology causes connection paths to vary depending on > > where you're running the slonik script from, thus each node would need > > its own slonik script that was different than other nodes > > So there's more than one way to connect to a given node? Can you > explain this further? What kind of network topology do you have that > necessitates having connection paths that vary? (I obviously need to > read more slony documentation) Each of our DB servers has multiple IP addresses and firewall policies dictate who can talk to who. For example, two DB servers in the same data center will talk directly to each other on their DB IPs, whereas a DB server in another facility will have to go through two firewalls and connect to another DB's management IP. In somewhat less abstract terms, if I have 3 servers: db0 - datacenter 1 db1 - datacenter 1 db2 - datacenter 2 If I execute slonik commands from db1, it will use the hostname db0-db to connect to db0, but db2 will use the hostname db0-mgmnt. Are you running Linux by any chance? This script was developed and is deployed for us on FreeBSD, and I've verified that it works as advertised on that platform. I've _attempted_ to make sure that it will work on Linux as well, but I've not had the opportunity to test it. Testing and feedback is encouraged. -- Bill Moran Collaborative Fusion Inc. wmoran at collaborativefusion.com Phone: 412-422-3463x4023 **************************************************************** IMPORTANT: This message contains confidential information and is intended only for the individual named. If the reader of this message is not an intended recipient (or the individual responsible for the delivery of this message to an intended recipient), please be advised that any re-use, dissemination, distribution or copying of this message is prohibited. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. ****************************************************************
- Previous message: [Slony1-general] Re: Small tool to make Slony management easier
- Next message: [Slony1-general] Re: Small tool to make Slony management easier
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Slony1-general mailing list