-
-
Notifications
You must be signed in to change notification settings - Fork 60
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
v1.91.0 DB Crash #55
Comments
I ran into this as well. For what it is worth, in the meantime, I was able to resolve this by creating the missing config file "/bitnami/postgresql/data/postgresql.conf" and "/bitnami/postgresql/data/pg_hba.conf". I simply took a default config file and it allowed the database to come back online. |
Thanks @inglemr Inevitably I needed the following: postgresql.conf
pg_hba.conf
I tried using the default in the bitnami images:
And while postgres came online, the other services couldn't connect to it. So I modified the above to include the changes I first mentioned. If that's all you do, you'll need to also ensure a
And to copy the local file to the pod:
|
Same for me. Described solution also worked. However immich-server still expects TYPESENSE_API_KEY and crash loops....
|
This seems to be caused by using a docker images based on postgres/postgres and injecting it into a chart dependency that expects a bitnami version. |
I had to mod this a little to match my pod CIDR, and put "password" instead of "md5" since the server kept nagging about no pg_hba.conf entry for "no encryption" |
This one caught me off guard too. The config paths are passed at Also, from what I see, it seems that the default UID is different: postgresql:
image:
repository: tensorchord/pgvecto-rs
tag: pg16-v0.1.11
primary:
podSecurityContext:
fsGroup: 999
containerSecurityContext:
runAsUser: 999
volumePermissions:
enabled: true # By setting this, you make sure that the existing data get chmod'd to UID 999 |
As this is caused by replacing the used image, this might only be an issue for a migration to the 1.91+ immich release. |
Switching from a Bitnami to a normal PostgreSQL image is a really bad idea, every user that updates this Helm chart is going to run into this exact issue. This caught me off guard because there was no breaking change warning about this, only about Immich itself which mentions docker-compose but not Helm, and the section about 'normal' Postgres images also does not mention it. I'm looking into what needs to be done to fix this for myself, Edit: in the end I ended up rolling back the Helm chart to 0.2.0 and the immich tag to v1.90.2 . There is no easy way to install the pgvector.rs extension in the Bitnami image without also running PostgreSQL as root as far as I can see. |
quick repo I threw up with a bitnami compatible build of pgvecto.rs: https://github.com/SoarinFerret/bitnami-postgres-pgvecto-rs This does NOT run the PostgreSQL as root - so should fix your concerns @LordGaav if you update your postgressql:
image:
registry: ghcr.io
repository: soarinferret/bitnami-postgres-pgvecto-rs
tag: pg14.5-v0.1.11 you can update to the latest release. Hope this helps someone. I think long term my plan will be to stop running this in k8s, so I don't intend to keep the repo updated. Here is the dockerfile for anyone who may want to build themselves: ARG PGVECTORS_TAG=pg14-v0.1.11-amd64
ARG BITNAMI_TAG=14.5.0-debian-11-r6
FROM scratch as nothing
FROM tensorchord/pgvecto-rs-binary:${PGVECTORS_TAG} as binary
FROM docker.io/bitnami/postgresql:${BITNAMI_TAG}
COPY --from=binary /pgvecto-rs-binary-release.deb /tmp/vectors.deb
USER root
RUN apt-get install -y /tmp/vectors.deb && rm -f /tmp/vectors.deb && \
mv /usr/lib/postgresql/*/lib/vectors.so /opt/bitnami/postgresql/lib/ && \
mv usr/share/postgresql/*/extension/vectors* opt/bitnami/postgresql/share/extension/
USER 1001
ENV POSTGRESQL_EXTRA_FLAGS="-c shared_preload_libraries=vectors.so" |
Can confirm your image works @SoarinFerret , thanks. I only had to do |
I had some long hours of frustration with strange permissions errors, version mismatching and some issues with @SoarinFerret fix (don't get me wrong, thanks a lot for providing the image, I am not sure why it was not working me, it worked for other people). My more drastic fix was to perform a backup & restore:
I hope someone benefits from this. If you already have backups in place, this whole procedure can be done in under 10 minutes. Otherwise, you may need some back&forth (maybe some rolling back and trying again). Good luck! EDIT: DISCLAIMER: Those steps can break your installation and/or you can lose data, make sure to know what you are doing, make a backup before even trying, if you are not sure of the procedure train and dry-run it with a playground environment in order to try it in a safe manner, understand all the steps before attempting them, etc. |
How can you run those if the container is in a crash loop? |
@Nepoxx hacky, not sure if theres a better way, but I edit the StatefulSet container definition with:
Then do my changes, then remove the edit. |
Ufff .... there are so many things to unpack here. First of all, @ALL who are currently contributing to this thread: THANK YOU VERY MUCH 🙏 I finally found some time to upgrade my cluster apps and I knew that upgrading immich will be "a thing" which is why I did not do it for a while. Your comments and solutions were tremendous in helping me. Honestly, I don't like the inclusion of the database for immich in this chart. The Sub-Charts of Bitnami have no way of upgrading between major versions, so we inherited the breaking changes that will come with it. with #61 we'd start building our own database image which would lead to us making sure this is updated and maintained and again - still breaking changes between major versions. I did a LOT of manual steps to get the database for immich working, which included finding the correct pgvector image to use 🙈
This seems like there is an endorsement for an image to use as a database from the main project and I'd like us to use the same and/or have a collaborative effort to create an image on the main account of this project (rather than adding an Image to this Helm-Chart). I'd also like us to condense the "manual migration" from the bitnami chart to this new version in a CHANGELOG and introduce it as a breaking change to this chart. What are your thoughts about that? @bo0tzz you have any input? |
Sorry about the breaking change and the silence afterwards folks! Unfortunately the way we have the helm chart releases set up right now means there is very little testing, and also no easy way to communicate (breaking) changes. On top of that, I got lazy and did too little manual testing when making this breaking release. Like Jonas mentions, I'm also not a fan of including the database in this chart. On the other hand, I can see the argument for being able to deploy Immich easily without needing to set up several (postgres, redis) external dependencies manually. I'm not sure what the best way forward is, but if possible I would like to avoid needing to maintain a(nother) database image. The upstream pgvecto.rs image is perfectly good other than not playing nice with the bitnami postgres chart (for which I blame bitnami). Since we're running on kubernetes, there's also the option of database operators with for example https://github.com/tensorchord/cloudnative-pgvecto.rs (for cloudnative-pg) or https://github.com/chkpwd/cdpgvecto.rs (for crunchydata PGO). Finally, the release process of this chart needs to be improved as currently it just releases on every merge to |
Doesn't the chart help configure postgresql with the geodata-plugin etc.? I think for that reason it's convenient to include it, although I would personally not mind running my own bitnami-postgres alongside immich. |
If any of you have feedback on the proposal in #129, I'd love to hear it. |
Postgres Pod Crash:
Chart Values:
The postgres statefulset is appropriately configured with the following image:
Chart version:
immich-0.3.0
The text was updated successfully, but these errors were encountered: