Corrupt AstDB file

First of all, make sure that HAast isn’t warning you of a real problem. Does your standby node have latency problems? Sever network/cpu/disk latency could easily cause a sync to fail. And if that’s a rare occurrence then that’s ok. But if it’s happening regularly then first check for hardware (or virtualization) issues.

Next, as you may already be aware, FreePBX is known to destroy the AstDB file for no good reason on rare occasions (i.e. it’s a bug that occurs rarely). See https://community.freepbx.org/t/corrupted-astdb-how-to-rebuild/4809 This problem has existed for many years customers have commented that Sangoma appears unable/unwilling/uninterested to resolve this. The nature of the problem is that Astdb file remains valid and whole (i.e. a valid SQLite 3 file), but critical information is missing or invalid in the database. Since HAast will try to apply changes to the AstDB upon sync, the sync may fail if the contents violate SQL relationship rules or other integrity constraints.

To pinpoint the cause, please enabled debug in the syncjob on the standby computer; for example, the file /etc/xdg/telium/haast.conf.d/asterisk.syncjob.conf might contain a syncjob called asterisk-db. Add the following line to that job:

asterisk-db/debug=on

And then restart HAast on the standby node. This will cause a detailed bug file to be created in the /var/tmp/haast directory. After a few automatic (or manual) starts of the asterisk-db sync job, please send that file to the support team and we will have more insight on what is going wrong.

In summary, the most likely cause is OUTSIDE of HAast. Experience has show that HAast will detect these errors and report them, but it doesn’t mean you have a HAast problem. If you are sure the hardware, Linux, and resources of the nodes are ok then starting debugging in HAast as described above.