Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
#1882 - Recovery and backup startegy patroni #2057
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
#1882 - Recovery and backup startegy patroni #2057
Changes from 13 commits
7a82c9e
633ab60
cf507e8
776fbd6
ef1537b
9d8e91d
1849c1e
b854b56
653f2ec
3c180d7
79b9f71
93fdd3c
a1644e8
be48c0c
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When this was mentioned "The backup.conf should be created for databases separately" does it means that they need to be created per database or per database type? For instance, Mongo/Postgres? In case we have a second DB on Postgres, do we need to create a second backup structure?
IMO, the answer to this question can help determine the variable's names.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah for seperate database not the database type, because individual databases can have different schedule of backups
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So, "The backup.conf should be created for databases separately" actually means that the backups can be configured for multiple databases but we are actually structuring it in a way that it will be per database assuming that a new database will have a different backup schedule, right?
Does it mean that in the future, if we have more than one DB, instead of a new line in a config file we will create a separate structure to handle the new backup?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes you got it right, that was the plan, as individual backup stratergy for different databases.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I went through the conversation @guru-aot @andrewsignori-aot .
@guru-aot what could be the benefit of having individual backup strategy per db?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this also include SIMS to be aligned with the other renamed variables?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i specifically did not add SIMS, becuase build is going to be same for all, but while deploying we can have multiple databases with different names.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
artifacts.developer.gov.bc.ca/docker-remote
is not the same asdocker.io
?Are we not supposed to be using the
artifacts
URL as much as possible (if not for everything)?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes you are right, but in this case, the build.yaml has been copied from the https://github.com/BCDevOps/backup-container/blob/master/openshift/templates/backup/backup-build.yaml. And the base image is actually not uses this too instead it uses quay.io/fedora/postgresql-14:14, as per the suggestion from the bcgov developer who did the changes to the dockerfile, which supports postgres 14.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@guru-aot does
artifacts.developer.gov.bc.ca/docker-remote/centos/postgresql-12-centos7:20200917-804ef01
work? as artifacts.developer.gov.bc.ca/docker-remote is just a proxy.Correct me if wrong.
IMO only if it does not work we should start thinking about docker.io IMO.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we claim that current backup supports postgres 14 with this image?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes it supports Postgres 14, as per the fedora postgres 14 base image
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are we removing the "_USER" because we will no longer support the backup for multiple DBs?
"_USER" reference: https://github.com/BCDevOps/backup-container/tree/master#backupconf
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we decide to move away from back-up of multiple db in same backup container?
If there is a requirement in future to have a another db, or we if decide to back up redis(by any chance) current way will be easily adaptable right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