I have a statefulset which has 3 replicas of mysql pods. Why it is not recommended to share the same backend storage/PV among these 3 replicas. Why each pod has its own pvc and pv.
This approach is recommended
What is the problem with this approach
I searched a lot for this, but didn't get any appropriate answer. Can anyone explain this to me.
I have a statefulset which has 3 replicas of mysql pods. Why it is not recommended to share the same backend storage/PV among these 3 replicas. Why each pod has its own pvc and pv.
This approach is recommended
What is the problem with this approach
I searched a lot for this, but didn't get any appropriate answer. Can anyone explain this to me.
Share Improve this question asked Jan 17 at 15:24 hello_ubuntuhello_ubuntu 14 bronze badges 1- Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. – Community Bot Commented Jan 17 at 15:58
1 Answer
Reset to default 1Sharing files is more challenging than it sounds. This isn't anything specific to MySQL, or even to containers: if you have multiple processes trying to read or write the same file, there's a risk that one process will overwrite the data that another's trying to write. Databases tend to use complex binary file formats, and so if one process is trying to write data while another is updating an index, you'll get a corrupted file. There are also some hidden bad things that can happen if the data is crossing a network, and packets get lost or delayed or corrupted in flight.
One typical protection against this – again, not specific to containers – is to write a lock file into the data store. Assuming all of the processes cooperate, this ensures that only one copy of the application can use a given file store. This is particularly common among databases: if you have two copies of MySQL that are trying to use the same physical storage, one of them just won't start up.
Let's say you're using a database like MongoDB or Elasticsearch that's conscious of this, and is able to run multiple copies of itself. You might configure Elasticsearch to have five replicas. Any given datum will be stored in two of them, so if a single replica fails the data can be replicated back to a node that's still alive. But this setup means that each replica needs its own independent data store.
This is the setup that a StatefulSet is aiming towards: you have multiple replicas, each needs its own independent data volume, but the in-process logic knows how to route requests to the right place to find the data.
Assuming your cluster can create a ReadWriteMany volume (these can be a little tricky to come by) and you can tolerate both concurrent writes and network hiccups, you could independently create a volume and mount it into multiple replicas of a Deployment. A StatefulSet wouldn't manage these, though. If you needed other properties of a StatefulSet like ordered replicas with consistent names, you could mount the RWX volume into StatefulSet replicas too, but it wouldn't be part of the volumeClaimTemplates:.