Sporadic re-writes of the pgclustertab

Question

Sporadic re-writes of the pgclustertab

masc-online opened this issue 3 years ago · comments

Hi Trivadis,

In my environment, the pgclustertab is sometimes rewritten. So far I have not been able to identify a pattern of when this happens. So far, this has happened at least twice.

It always comes as a bit of a shock when all PostgreSQL clusters are displayed as DOWN after logging in to the server. The PGDATA directory is found correctly, port and PID are not despite running processes. In addition, new aliases are assigned automatically.

Possibly this happens when after a reboot of the server the PgOperate daemon tries to start up the PostgreSQL clusters, the startup is delayed a bit and I can already log in to the environment / source PgBasEnv. However, I cannot consciously reproduce the behaviour.

As a workaround, I have put aside a copy of the correct pgclustertab and will probably also adjust the permissions of the file so that a change is only possible manually by another user.

Best regards,
Marian

Roland Stirnimann · Answer 1 · Wed Aug 18 2021 22:11:23 GMT+0800 (China Standard Time)

Hello Marian

These rewrites/updates on pgclustertab are done by design. So this is not an unwanted behavior.
Of course, it should not happen that it writes some wrong information to the file.
Currently, we cannot reproduce the issue but we will keep an eye on it. Please let us know when you find out something.

Could it be that the PGDATA is located on an NFS share which is probably not yet available during the boot and pgBasEnv therefore is not able to detect everything properly?

Regards
Roland

Marian Schmöker · Answer 2 · Tue Sep 14 2021 18:56:19 GMT+0800 (China Standard Time)

Hi Roland,

The behaviour occurred with local disks (VMware disks) assigned to the machine - no network drives.
So far, the problem has not reoccurred (although the reboots of the corresponding servers are now at a minimum).

Regards,
Marian

cyrmue · Answer 3 · Fri Aug 12 2022 19:40:59 GMT+0800 (China Standard Time)

Hi
Yes we also had this problem one or two times after reboot.
We didn't dived to deep for analyse and just disabled autoscanning at source time (--noscan):
.pgbasenv_profile

. $PGBASENV_BASE/bin/pgsetenv.sh --noscan

and we do it manually when there is a cluster change (upgrade/create ....)

regards

Marian Schmöker · Answer 4 · Fri Aug 12 2022 20:19:19 GMT+0800 (China Standard Time)

We didn't dived to deep for analyse and just disabled autoscanning at source time (--noscan)

This also sounds like a possible workaround. I almost like it better than my variant (store a copy of the pgclustertab with a correct state and restore it if necessary).

Roland Stirnimann · Answer 5 · Thu Mar 23 2023 23:52:36 GMT+0800 (China Standard Time)

Latest release 2.2 has a changed behaviour in terms of instance discovery. New instances are discovered everytime but not deleted automatically. Means if an instance resp. its PGDATA becomes temporarily unavailable and someone executes pgbasenv at the same time the instance will not be deleted from pgclustertab. In case old obsolete entries should be cleaned out you can use the option --clean-pgclustertab.