Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

primary database not found on 2.19 #878

Closed
marco44 opened this issue Nov 20, 2019 · 6 comments
Closed

primary database not found on 2.19 #878

marco44 opened this issue Nov 20, 2019 · 6 comments

Comments

@marco44
Copy link
Contributor

marco44 commented Nov 20, 2019

Hi, I'm having this error on a just-migrated 2.19 pgbackrest (from 2.18, that worked), during a check command.

If I understand the code correctly, my configuration fails on a standby database for which repoIsLocal. repoIsLocal being defined as !cfgOptionTest(cfgOptRepoHost)

I don't have a repo host, as it's a S3 storage. But I'm wondering about this test anyway: why check that the primary is on the same machine ? There are so many ways that we could have a standby database with no primary database, such as a NFS or CIFS storage.

Here is may configuration, for reference...

[11-main
pg1-path=/mnt/secure/11/main
pg1-port=5433

[global]
compress-level=3
archive-async=y
archive-get-queue-max=4294967296
process-max=8
repo1-cipher-pass=xxxxxxxxxxxxxxxxxxxxxxxx
repo1-cipher-type=aes-256-cbc
repo1-path=/pgbackrest
repo1-s3-bucket=pgbackrest_bucket
repo1-s3-endpoint=s3.amazonaws.com
repo1-s3-key=yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy
repo1-s3-key-secret=zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz
repo1-s3-region=us-east-1
repo1-type=s3
spool-path=/mnt/secure/main/spool/
@dwsteele dwsteele self-assigned this Nov 20, 2019
@dwsteele dwsteele added this to the 2.20 milestone Nov 20, 2019
@dwsteele
Copy link
Member

So you are doing backups from the primary? It looks like check thinks that backups are running from the standby (which requires a primary) but backup-standby is not set, so not sure why.

@dwsteele dwsteele assigned cmwshang and unassigned dwsteele Nov 20, 2019
@marco44
Copy link
Contributor Author

marco44 commented Nov 20, 2019

We are also doing backups on the primary. But here, we are only setting up pgbackrest to be able to backup on all nodes, in case of a later switchover (so we don't have to deploy and setup pgbackrest in a rush the day we have an incident, or in case we need to do a restore). We only have the standby node on the server we are doing this test. On 2.18, doing a pgbackrest check didn't fail here.

@dwsteele
Copy link
Member

So you wouldn't be doing a backup on this host until after a failover. That's why backup-standby is not set.

OK -- we'll have a look at it.

@marco44
Copy link
Contributor Author

marco44 commented Nov 20, 2019

That's right. Thanks a lot.

@dwsteele
Copy link
Member

@cmwshang I think it's OK to allow a standby to pass check if backup-standby=n (the default). In this case there's about zero check can do (like test archive-push) but it should at least succeed.

@dwsteele dwsteele modified the milestones: 2.20, 2.21 Dec 13, 2019
@dwsteele dwsteele modified the milestones: 2.21, 2.22 Jan 16, 2020
feikesteenbergen added a commit to timescale/helm-charts that referenced this issue Jan 17, 2020
The check command of pgBackRest used to succeed on the replica, but this
behaviour changed recently [1] and will be ok in the long term.

This commit is a workaround for this change, and will only check the
backup stanza when running as primary.

Addresses issues #83 and #93

1: pgbackrest/pgbackrest#878
feikesteenbergen added a commit to timescale/helm-charts that referenced this issue Jan 17, 2020
The check command of pgBackRest used to succeed on the replica, but this
behaviour changed recently [1] and will be ok in the long term.

This commit is a workaround for this change, and will only check the
backup stanza when running as primary.

Addresses issues #83 and #93

1: pgbackrest/pgbackrest#878
feikesteenbergen added a commit to timescale/helm-charts that referenced this issue Jan 21, 2020
The check command of pgBackRest used to succeed on the replica, but this
behaviour changed recently [1] and will be ok in the long term.

This commit is a workaround for this change, and will only check the
backup stanza when running as primary.

Addresses issues #83 and #93

1: pgbackrest/pgbackrest#878
@dwsteele dwsteele modified the milestones: 2.22, 2.23, 2.24 Jan 23, 2020
@dwsteele dwsteele removed this from the 2.24 milestone Mar 6, 2020
@dwsteele dwsteele assigned dwsteele and unassigned cmwshang May 21, 2021
@dwsteele
Copy link
Member

We've made a lot of improvements to configuration in this area so closing. If this can reproduced on a recent version please let us know.

@github-actions github-actions bot locked and limited conversation to collaborators Oct 23, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants