4 ms·

Can you tell me how the storage there works when using their replica feature? Can I just provide it storage from a k8s-host and it replicates it to the hosts w

Can you tell me how the storage there works when using their replica feature? Can I just provide it storage from a k8s-host and it replicates it to the hosts where the other replicas live via software or do I need to provide it a StorageClass that supports distributed volumes? This is the one thing I cannot wrap my head around and apparently there isn't that much information (read benchmarks) on the implications of using different kinds of storages for databases on k8s (or at least I can't find anything)

motoboi 4y ago
In the cloud, volumes are just disks. They are attached to the instance were your pod get scheduled. You can in gke choose the disk type (IOPS). If configured like a daemonset, you are garanteed to always match disk to pod instance ordinal (postgres-0 get disk 0, postgres-1 get disk 1). So basically a way to run multiple postgres instances. But the devil is in the details.
- 5Qn8mNbc2FNCiVV 4y ago
  I know that, I was asking more about the specifics of the Crunchydata postgres operator since they have replication built-in. If it was just them using the volumes and doing the replication on the application level (not using k8s storage management, idk how to better describe it) it'd be easy. If they expect me however to provide a Storageclass that provides replication on top of the volumes it'd be more annoying. I could try this out myself to be honest, but I didn't quite get to it until now
  - knewter 4y ago
    Pg manages replication. If you use something like longhorn to replicate the volume you're just wasting storage - run pg replicas and stream Wal to object storage with wal-g, which the operator probably does (I user stackgres, and it does)
  - INTPenis 4y ago
    I think you misunderstand, crunchydata only deploys postgresql and provisions streaming replication between postgres nodes using patroni, which provisions the postgresql.conf necessary when you choose more than one replica in the PostgresCluster object definition.

motoboi 4y ago

In the cloud, volumes are just disks. They are attached to the instance were your pod get scheduled. You can in gke choose the disk type (IOPS). If configured like a daemonset, you are garanteed to always match disk to pod instance ordinal (postgres-0 get disk 0, postgres-1 get disk 1). So basically a way to run multiple postgres instances. But the devil is in the details.

5Qn8mNbc2FNCiVV 4y ago
I know that, I was asking more about the specifics of the Crunchydata postgres operator since they have replication built-in. If it was just them using the volumes and doing the replication on the application level (not using k8s storage management, idk how to better describe it) it'd be easy. If they expect me however to provide a Storageclass that provides replication on top of the volumes it'd be more annoying. I could try this out myself to be honest, but I didn't quite get to it until now
- knewter 4y ago
  Pg manages replication. If you use something like longhorn to replicate the volume you're just wasting storage - run pg replicas and stream Wal to object storage with wal-g, which the operator probably does (I user stackgres, and it does)
- INTPenis 4y ago
  I think you misunderstand, crunchydata only deploys postgresql and provisions streaming replication between postgres nodes using patroni, which provisions the postgresql.conf necessary when you choose more than one replica in the PostgresCluster object definition.