[dead]
About synchronous disk replication
11–20 of 28 posts
Re: About synchronous disk replication
#12[dead]
Re: About synchronous disk replication
#13the problem with these solutions is how non-native they are to workloads. For zonal outages, you have to force-move things over. Even in k8s it doesn't seem like you can automatically failover statefulsets to another zone.
It feels better to me to have the replication at the data store level (e.g. database) rather than try and hide it under APIs that really aren't meant for it
Re: About synchronous disk replication
#14This would be great for a lot of purposes but still seems to fall short for operating a db in which you don’t want any data loss. Although it is called synchronous replication, it appears to be asynchronous. That is the primary disk will acknowledge writes while the secondary may not have acknowledged them. To make something synchronous usually requires 2 secondaries where writes occur on 2/3 disks total: this allows…
I see your point, but calling this synchronous doesn't seem any farther off than a caching raid controller replying before writing.
Re: About synchronous disk replication
#15This would be great for a lot of purposes but still seems to fall short for operating a db in which you don’t want any data loss. Although it is called synchronous replication, it appears to be asynchronous. That is the primary disk will acknowledge writes while the secondary may not have acknowledged them. To make something synchronous usually requires 2 secondaries where writes occur on 2/3 disks total: this allows…
Nope, this is in fact synchronous. It just degrades gracefully when one of the disaster domains is impacted. The main purpose here AIUI is availability, rather than durability.
For durability, you'll indeed want something like 3-way replication. But that's a distinct problem. If durability is your concern but you're fine with the availability SLOs of a single disaster domain, then you don't need regional replication.
Re: About synchronous disk replication
#16This would be great for a lot of purposes but still seems to fall short for operating a db in which you don’t want any data loss. Although it is called synchronous replication, it appears to be asynchronous. That is the primary disk will acknowledge writes while the secondary may not have acknowledged them. To make something synchronous usually requires 2 secondaries where writes occur on 2/3 disks total: this allows…
I see your point, but calling this synchronous doesn't seem any farther off than a caching raid controller replying before writing.
From linked article:
> If the disk replication status is catching up or degraded, then one of the zonal replicas is not updated with all the data. Any outage during this time in the zone of the healthy replica results in an unavailability of the disk until the healthy replica zone is restored.
There isn't a binary log that the replicas can catch up to, if the healthy disk goes down you are out of luck.
MySQL's semi-synchronous replication is "more synchronous" than this. If it's enabled it won't acknoledge a transaction until a replica has the transaction saved in it's binary log. Then the replica could be out of sync but if the master exploded, the slave would eventually catch up to the master using its own binary log.
I'm either misunderstanding Google's service here, because the name doesn't seem right.
Re: About synchronous disk replication
#17Earlier quoted context omitted.
This is replication between zones, not within a single zone.
The form would look like this: CREATE PERSISTENT DISK ---------------------- Replicas: W Zones to split replication across: X How many replicas must complete a write to allow the VM to continue: Y How many zones must complete a write to allow the VM to continue: Z With the above settings, you can expect approximately: Write latency 5-95%: 0.5-2.5 milliseconds Mean time to committed data loss: 37 years Mean time to fa…
And the customer support teams would waste countless hours debugging scenarios that the customer had no idea what they were doing. All of that with a SLO breathing down their neck.
Re: About synchronous disk replication
#18This would be great for a lot of purposes but still seems to fall short for operating a db in which you don’t want any data loss. Although it is called synchronous replication, it appears to be asynchronous. That is the primary disk will acknowledge writes while the secondary may not have acknowledged them. To make something synchronous usually requires 2 secondaries where writes occur on 2/3 disks total: this allows…
[deleted]
Re: About synchronous disk replication
#19I really don't know why Google doesn't just let users pick the how many copies to keep, and how many writes must be ACK'ed before the VM sees a write as complete. Then users can decide the cost vs reliability vs durability of data written milliseconds before an outage. Perhaps give users a web-based calculator where you can put the numbers, and see how much it would cost in $ per gb per day, the mean time to committe…
If you were a team working at Google internally, then yes you can pick these parameters. You can even pick between straight up replication versus Reed Solomon codes. I just don't understand why this is not exposed in their cloud offering.
> I just don't understand why this is not exposed in their cloud offering.
Probably because the mental model for the underlying implementation that you are basing this idea on does not accurately reflect the actual reality of the implementation.
As a very broad rule of thumb, whenever you find yourself saying, "Given , I don't understand ," you probably want to re-examine Thing A.
Re: About synchronous disk replication
#20Earlier quoted context omitted.
The form would look like this: CREATE PERSISTENT DISK ---------------------- Replicas: W Zones to split replication across: X How many replicas must complete a write to allow the VM to continue: Y How many zones must complete a write to allow the VM to continue: Z With the above settings, you can expect approximately: Write latency 5-95%: 0.5-2.5 milliseconds Mean time to committed data loss: 37 years Mean time to fa…
And the customer support teams would waste countless hours debugging scenarios that the customer had no idea what they were doing. All of that with a SLO breathing down their neck.
Easy enough to say "You had the replication parameters set to 1 replica, so data loss was expected every 1 month on average, and now some of your data has been lost. You can try to recover data with these opensource tools, or you can delete the disk and start again. We recommend replication of at least 1.15 to get a mean time between data loss of 150 years."