How does XMLRPC config sync work across failover?

MrPete

I get that all config sync must be set up on the Primary.

HOWEVER: what happens if there's a significant Primary outage?

In that case:

Users are running on the secondary for a while
the longer it takes, the more likely that config changes need to be "reverse synced"

I don't see any documentation for this.

Seems it would be helpful to reliably know. Here's my guess:

Disconnect the sync interface cable so sync is blocked even if enabled
Get both machines running and connected
On Primary, delete sync config, then attach sync cable
Sync secondary->primary
Del sync config on secondary
Add sync to primary
you are good to go

Am I close?

viragomann

@mrpete
The primary node of an HA setup is not meant be down for a longer period of time. However, yes, you can reverse the sync direction this way.

Instead of disconnecting the sync cable you can also block syncing on the secondary temporarily by disabling the respective firewall rule.

MrPete

@viragomann
THANKS!

My current challenge: is there a shell command sequence to remove the primary sync config? In other words, I need to do the equivalent of this to temporarily convert primary to secondary:

System -> High Avail. Sync

Uncheck all checkboxes
Remove IP addresses
Preserve login ID and passwords
Save

I assume that data is preserved in some set of config files. ;)

MrPete

@mrpete said in How does XMLRPC config sync work across failover?:

@viragomann
THANKS!

My current challenge: is there a shell command sequence to remove the primary sync config? In other words, I need to do the equivalent of this to temporarily convert primary to secondary:

Solved this one.

I used the following to remove each VIP from the "down" pfSynce, using console:
ifconfig vtnet1.71 192.168.1.1 -alias

An alternative would be the disablecarp console script.

mattww

I think there needs to be some work done e.a redesign of the whole xmlrpc process thing.
I could easily see times that one firewall is broken and it takes weeks to perhaps months ( depending on supply of hardware vendor ) to get replaced and sycing can be moved back to original primary device.

There should become an option to track changes on secondary device and have information tracking on primary device and as soon primary comes online there should become an option to sync the rules between devices.

So basically what I am saying here is that a secondary node should have more involvement in this whole xmlrpc config process.

Like there should also become an option when primary comes back online you can still keep the secondary running as the main firewall rule util you are sure the primary firewall is working correctly again.

Just my 2 cents of thoughts.