Хорошо, поэтому я использую модифицированную версию этого репо: https://github.com/CaptTofu/mysql_replication_kubernetes/tree/master/galera_sync_replication
измененные файлы:
сервис:
apiVersion: v1
kind: Service
metadata:
name: ro-db
labels:
unit: pxc-cluster
spec:
ports:
- port: 3306
name: mysql
selector:
unit: pxc-cluster
pxc1, этотот же контроллер репликации, сервис для обнаружения и постоянный том, требующийся для 2 и 3, просто меняя числа
apiVersion: v1
kind: Service
metadata:
name: pxc-node1
labels:
node: pxc-node1
spec:
ports:
- port: 3306
name: mysql
- port: 4444
name: state-snapshot-transfer
- port: 4567
name: replication-traffic
- port: 4568
name: incremental-state-transfer
selector:
node: pxc-node1
---
apiVersion: v1
kind: ReplicationController
metadata:
name: pxc-node1
spec:
replicas: 1
template:
metadata:
labels:
node: pxc-node1
unit: pxc-cluster
spec:
nodeSelector:
number: '1'
containers:
- image: capttofu/percona_xtradb_cluster_5_6:beta
name: pxc-node1
ports:
- containerPort: 3306
- containerPort: 4444
- containerPort: 4567
- containerPort: 4568
env:
- name: GALERA_CLUSTER
value: "true"
- name: WRSEP_ON
value: "true"
- name: WSREP_CLUSTER_ADDRESS
value: gcomm://
- name: WSREP_SST_USER
value: sst
- name: WSREP_SST_PASSWORD
value: sst
- name: MYSQL_USER
value: mysql
- name: MYSQL_PASSWORD
value: mysql
- name: MYSQL_ROOT_PASSWORD
value: c-krit
volumeMounts:
- name: mysql-persistent-storage-1
mountPath: /var/lib
securityContext:
capabilities: {}
privileged: true #privileged required for mount
volumes:
- name: mysql-persistent-storage-1
persistentVolumeClaim:
claimName: claim-galera-1
---
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: claim-galera-1
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 4Gi
selector:
matchLabels:
name: pxc1
Дело в том, что он работал несколько дней назад и провел много испытаний, приводя к остановке модулей, узлов ипосмотрите, как работало голосование с репликацией и все, теперь, когда я интегрируюсь в приложение, оно просто не запускается, и я не могу понять, почему, если работает та же конфигурация, я много смотрел в Интернете,ТАК, GitHub и попробовал предложенные исправления, но не будет работать.
2018-10-23 20:36:46 1 [Note] WSREP: (4be59ce1, 'tcp://0.0.0.0:4567') turning message relay requesting on, nonlive peers: tcp://10.244.2.61:4567
2018-10-23 20:36:47 1 [Note] WSREP: forgetting 49c4d2cf (tcp://10.244.2.61:4567)
2018-10-23 20:36:47 1 [Note] WSREP: (4be59ce1, 'tcp://0.0.0.0:4567') turning message relay requesting off
2018-10-23 20:36:47 1 [Warning] WSREP: no nodes coming from prim view, prim not possible
2018-10-23 20:36:47 1 [Note] WSREP: view(view_id(NON_PRIM,4be59ce1,5) memb {
4be59ce1,0
} joined {
} left {
} partitioned {
47f2860c,0
49c4d2cf,0
})
2018-10-23 20:36:50 1 [Note] WSREP: view((empty))
2018-10-23 20:36:50 1 [ERROR] WSREP: failed to open gcomm backend connection: 110: failed to reach primary view: 110 (Connection timed out)
at gcomm/src/pc.cpp:connect():162
2018-10-23 20:36:50 1 [ERROR] WSREP: gcs/src/gcs_core.cpp:long int gcs_core_open(gcs_core_t*, const char*, const char*, bool)():206: Failed to open backend connection: -110 (Connection timed out)
2018-10-23 20:36:50 1 [ERROR] WSREP: gcs/src/gcs.cpp:long int gcs_open(gcs_conn_t*, const char*, const char*, bool)():1379: Failed to open channel 'galera_kubernetes' at 'gcomm://pxc-node2,pxc-node3': -110 (Connection timed out)
2018-10-23 20:36:50 1 [ERROR] WSREP: gcs connect failed: Connection timed out
2018-10-23 20:36:50 1 [ERROR] WSREP: wsrep::connect(gcomm://pxc-node2,pxc-node3) failed: 7
2018-10-23 20:36:50 1 [ERROR] Aborting
2018-10-23 20:36:50 1 [Note] WSREP: Service disconnected.
2018-10-23 20:36:51 1 [Note] WSREP: Some threads may fail to exit.
2018-10-23 20:36:51 1 [Note] Binlog end
2018-10-23 20:36:51 1 [Note] mysqld: Shutdown complete
какие-либо предложения?прошло уже несколько часов и просто не могу заставить его работать