|
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
|
