Improved Postgres Clustering with repmgr - Preview

Hi @shaun! I’ve upgraded to the v0.0.34. It started showing the database size on the dashboard, though it’s a weird number. Is it the sum of sizes of all instances?

If it is, it’s not super helpful, as it doesn’t answer the following questions:

  1. Am I running out of space on my db volumes? (currently I have 3 nodes with 15 gb volume each and db size shows 17 gb)
  2. What is the actual size of my db?
  3. Is it growing too rapidly? (I assume it would show up 3x inflated)

If it supposed to be like that then the metric should probably be renamed to reflect the actual meaning.

Also, it makes me wonder if other metrics are also aggregate values of all instances.

ps. Sorry for bugging that often. That’s the result of me actually relying on the service

No problem at all. Can you post a screenshot on what you’re seeing?

If you connect to your database via fly pg connect --app <app-name>, you can run \l+ to confirm the sizes.

I was able to reproduce the issue. Weird. I’ll see what I can do about it. Thanks for reporting it!

1 Like

It would be great if there was a smaller PG option with HA. Something like “Light Production” or at least if we could chose 1GB or 2GB of RAM with the custom config.

Right now it’s either a dev instance… or a full blown 3 nodes with 2x CPUs, 4GB of RAM, and 40GB of disk. It’s really overkill for apps just starting out that still need HA.

With a custom config but it’s either 1 CPU with 256MB of RAM or 2 CPUs with 4GB of RAM.

@pier you can do custom, i have 3 nodes, 2x cpu each, 2 gb ram, 15 gb hd each

How do you select custom RAM? from what I can see the RAM is tied with the CPU config.

@pier you can modify ram and cpu later via fly machine update. I start with one node, set memory and cpu, import my data, and then clone it into 3

1 Like

Thanks I will try that! I thought these configs were fixed somehow :sweat_smile:

They are just starting presets

@pier it’s fly machine update <id> --memory 2048 -a app-db.

Then I migrate my data and use fly machine clone <id> -a app-db twice and they become a cluster

PS. I agree this should be mentioned in the pg setup prompt.

3 Likes

How was this promoted from a preview without WALG support? On top of that the --stolon option, at least in flyctl v0.0.495 doesn’t even work.

IMHO this change should have not only been communicated more effectively, it should never have been promoted from preview until WALG support was included. I’m now stuck in a position where I can’t implement our backup strategy on our new production cluster because proper support for backing up Postgres has been removed.

@LeoAdamek I would be helpful if you let us know what kind of issues you are seeing provisioning with the --stolon flag.

Also, if things are not working be sure to update to the latest flyctl version.

The --stolon flag has no effect, its completely ignored.

Got it, we will take a look at that. In the mean time, as a workaround, you can specify the image-ref at provision time.

fly pg create --image-ref flyio/postgres:14 --initial-cluster-size 2 ...

Sorry for the issues

@LeoAdamek The --stolon flag issue has been fixed as part of flyctl v0.0.498. I just kicked off the build, so it may take a few minutes.

2 Likes

Were you able to root cause this or find a solution/workaround? The pg_replication_lag metric is empty for all of our new repmgr clusters on Apps V2 (which other than that are working beautifully). The volume size metric is working fine though.

Is there a way to migrate a v2 app that is using the normal flyio/postgres image to this flyio/postgres-flex image?

You can use our Postgres Import Feature to migrate your data from one Stolon-based PG app to a new PG Flex app.

1 Like