]> git.proxmox.com Git - pmg-api.git/commit
fix #5189: cluster: avoid sync errors for statistics and quarantine
authorFriedrich Weber <f.weber@proxmox.com>
Thu, 22 Feb 2024 16:35:35 +0000 (17:35 +0100)
committerStoiko Ivanov <s.ivanov@proxmox.com>
Thu, 22 Feb 2024 21:10:07 +0000 (22:10 +0100)
commitc8fa62e42412c92c97fd143a18a7704e4894193b
tree22ae43d618b0357ff313bbdcf4e912ba6594bbb5
parent8f67522b5e681c1a0449acc9ae40edf13c478039
fix #5189: cluster: avoid sync errors for statistics and quarantine

After restoring a backup from a cluster on a fresh node with
statistics, and then creating a cluster, the following can happen
(node 1 being master and node 2 being a node): `ClusterInfo` on node
1 has no record about the last-synchronized `CStatistic` row id of
node 2. Thus, pmgmirror on node 1 initializes the record with -1 and
tries to synchronize *all* `CStatistic` rows with cid 2 from node 2.
But (some of) these rows may already exist on cid 1, because they
were part of the backup, so pmgmirror on node 1 triggers a Postgres
unique constraint violation, statistics synchronization on node 1
fails, and node 1 remains in the "synchronizing" state.

Fix this as follows: When a new node is added to a cluster, the master
now initializes its `ClusterInfo` record of the last-synchronized
`CStatistic` row id for that node cid with the maximum row id that
exists in the local `CStatistic` for that node cid, or with -1 if the
local `CStatistic` has no row for that node cid. This is valid because
the newly-added node copies the master's `CStatistic` table during
cluster join.

Do the same for the `CMailStore` table, where a similar sync error
could happen e.g. if the table has rows for both node cids, node 2 is
shut down and manually deleted from the cluster.conf, the maxcid is
manually reset to 1, and a fresh node is joined to the cluster and
gets assigned cid 2.

Signed-off-by: Friedrich Weber <f.weber@proxmox.com>
src/PMG/DBTools.pm