On Sun, 2008-01-27 at 23:42 -0500, Jason Ledford wrote: > Yes, thats what I meant. I didn't think I was explaining it good. it works > syncing primary to backup, but when the original backup becomes the new > primary and the original primary becomes the new backup, its not syncing the > connections. So when I want to reverse it and promote the original primary > back to primary, it breaks all current connections. I am probably > overlooking something so I appreciate any help.
I think this thread might be less confusing from here if change the terminology - what happens when the original backup, which has been master but been demoted back to backup, becomes master again? :) So you have D1 and D2. D1 is usually master, D2 backup. In normal operation, D1 -> D2 sync works fine. In failover operation, D2 -> D1 sync does not. This means that you've not got a sync daemon in the right mode on both machines. To achieve what you want to do, you either: 1. Run a sync daemon in both modes on both machines. This is relatively easy. 2. Use your failover (heartbeat?) to change the daemon states on failover. This is also relatively easy, but if D1 goes offline for some reason how does it know what state to be in when it comes back up? I can see a potential problem here. In the case of point 1, you'd just do the following on both machines (assuming you're controlling your system from scripts - heartbeat, keeplived et al will do this differently or may need a "helping hand"): ipvsadm --start-daemon master ipvsadm --start-daemon backup Whatever then comes from either machine will end up in the table regardless of D1 or D2's current state. Graeme _______________________________________________ LinuxVirtualServer.org mailing list - [email protected] Send requests to [EMAIL PROTECTED] or go to http://lists.graemef.net/mailman/listinfo/lvs-users
