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.

Sign up for GitHub

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

Jump to bottom

Make sure the backup object store is empty when bootstrapping a new cluster #61

Closed
gbartolini opened this issue Apr 27, 2022 · 5 comments · Fixed by #83
Closed

Make sure the backup object store is empty when bootstrapping a new cluster #61

gbartolini opened this issue Apr 27, 2022 · 5 comments · Fixed by #83
Assignees
@jlong49
Labels
bug 🐛 Something isn't working
Milestone
2022-Q2

Comments

@gbartolini
Copy link
Contributor

When bootstrapping a new cluster from a recovery object store, and the target cluster has a backup object store configured, invoke barman-cloud-check-wal-archive to make sure that the destination backup object store is empty.

This prevents users from erroneously overwrite an existing object store. The same concept can be probably extended to any bootstrap phase.
@gbartolini gbartolini added the bug 🐛 Something isn't working label Apr 27, 2022
@gbartolini gbartolini added this to the 2022-Q2 milestone Apr 27, 2022
@sxd sxd self-assigned this Apr 27, 2022
@sxd
Copy link
Member

sxd commented Apr 27, 2022

@gbartolini I found an issue, we can't check the "future" object store from the operator since we don't have the barman-cloud-check-wal-archive command, this can only run inside a cluster already created, meaning that we can check during the init job only, and that will create at least one pod, it's that solution ok with you? It's the only solution I can see by now since only those container will have the Barman tools we need.

sxd added a commit that referenced this issue Apr 27, 2022
@sxd
chore: prevents to bootstrapping a new cluster with a non-empty objec…
ad6794f 
…t store

The idea behind this patch it's to prevent any cluster boostrapping
if case the target ObjectStore it's already used by another backup
or it's not empty at all, thuse, we can prevent the overwrite of
clusters backups and misunderstanding in the PostgreSQL timeline
when trying to recover a pod.

Closes #61

Signed-off-by: Jonathan Gonzalez V <jonathan.gonzalez@enterprisedb.com>
@sxd
Copy link
Member

sxd commented Apr 28, 2022

@gbartolini After talking with @mnencia I have a cleared idea and I'll be moving this soon

sxd added a commit that referenced this issue Apr 28, 2022
@sxd
chore: prevents to bootstrapping a new cluster with a non-empty objec…
9be085a 
…t store

The idea behind this patch it's to prevent any cluster boostrapping
if case the target ObjectStore it's already used by another backup
or it's not empty at all, thuse, we can prevent the overwrite of
clusters backups and misunderstanding in the PostgreSQL timeline
when trying to recover a pod.

Closes #61

Signed-off-by: Jonathan Gonzalez V <jonathan.gonzalez@enterprisedb.com>
@NiharDudam
Copy link

I believe #62 (comment) applies to this issue as well?

@jsilvela jsilvela mentioned this issue May 2, 2022
Closed
sxd added a commit that referenced this issue May 2, 2022
@sxd
chore: prevents to bootstrapping a new cluster with a non-empty objec…
1cfae7d 
…t store

The idea behind this patch it's to prevent any cluster boostrapping
if case the target ObjectStore it's already used by another backup
or it's not empty at all, thuse, we can prevent the overwrite of
clusters backups and misunderstanding in the PostgreSQL timeline
when trying to recover a pod.

Closes #61

Signed-off-by: Jonathan Gonzalez V <jonathan.gonzalez@enterprisedb.com>
sxd added a commit that referenced this issue May 2, 2022
@sxd
chore: prevents to bootstrapping a new cluster with a non-empty objec…
9192ea2 
…t store

The idea behind this patch it's to prevent any cluster boostrapping
if case the target ObjectStore it's already used by another backup
or it's not empty at all, thuse, we can prevent the overwrite of
clusters backups and misunderstanding in the PostgreSQL timeline
when trying to recover a pod.

Closes #61

Signed-off-by: Jonathan Gonzalez V <jonathan.gonzalez@enterprisedb.com>
@sxd sxd mentioned this issue May 2, 2022
Merged
@sxd sxd removed their assignment May 2, 2022
@jsilvela jsilvela assigned jsilvela and unassigned jsilvela May 4, 2022
@jsilvela
Copy link
Contributor

jsilvela commented May 4, 2022

Taking the issue back - I think I can add a quick E2E

@jsilvela jsilvela removed their assignment May 5, 2022
@jsilvela jsilvela mentioned this issue May 5, 2022
Closed
@jsilvela
Copy link
Contributor

