PostgreSQL slaves should handle restarts properly and not delete userdata
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 25/100
- Issue type
- Bug
- Clarity
- Needs clarification
- Activity status
- Stale
- Tech stack
- postgresql
- Domain
- databases
Research direction
No files, tests, or entry points are named in the issue. Start by tracing the PostgreSQL slave restart and userdata cleanup behavior, then resolve which proposed strategy is acceptable; done means a restarting slave starts properly without deleting user data.
Written by the indexing model from the issue text.
Description
Currently, we have a problem that a restarting slave occasionally doesn't start up properly. The quick fix was rm -rf'ing userdata, so a started PostgreSQL process will replicate it anew from the master. It seems to me we could do better (and @praiskup didn't like our current solution). I asked our storage team, and they are of the opinion that making OpenShift/Kubernetes do the EmptyDir cleanup would not make much sense, since EmptyDirs are pod-specific.
Viable options that come to mind:
- Don't use a volume for the slave data, just a plain container directory. This might be problematic, since we might not be able to do quota space accounting later. It would be a very quick and easy solution, though, without risk of deleting user's data (unless he really wants to)
- Be intelligent about the deletion. Include some sort of "state" file that would make guarantees about the last known state of the data. This would be harder to implement and do right, but would provide additional benefit of reusing the data and saving some bandwidth.
cc @bparees @hhorak @mfojtik @rhcarvalho
- Dominant language
- PLpgSQL
- Stars
- 178
- Forks
- 220
- PR merge metrics
- No merged PRs in 30d
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from sclorg/postgresql-container
-
Difficulty 2/5 1-2 days Newbie friendliness 72/100
sclorg/postgresql-container#661 ·
-
Difficulty 3/5 1-2 days Newbie friendliness 68/100
sclorg/postgresql-container#669 · 1 comment ·
-
Difficulty 3/5 1-2 days Newbie friendliness 52/100
sclorg/postgresql-container#668 ·
-
Dockerfile failing Open
Difficulty 2/5 1-3 hours Newbie friendliness 55/100
sclorg/postgresql-container#656 ·
-
Difficulty 3/5 1-2 days Newbie friendliness 50/100
sclorg/postgresql-container#654 ·
All issues in sclorg/postgresql-container
Similar issues
-
bug: AI Gateway client filter lists "Unknown" twice when NULL and literal Unknown clients coexist Openbug
Difficulty 2/5 1-3 hours Newbie friendliness 90/100
-
[BUG] A column whose default is the empty string is drawn in the ER diagram as having no default Openbug database-provider good first issue hacktoberfest
Difficulty 2/5 1-3 hours Newbie friendliness 90/100
libredb/libredb-studio#1030 · 6 comments ·
-
comp-datalake
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
ClickHouse/ClickHouse#121222 ·
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
-
bug redshift
Difficulty 2/5 1-3 hours Newbie friendliness 88/100