Spam release using cluster (ASG320 V9.106)

Actually this is a little easier to do compared to the past. You have to make each unit MASTER one at a time if it is a HA Active/Active Cluster. Then check if the function fails on each unit until you find the units that have bad databases.

As an Example: if the mail postgresql table is toast; the summary stats on the mail manager tab will be blank. Or in this case the spam quarantine table will not release mail.

When you locate the bad unit; AND it is the master; then do a:

sudo /etc/init.d/postgresql92 rebuild

After the rebuild finishes that unit will be working again. Repeat with each unit looking for broken tables. Notice the command has changed with the most recent updates as postgresql was up rev'd. You should verify if you have /etc/init.d/postgresql92 before proceeding; or use the older command.



Sadly the recent bug with "preferred masters" cause many of our client mail databases to get torqued. We have all of ours fixed now. For completeness here is the process we used to fix it. At customer locations.

1) Connect; find the node in the best condition from what ever data we can scrounge from active mode. This is subjective base on experience. We usually go with the one with the best history data.
2) Make the best unit Master by rebooting the others.
3) From the HA Control panel. Set preferred to "none"
4) Wait 30 seconds.
5) From the HA Control panel "Shutdown" all units except the master
6) When each node is "dead" remove it.
7) Make sure "Enable automatic configuration of new devices" is turn on.
8) Boot one "dead" node.  Wait for it to join and finish syncing.
9) Repeat (8) each time the system gets to full "ACTIVE" state; until all nodes are running.

At this point your clusting is fixed and you just need to fix units that have torqued databases. Odds are you have at least one with a bad database; we had a minimum of 1 unit in every cluster that failed.

A) Make each unit master in turn and make sure you can view the mail-database and release spam. If you cannot then run the above rebuild command on that unit.
B) Repeat (B) until every unit works as master.

That is it; it is boring; it is slow; but it is easy and it will fix damage caused to the databases by the preferred master bug. I am not with the support team; but at this point only Alan in support has been around longer than me. Since I do not post often one of the regular gurus can verify my solution is a good one.  Normal disclaimers applies.

Actually this is a little easier to do compared to the past. You have to make each unit MASTER one at a time if it is a HA Active/Active Cluster. Then check if the function fails on each unit until you find the units that have bad databases.

As an Example: if the mail postgresql table is toast; the summary stats on the mail manager tab will be blank. Or in this case the spam quarantine table will not release mail.

When you locate the bad unit; AND it is the master; then do a:

sudo /etc/init.d/postgresql92 rebuild

After the rebuild finishes that unit will be working again. Repeat with each unit looking for broken tables. Notice the command has changed with the most recent updates as postgresql was up rev'd. You should verify if you have /etc/init.d/postgresql92 before proceeding; or use the older command.



Sadly the recent bug with "preferred masters" cause many of our client mail databases to get torqued. We have all of ours fixed now. For completeness here is the process we used to fix it. At customer locations.

1) Connect; find the node in the best condition from what ever data we can scrounge from active mode. This is subjective base on experience. We usually go with the one with the best history data.
2) Make the best unit Master by rebooting the others.
3) From the HA Control panel. Set preferred to "none"
4) Wait 30 seconds.
5) From the HA Control panel "Shutdown" all units except the master
6) When each node is "dead" remove it.
7) Make sure "Enable automatic configuration of new devices" is turn on.
8) Boot one "dead" node.  Wait for it to join and finish syncing.
9) Repeat (8) each time the system gets to full "ACTIVE" state; until all nodes are running.

At this point your clusting is fixed and you just need to fix units that have torqued databases. Odds are you have at least one with a bad database; we had a minimum of 1 unit in every cluster that failed.

A) Make each unit master in turn and make sure you can view the mail-database and release spam. If you cannot then run the above rebuild command on that unit.
B) Repeat (B) until every unit works as master.

That is it; it is boring; it is slow; but it is easy and it will fix damage caused to the databases by the preferred master bug. I am not with the support team; but at this point only Alan in support has been around longer than me. Since I do not post often one of the regular gurus can verify my solution is a good one.  Normal disclaimers applies.