jsilvela commented May 5, 2022

I have added an issue to add E2E tests for the new backup + restore scenarios.
For the moment this PR could be tested manually. Moving to second review.

jlong49 pushed a commit that referenced this issue May 5, 2022
@sxd @jlong49
chore: prevents to bootstrapping a new cluster with a non-empty objec…
d38ec2e 
…t store

The idea behind this patch it's to prevent any cluster boostrapping
if case the target ObjectStore it's already used by another backup
or it's not empty at all, thuse, we can prevent the overwrite of
clusters backups and misunderstanding in the PostgreSQL timeline
when trying to recover a pod.

Closes #61

Signed-off-by: Jonathan Gonzalez V <jonathan.gonzalez@enterprisedb.com>
jlong49 pushed a commit that referenced this issue May 6, 2022
@sxd @jlong49
chore: prevents to bootstrapping a new cluster with a non-empty objec…
c8bae72 
…t store

The idea behind this patch it's to prevent any cluster boostrapping
if case the target ObjectStore it's already used by another backup
or it's not empty at all, thuse, we can prevent the overwrite of
clusters backups and misunderstanding in the PostgreSQL timeline
when trying to recover a pod.

Closes #61

Signed-off-by: Jonathan Gonzalez V <jonathan.gonzalez@enterprisedb.com>
jlong49 pushed a commit that referenced this issue May 6, 2022
@sxd @jlong49
chore: prevents to bootstrapping a new cluster with a non-empty objec…
153d268 
…t store

The idea behind this patch it's to prevent any cluster boostrapping
if case the target ObjectStore it's already used by another backup
or it's not empty at all, thuse, we can prevent the overwrite of
clusters backups and misunderstanding in the PostgreSQL timeline
when trying to recover a pod.

Closes #61

Signed-off-by: Jonathan Gonzalez V <jonathan.gonzalez@enterprisedb.com>
jlong49 pushed a commit that referenced this issue May 9, 2022
@sxd @jlong49
chore: prevents to bootstrapping a new cluster with a non-empty objec…
4a7f1b6 
…t store

The idea behind this patch it's to prevent any cluster boostrapping
if case the target ObjectStore it's already used by another backup
or it's not empty at all, thuse, we can prevent the overwrite of
clusters backups and misunderstanding in the PostgreSQL timeline
when trying to recover a pod.

Closes #61

Signed-off-by: Jonathan Gonzalez V <jonathan.gonzalez@enterprisedb.com>
mnencia pushed a commit that referenced this issue May 10, 2022
@sxd @mnencia
chore: prevents to bootstrapping a new cluster with a non-empty objec…
be48d40 
…t store

The idea behind this patch it's to prevent any cluster boostrapping
if case the target ObjectStore it's already used by another backup
or it's not empty at all, thuse, we can prevent the overwrite of
clusters backups and misunderstanding in the PostgreSQL timeline
when trying to recover a pod.

Closes #61

Signed-off-by: Jonathan Gonzalez V <jonathan.gonzalez@enterprisedb.com>
mnencia pushed a commit that referenced this issue May 10, 2022
@sxd @jsilvela
chore: prevents to bootstrapping a new cluster with a non-empty objec…
7a81315 
…t store (#83)

The idea behind this patch it's to prevent any cluster bootstrapping
if case the target ObjectStore it's already used by another backup
or it's not empty at all, thus, we can prevent the overwrite of
clusters backups and misunderstanding in the PostgreSQL timeline
when trying to recover a pod.

Closes #61

Signed-off-by: Jonathan Gonzalez V <jonathan.gonzalez@enterprisedb.com>
Signed-off-by: Jaime Silvela <jaime.silvela@enterprisedb.com>
Co-authored-by: Jaime Silvela <jaime.silvela@enterprisedb.com>
@jsilvela jsilvela mentioned this issue May 12, 2022
Closed
mnencia added a commit that referenced this issue Dec 29, 2022
@litaocdl @mnencia
fix: improve handling of enterprisedb/postgresql repository (#61)
acd7f02 
Signed-off-by: Tao Li <tao.li@enterprisedb.com>
Signed-off-by: Marco Nenciarini <marco.nenciarini@enterprisedb.com>
Co-authored-by: Marco Nenciarini <marco.nenciarini@enterprisedb.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@jlong49 jlong49

Labels
bug 🐛 Something isn't working
Projects
CloudNativePG operator development
Archived in project
Milestone
2022-Q2
5 participants
@gbartolini @jsilvela @sxd @jlong49 @NiharDudam