search

Trivadis / pgbasenv

pgBasEnv - PostgreSQL Base Environment Tool
https://github.com/Trivadis/pgbasenv
Apache License 2.0
9 stars 3 forks source link

Sporadic re-writes of the pgclustertab #7

Closed masc-online closed 1 year ago

masc-online commented 3 years ago

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

rolandstirnimann commented 3 years ago

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

masc-online commented 3 years ago

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 commented 2 years ago

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

masc-online commented 2 years ago

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).

rolandstirnimann commented 1 year ago

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.