CARP: Promote Backup
-
Hi, you should be able to find the info you need on this page: https://doc.pfsense.org/index.php/CARP_Status
-
Thanks for your reply,
yes I have seen this documentation. Also the pfsense book describes in detail the creation of a cluster but not the change.
I can't figure out in witch order should I switch. -> At first the VIP and then the "High Availability Sync" or reverse order?
-
IIRC there is some button on 2.2.2 snapshots.
-
Thanks, then I will take a look..
-
I can't find this button in 2.2.2.
Can you send me a hint?Dirk
-
You can't promote the secondary node, but you can demote the primary node using the controls at Status > CARP. For times when a reboot is required on the primary, use the button to activate maintenance mode (2.2+) which will persist across restarts.
-
… you can demote the primary node using the controls at Status > CARP. For times when a reboot is required on the primary, use the button to activate maintenance mode (2.2+) which will persist across restarts.
But If the master fallback all changes are gone.
If the master is down for maintenance… for example one week. I mustn't enable/start this server, or all changes within this week are gone. Or have I a knot in my mind?
-
Yeah. Failover and config sync are two different things. If you make changes to the secondary (the one that receives configs from the primary) I can see things becoming undesirable. I would think a reasonable course of action would be to keep a log of the changes made while the primary is offline, then before putting primary back into production, bringing it up offline, duplicating the changes, then putting it back in service. You're talking about a pretty rare occurrence. One that might require some work.
If everything is synced (like all the checkboxes in the config sync area are checked) I don't see why you couldn't reverse the direction of the config sync and bring the other node back online (after disabling config sync in the other direction of course) but I've never done this.
-
At master-downtime it is a little bit difficult to write the changes down.
To reverse the replication I disable all syncs on the "config-master" (carp Sync + snort +…) and enable these syncs on the "config-slave". In my eyes this the promote. I hope this is the best practice in case of HW change or downtime for maintenance. -
All you need to do is note the changes made while the primary is offline. Restore your backup then enter the changes on the primary before you bring it back online. It will sync to the secondary but everything will be the same.
I have no idea if this is 3 changes or 3000. That obviously makes a difference. But, IMHO, if you're making 3000 firewall changes in a week you should have a ready spare to bring online as a replacement primary before making any changes to the secondary.
And I deal with pfSense without packages such as snort/squid. I have no idea how the HA sync works with those enabled.
-
There is no simple way to retain changes made to the secondary. If you try to sync them back to the primary later, other things may break unless you're careful (e.g. fix CARP VIP skews, DHCP failover IP addresses, etc)
If you know the primary node will be gone for quite some time, just grab a backup off both units, power it off, restore the primary backup file to the secondary, and now you just took your "secondary (formerly known as the primary)" is down for maintenance. :-) When the time comes to switch back, you could either restore the secondary node config to the repaired unit or swap them back around.
