3 ms·

Thanks for the feedback. This is fully inclusive of machine prices, backups, everything. For redundancy there's two things. First is for data durability, we ar

Thanks for the feedback. This is fully inclusive of machine prices, backups, everything. For redundancy there's two things. First is for data durability, we archive all updates to S3 every 16 MB or 60 seconds whichever comes first, using WAL-E. Second, if you want higher availability you enable that. In that case, we run a streaming replica for all nodes in the cluster, those nodes receive updates as they happen. In the event of some failure (which we continuously monitor for) we automatically fail you over to the standby.

koolba 10y ago
> In the event of some failure (which we continuously monitor for) we automatically fail you over to the standby. Is there a transparent load balancer in front of the servers to handle that or would the master endpoint host change in the case of a failover? I noticed in the video that the database URL connected to is a raw EC2 hostname. Can't tell if it's a load balancer or the raw server though. In either case I'm assuming any connections in a pool would have to be re-opened (new TCP sockets) but updating the host for the DB is a bit more involved (and would require an app reboot) v.s. just allowing the connection pool to auto recover.
- fdr 10y ago
  All network addresses of every node is kept the same for-ever, even as they are replaced, via AWS Elastic IPs. The burden on the client application is to timeout and re-connect only.