3 ms·

Very funny. Also, you can actually make it cost competitive if the object you store is the last n milliseconds of packets instead of one packet each. So, inste

by Veserv 3y ago

Very funny. Also, you can actually make it cost competitive if the object you store is the last n milliseconds of packets instead of one packet each. So, instead of incurring two API calls per packet, you incur two API calls per minimum buffering time. If S3 is zero-rated for any ingress/egress then you get “infinite” bandwidth for 4.22$ * 3 (for the active case) = 12.66$ a day if you are willing to accept 500 ms minimum latency, or ~600$ a day at a more reasonable 10 ms. If you are saturating even just a 1 Gb link for a whole day that is ~10,000 GB which would be ~700$ via the blessed channel, so you could very well come out ahead. You could do even better if you out-of-band signal the readiness so you do not need to poll while idle. Then you only incur a cost while actively transmitting so as long as you average 1 Gb/s on the channel you should be coming out even or ahead with minimal latency impact.

derefr 3y ago
This isn't theoretical; many companies do PostgreSQL async 1:N physical replication, by using e.g. https://pgbackrest.org/ https://pgbackrest.org/ to have the primary push WAL segment files (a.k.a. "the last n milliseconds of packets" in the write-ahead log) as objects to S3. All the read-replicas then independently discover the new objects in S3 as they become available; fetch them; and replay them. > You could do even better if you out-of-band signal the readiness so you do not need to poll while idle. S3 and its clones have "object lifecycle notifications", where you can be informed by a push-based mechanism whenever a new object is put into the bucket. But — what do you have to do, to get these notifications? Subscribe to a real message queue, that S3 puts these notifications into. So using it here would be somewhat cheating ;)
- candiddevmike 3y ago
  Can you failover/promote using pgbackrest?
  - dikei 3y ago
    Not really, but you can use Patroni for that, which automatically promote one of your replica to master, it can also create the replica from WAL archive in S3 using wal-g/pgbackrest.
- Karrot_Kream 3y ago
  Yup we do something very similar for MySQL replication ourselves.
KRAKRISMOTT 3y ago
Try it with CloudFlare's S3 equivalent offering

by Veserv 3y ago

derefr 3y ago

This isn't theoretical; many companies do PostgreSQL async 1:N physical replication, by using e.g. https://pgbackrest.org/ https://pgbackrest.org/ to have the primary push WAL segment files (a.k.a. "the last n milliseconds of packets" in the write-ahead log) as objects to S3. All the read-replicas then independently discover the new objects in S3 as they become available; fetch them; and replay them. > You could do even better if you out-of-band signal the readiness so you do not need to poll while idle. S3 and its clones have "object lifecycle notifications", where you can be informed by a push-based mechanism whenever a new object is put into the bucket. But — what do you have to do, to get these notifications? Subscribe to a real message queue, that S3 puts these notifications into. So using it here would be somewhat cheating ;)

candiddevmike 3y ago
Can you failover/promote using pgbackrest?
- dikei 3y ago
  Not really, but you can use Patroni for that, which automatically promote one of your replica to master, it can also create the replica from WAL archive in S3 using wal-g/pgbackrest.
Karrot_Kream 3y ago
Yup we do something very similar for MySQL replication ourselves.

KRAKRISMOTT 3y ago

Try it with CloudFlare's S3 equivalent offering