☰

Kubernetes InnoDBCluster: все модули должны иметь один PersistentVolumeClaim?

tag-icon • tag-icon kubernetes mysql-replication innodb mysql-cluster
Kubernetes InnoDBCluster: все модули должны иметь один PersistentVolumeClaim?

Kubernetes InnoDBCluster: все модули должны иметь один PersistentVolumeClaim?

Следующий:https://dev.mysql.com/doc/mysql-operator/en/mysql-operator-innodbcluster-simple-kubectl.html

kubectl create namespace mysql-cluster-test
kubectl create secret generic mypwds \
  --from-literal=rootUser=root \
  --from-literal=rootHost=% \
  --from-literal=rootPassword=123456 -n mysql-cluster-test
kubectl apply -f mycluster.yaml -n mysql-cluster-test

Kubectl получить pods -n mysql-cluster-test

NAME                                READY   STATUS    RESTARTS   AGE
mycluster-0                         2/2     Running   0          12m
mycluster-1                         2/2     Running   0          12m
mycluster-2                         2/2     Running   0          12m
mycluster-router-5d87fbd754-zhsrh   1/1     Running   0          10m

kubectl получить pvc -n mysql-cluster-test

NAME                  STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
datadir-mycluster-0   Bound    pvc-b3bf5f24-99d0-4497-bd34-fd91eb4adc6c   2Gi        RWO            hostpath       8m9s
datadir-mycluster-1   Bound    pvc-1c042c50-bc3f-43f8-8e16-094042495e6d   2Gi        RWO            hostpath       8m9s
datadir-mycluster-2   Bound    pvc-85fbf9f9-d975-4899-a292-d247644cb2d2   2Gi        RWO            hostpath       8m9s

Есть 3 mysql POD, каждый из которых имеет свой собственный PVC и привязан к разным Volumes. Данные Mysql должны храниться в одном томе. Должны ли все POD совместно использовать один PVC?

решение1

Есть 3 mysql POD, каждый из которых имеет свой собственный PVC и привязан к разным Volumes. Данные Mysql должны храниться в одном томе. Должны ли все POD совместно использовать один PVC?

MySQL (и другие базы данных SQL) не созданы для работы с общим хранилищем. Если вам нужно больше одного экземпляра, то каждому экземпляру нужно свое собственное выделенное хранилище. В конфигурации кластера каждый экземпляр использует некоторую форму репликации, чтобы поддерживать свою локальную копию в актуальном состоянии с другими членами кластера.

Это, как правило, то, что вам нужно, даже если вымогиспользуйте один общий PV, потеря PV будет означать, что вы потеряете все свои данные. Используя репликацию, другой экземпляр в кластере может взять на себя основную роль (или может продолжать предоставлять доступ, если у вас есть несколько реплик чтения/записи).

Тымогиспользуйте один том, а затем отдельный каталог для каждого экземпляра, но, как было отмечено ранее, это сделает ваше хранилище единой точкой отказа (а также единой точкой конфликта ввода-вывода).

Будет ли удалено локальное хранилище при удалении модуля?

Если вы используете эфемерное хранилище для базы данных, то да. Если вы поместите базу данных, хранящуюся на (не-shared) PV, то нет. Использование PV для хранения обычно является наилучшим планом; в случае перезапуска Pod (например, при обновлении версий) это минимизирует объем данных, которые необходимо передать для повторной синхронизации реплики.

Связанный контент