When you perform an upgrade/update to any module in FreePBX (even a minor one) there is the possibility that FreePBX will change the structure of the tables in MySQL. Since HAAst will (intentionally) not sync metadata (SQL structures), you must ensure that the peers do not attempt to synchronize data during such an upgrade/update.
The Maintenance and Operations Guide shows the complete upgrade procedure (see section 6). But if you are very experienced with Linux & FreePBX, you can follow this short-cut:
- Upgrade A
- Unplug the network connection from A
- Upgrade FreePBX on A
- Upgrade B
- Unplug the network connection from B
- Replug the network connection to A
- Upgrade FreePBX on B
- Re-establish cluster
- Replug the network connection from B
- Wait for the cluster to HAAst restablish automatically
- Use the telnet/web interface to make the preferred peer active. (Or wait for automatic fallback during the maintenance window if enabled in the haast.conf file)
The key concept here is that a standby peer must NOT be able to see an active peer which is running a different version (or different modules installed/enabled) of the configuration generator.
Note that this applies only to FreePBX. Other configuration generators do a much better job managing settings and keeping settings-code aligned.
