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

timescaledb:2.14.2-pg16-bitnami does not work with readreplica nodes #231

Open
nleeuskadi opened this issue Feb 26, 2024 · 6 comments
Open

Comments

@nleeuskadi
Copy link

nleeuskadi commented Feb 26, 2024

Hello,

I am trying to use the bitnami/postgresql chart with your image [2.14.2-pg16-bitnami]

I want to install a cluster like this : 1 primary and 2 read replicas.

I execute this command:
helm install bitnami-tsdb oci://registry-1.docker.io/bitnamicharts/postgresql --version 14.2.2 --set 'image.repository=timescale/timescaledb' --set 'image.tag=2.14.2-pg16-bitnami' --set readReplicas.replicaCount=2 --set architecture=replication --namespace test-bitnami-tsdb

The primary succeeds to start but the read replica fail in a crashloopback.

I guess that the problem is the same as the one you solved with repmgr (commit ddd1609).
indeed, timescaledb tuning breaks not only standy nodes on repmgr cluster but it also breaks read replicas nodes on postgresql cluster.

My though is that you should disable timescale tune at all for any bitnami based image and not only for bitnami/postgresql-repmgr based image.

Here below the solution you implemented to disable Timescale tuning in case of bitmani/postgresql-repmgr based image
which should be generalize i think.

# Timescale tuning breaks standby nodes on repmgr clusters, so we disable it
# by default
if [ "$PG_BASE_IMAGE" == "postgresql-repmgr" ]
then
    export NO_TS_TUNE=true
fi

Thank you in advance for your help

best regards

Nicolas

@antekresic
Copy link

Hm, I don't have too much experience with helm charts but is it possible that you just use that env variable in order to disable timescaledb-tune support?

Would that make sense for you?

@nleeuskadi
Copy link
Author

Hi @antekresic ,

thank you for your answer. You are right with your solution.
But it is not applicable in my case since I am using the bitnami chart which does not use this NO_TS_TUNE var env.
And I don't wan't to modify the official community helm chart.

Since Timescaledb community provides a timescaledb image based on official Bitnami image, I am guessing that the intention of these images is also to be able to use it with Bitnami helm chart while taking advantage that Timescaledb is included in the official Bitnami image.

A fix was implemented for the images timescale/timescaledb:x.xx.x-pgxx-repmgr-bitnami (for example this one: https://hub.docker.com/layers/timescale/timescaledb/2.14.2-pg16-repmgr-bitnami/images/sha256-b15578c2688f7574557791cfc8eebd427d72bb9bc871773aaff037dd79a52766?context=explore) , and these images works fine now with the bitnami chart https://github.com/bitnami/charts/tree/main/bitnami/postgresql-ha.

Similarely, it could be of interest if the timescale/timescaledb:x.xx.x-pgxx-bitnami is also fixed to work natively with the offical Bitnami helm chart (https://artifacthub.io/packages/helm/bitnami/postgresql) without modify the Chart :)

many thanks :)

@Laurianti
Copy link

Laurianti commented Mar 26, 2024

The repmgr image is also not working correctly (it crashes at startup), but upon creating a new build, it works fine.

I think that the version 2.14.2 of TimescaleDB seems to have been built using a version of docker.io/bitnami/postgresql-repmgr:15 that likely contained an issue.

After forking and rebuilding version 2.14.2, the issues related to postgresql-repmgr no longer appear, suggesting the initial problem was tied to the specific version of postgresql-repmgr used at that time.

Given these findings, could the 2.14.2 version of TimescaleDB be re-builded?

The currently available version seems to be buggy due to this specific problem.

@svenklemm

@Laurianti
Copy link

Any update here?

@svenklemm
Copy link
Member

I've triggered a rebuild, new images should be available in an hour.

@Laurianti
Copy link

Thank, now it starts, but the creation of hypertable has a bug in this version.
I fixed it in a new PR:
#237

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants