Hola a todos!
Una vez que apareció una tarea en el trabajo, parece que hay un clúster de innoDB de prueba configurado en varias máquinas virtuales con centos 7.5, debe estudiarlo y agregar un par de nodos más. Puedes romper y burlarte como quieras. Suena tentador
Antes de eso, no tenía experiencia con ese grupo, pero Google me ayudó.
Con algunas excepciones, todos los enlaces en él y en Yandex estaban en dev.mysql.com o en este
artículo sobre Habr . Parece que se configuró un clúster de dos nodos.
Bueno, leí el artículo, me sorprendió un poco la complejidad de agregar nodos y la falta de muchos detalles, pero bueno. Con un pecado, agregué la mitad de un nuevo nodo (algunos de los comandos no fueron útiles, algunos generalmente rompieron todo), después de lo cual comencé a experimentar reiniciando los nodos, etc.
Después de varios enfoques e innumerables muertes de células nerviosas, el grupo no pudo soportarlo. Un nodo no quería agregarse bajo ninguna circunstancia, el otro colgaba al intentar acceder a la base de datos, el tercero pretendía que todo estaba en orden. Tuve que disparar y comenzar desde cero.
Al crear un nuevo clúster, desafortunadamente, surgieron muchos problemas e inconsistencias. Quizás el punto esté en las versiones de software, probé mysql 5.7. Quizás en la distribución. Como resultado, detuve los intentos irreflexivos de hacer todo en una hoja de papel y comencé a configurarlo escribiendo. Y google.
Un par de noches y noches agradables y el grupo se reunió e incluso se negó a desmoronarse.
Al mismo tiempo, el método de su creación fue notablemente diferente de los intentos anteriores y quería compartirlo, porque En Internet, no encontré otras instrucciones comprensibles detalladas relevantes para configurar el clúster inndoDB.
Por lo tanto, tenemos tres máquinas virtuales idénticas con el Centos 7.5 minimal 1804 recién instalado y selinux y firewalld deshabilitados:
1.1.1.1
1.1.1.2
1.1.1.3
Para el trabajo, usé mysql 5.7, así que lo usamos. Comencemos con 1.1.1.1:
1. Instale el repositorio mysql-community:
rpm -i https://dev.mysql.com/get/mysql80-community-release-el7-1.noarch.rpm
Apague el repositorio para 8, enciéndalo para 5.7 y verifique: si todo está bien, instale mysql:
yum install yum-utils yum-config-manager --disable mysql80-community yum-config-manager --enable mysql57-community yum repolist yum install mysql-community-server mysql-shell
2. Traemos /etc/my.cnf a este formulario:
[mysqld] datadir=/var/lib/mysql socket=/var/lib/mysql/mysql.sock symbolic-links=0 log-error=/var/log/mysqld.log pid-file=/var/run/mysqld/mysqld.pid bind-address=0.0.0.0 port=3301 # Replication part server_id=1 gtid_mode=ON enforce_gtid_consistency=ON master_info_repository=TABLE relay_log_info_repository=TABLE binlog_checksum=NONE log_slave_updates=ON log_bin=binlog binlog_format=ROW plugin-load = group_replication.so # Group replication part transaction_write_set_extraction=XXHASH64 loose-group_replication_start_on_boot = OFF loose-group_replication_local_address = 1.1.1.1:33011 loose-group_replication_bootstrap_group = OFF report_port = 3301 report_host = 1.1.1.1
Aquí 3301 es el puerto en el que mysql escuchará, y 33011 es el puerto en el que los nodos se comunican entre sí.
3. Inicie mysql y realice la configuración preliminar:
systemctl start mysqld grep 'password' /var/log/mysqld.log mysql_secure_installation
4. Bueno, cree un clúster, así como un usuario separado para administrarlo. Si conoce de antemano las direcciones IP de los nodos, puede enumerarlas de inmediato en ipWhitelist. Fingiremos que aún no conocemos 1.1.1.2. y 1.1.1.3:
mysqlsh > \c 127.0.0.1:3301 > dba.configureLocalInstance("127.0.0.1:3301", {mycnfPath: "/etc/my.cnf", clusterAdmin: "cladmin", clusterAdminPassword: "SomePassword!123"}) > \c cladmin@1.1.1.1:3301 > dba.checkInstanceConfiguration() > cl=dba.createCluster('TestCluster', {ipWhitelist: '1.1.1.1'}) > dba.configureLocalInstance() > cl.status()
Hecho cl.status debería generar algo como esto:
{ "clusterName": "TestCluster", "defaultReplicaSet": { "name": "default", "primary": "1.1.1.1:3301", "ssl": "REQUIRED", "status": "OK_NO_TOLERANCE", "statusText": "Cluster is NOT tolerant to any failures.", "topology": { "1.1.1.1:3301": { "address": "1.1.1.1:3301", "mode": "R/W", "readReplicas": {}, "role": "HA", "status": "ONLINE" } } }, "groupInformationSourceMember": "mysql://cladmin@1.1.1.1:3301" }
Al cambiar el clúster, será necesario ejecutar el comando dba.configureLocalInstance () localmente en todos los nodos para guardar los cambios:
WARNING: On instance '1.1.1.1:3301' membership change cannot be persisted since MySQL version 5.7.23 does not support the SET PERSIST command (MySQL version >= 8.0.11 required). Please use the <Dba>.configureLocalInstance command locally to persist the changes.
Porque vamos a agregar un par de nodos más, no cerramos la conexión con el servidor 1.1.1.1, será útil para nosotros.
Ahora intentemos agregar el nodo 1.1.1.2 al clúster. Para hacer esto, ejecutamos los mismos comandos en hasta 3 pasos inclusive, sin olvidar cambiar server_id, loose-group_replication_local_address y report_host.
4. Ejecutamos en 1.1.1.2:
mysql -p > set GLOBAL group_replication_allow_local_disjoint_gtids_join=ON;
Traté de establecer esta variable a través de mysqlsh, cambiando al modo sql, pero las acciones allí no la afectaron en mysql. Siguiente:
mysqlsh > \c 127.0.0.1:3301 > dba.configureLocalInstance("127.0.0.1:3301", {mycnfPath: "/etc/my.cnf", clusterAdmin: "cladmin", clusterAdminPassword: "SomePassword!123"}) > \c cladmin@1.1.1.2:3301 > dba.checkInstanceConfiguration()
5. Regrese al primer nodo 1.1.1.1. Si cerró la conexión, puede conectarse rápidamente al clúster de esta manera:
mysqlsh --uri cladmin@1.1.1.1:3301 --cluster > \sql > STOP GROUP_REPLICATION; > SET GLOBAL group_replication_ip_whitelist="1.1.1.1,1.1.1.2"; > START GROUP_REPLICATION; > \js > cluster.addInstance('cladmin@1.1.1.2:3301', {ipWhitelist: '1.1.1.1,1.1.1.2'}) > cluster.status()
Por alguna razón, al agregar un nodo sin la opción ipWhitelist, no se transmite automáticamente, por lo que lo especificamos manualmente.
Si su lista blanca está configurada inicialmente para todos los nodos o una subred, entonces se pueden omitir los comandos en modo sql.
No olvide ejecutar dba.configureLocalInstance () en todos los nodos para guardar la configuración.
El grupo de sus dos nodos resultó:
{ "clusterName": "TestCluster", "defaultReplicaSet": { "name": "default", "primary": "1.1.1.1:3301", "ssl": "REQUIRED", "status": "OK_NO_TOLERANCE", "statusText": "Cluster is NOT tolerant to any failures.", "topology": { "1.1.1.1:3301": { "address": "1.1.1.1:3301", "mode": "R/W", "readReplicas": {}, "role": "HA", "status": "ONLINE" }, "1.1.1.2:3301": { "address": "1.1.1.2:3301", "mode": "R/O", "readReplicas": {}, "role": "HA", "status": "ONLINE" } } }, "groupInformationSourceMember": "mysql://cladmin@1.1.1.1:3301" }
Bueno, hay un clúster de dos nodos, pero en el "Clúster NO es tolerante a ninguna falla".
Agregue un tercero, el algoritmo es básicamente el mismo que agregar un segundo.
Si nuevamente necesita cambiar la lista blanca, entonces necesita ejecutar los comandos en el nodo r / w, porque en nodos r / o no parece conducir a nada. En este caso, los nodos r / o se caerán y deberán volver a conectarse, informando simultáneamente una nueva lista blanca.
En nuestro caso:
> cluster.rejoinInstance('cladmin@1.1.1.2:3301', {ipWhitelist: '1.1.1.1,1.1.1.2,1.1.1.3'})
Bueno, una vez más, no olvide ejecutar dba.configureLocalInstance () en todos los nodos para guardar la configuración.
Un grupo de tres nodos se ve así:
{ "clusterName": "TestCluster", "defaultReplicaSet": { "name": "default", "primary": "1.1.1.1:3301", "ssl": "REQUIRED", "status": "OK", "statusText": "Cluster is ONLINE and can tolerate up to ONE failure.", "topology": { "1.1.1.1:3301": { "address": "1.1.1.1:3301", "mode": "R/W", "readReplicas": {}, "role": "HA", "status": "ONLINE" }, "1.1.1.2:3301": { "address": "1.1.1.2:3301", "mode": "R/O", "readReplicas": {}, "role": "HA", "status": "ONLINE" }, "1.1.1.3:3301": { "address": "1.1.1.3:3301", "mode": "R/O", "readReplicas": {}, "role": "HA", "status": "ONLINE" } } }, "groupInformationSourceMember": "mysql://cladmin@1.1.1.1:3301" }
Si el clúster se ha colapsado al estado de un nodo, deberá iniciarse con el parámetro loose-group_replication_bootstrap_group = ON en /etc/my.cnf
Después de comenzar, el parámetro deberá desactivarse nuevamente; de lo contrario, este nodo siempre estará separado del clúster y se mantendrá.
La instalación de mysql-router está bien descrita
aquí , así que no veo ningún sentido en duplicar.
Eso es todo, eso es todo, espero que alguien encuentre útil mi experiencia.
Gracias por su atencion