27_MySQL PXC de alta disponibilidad

1. Introducción a PXC

Consulte el https://www.percona.com/software/mysql-database/percona-xtradb-cluster oficial de Percona

PXC (Percona XtraDB Cluster) es una solución de alta disponibilidad MySQL de código abierto. Integra Percona Server y XtraBackup con la biblioteca Galera para lograr una replicación multimaestro sincrónica. Las soluciones de alta disponibilidad basadas en Galera incluyen principalmente MariaDB Galera Cluster y Percona XtraDB Cluster En la actualidad, la arquitectura PXC se utiliza cada vez más madura en la línea de producción. En comparación con las arquitecturas de clúster de maestro dual y MHA tradicionales basadas en la replicación maestro-esclavo, la característica más destacada de Galera Cluster es que resuelve el problema del retardo de replicación, difamado durante mucho tiempo, y básicamente puede lograr la sincronización en tiempo real. Y entre nodos, su relación mutua es igual. Galera Cluster en sí es también una arquitectura multimaestro. PXC es una replicación sincrónica implementada por un motor de almacenamiento y una replicación no asincrónica, por lo que su consistencia de datos es bastante alta.

[Error en la transferencia de la imagen del enlace externo. El sitio de origen puede tener un mecanismo anti-hotlinking. Se recomienda guardar la imagen y subirla directamente (img-5tPDl9FV-1615780034023) (C: \ Users \ Administrator \ AppData \ Roaming \ Typora \ typora-user-images \ image-20210314150453680.png)]

Para construir una arquitectura PXC, se requieren al menos tres instancias de MySQL para formar un clúster. Las tres instancias no están en modo maestro-esclavo, pero son cada maestro. Por lo tanto, la relación entre las tres es igual, independientemente de la subordinación, que es también llamada Arquitectura multimaestro. Cuando el cliente lee y escribe, la instancia conectada a él es la misma y la lectura de datos es la misma. Después de escribir en cualquier instancia, el clúster sincronizará los datos recién escritos con otras instancias. Esta arquitectura no se comparte. una arquitectura de clúster altamente redundante.

1.1 Ventajas y desventajas de PXC

ventaja:

  • Descubra la alta disponibilidad del clúster MySQL y la sólida coherencia de los datos.
  • Completó la verdadera solución de clúster de lectura y escritura de múltiples nodos.
  • Se mejora el problema del retardo de replicación maestro-esclavo y básicamente se logra la sincronización en tiempo real.
  • Los nodos recién agregados se pueden implementar automáticamente sin una copia de seguridad manual por adelantado, lo que es conveniente para el mantenimiento.
  • Debido a que es de escritura de múltiples nodos, la conmutación por error de la base de datos es fácil.

Desventajas:

  • Es caro unirse a un nuevo nodo. Al agregar un nuevo nodo, el conjunto de datos completo debe copiarse de uno de los nodos existentes. Si los datos son 100G, copie 100G.
  • Cualquier actualización debe verificarse globalmente antes de que pueda ejecutarse en otros nodos. El rendimiento del clúster se limita al nodo de peor rendimiento, que es lo que a menudo llamamos la ley de los barriles.
  • Debido a la necesidad de garantizar la coherencia de los datos, PXC utiliza un motor de almacenamiento en tiempo real para implementar la replicación síncrona, por lo que cuando varios nodos escriben al mismo tiempo, el problema de los conflictos de bloqueo es más serio.
  • Hay un problema de expansión. Por lo tanto, las operaciones de escritura ocurrirán en los nodos. Para escenarios grandes con cargas de escritura, no se recomienda PXC.
  • Solo se admite el motor de almacenamiento innoDB.

1.2 Principio PXC

Inserte la descripción de la imagen aquí

El flujo de operación de PXC es más o menos así. Primero, antes de que el cliente envíe la transacción al punto de escritura que solicita la conexión, el nodo transmite el conjunto de escritura de autorización que debe generarse y luego obtiene la identificación de la transacción global y transmite a otros nodos. Después de que otros nodos fusionan los datos a través de la certificación, descubren que no hay datos en conflicto y luego ejecutan las operaciones apply_cb y commit_cd; de lo contrario, la transacción se descarta.

Después de que el nodo actual (el nodo de escritura solicitado por el cliente) pasa la verificación, se ejecuta la operación commit_cb y se devuelve ok al cliente. Si la verificación falla, entonces rollback_cb.

En el clúster de PXC en la línea de producción, debe haber al menos tres nodos. Si el mismo falla en la verificación y hay un conflicto de datos, entonces el método adoptado en este momento es eliminar el nodo con datos inconsistentes del clúster, y automáticamente ejecutará el comando de apagado para apagar automáticamente.

1.3 Conceptos importantes en PXC

El primer paso es escalar el número de nodos en el clúster. Todo el nodo del clúster se controla dentro de un rango de al menos tres y como máximo ocho. El mínimo de tres es para prevenir el cerebro dividido, porque el cerebro dividido ocurre solo cuando hay dos nodos. El rendimiento del cerebro dividido es ingresar cualquier comando, y el resultado es un comando desconocido.

Cuando un nuevo nodo desea unirse al clúster de PXC, se debe elegir un nodo donante (proveedor) de cada nodo del clúster como contribuyente a la cantidad total de datos. PXC tiene dos métodos de transmisión de datos para los nodos, uno se llama transmisión completa SST y el otro se llama transmisión incremental IST. La transmisión SST tiene tres métodos: XtraBackup, mysqldump y rsync, mientras que la transmisión incremental solo tiene XtraBacker. Generalmente, cuando la cantidad de datos no es grande, SST se puede usar como una pérdida total, pero solo se usa el método XtraBackup.

En un clúster de nodos, el cambio de estado se producirá debido a una falla en la unión de un nuevo nodo, falla de sincronización, etc.

  • abierto: el nodo se inició correctamente, intente conectarse al clúster.
  • primario: el nodo ya está en el clúster. Cuando un nuevo nodo se une al clúster, el estado se generará cuando se elija al donante para la sincronización de datos.
  • joiner: el nodo está en un estado de espera para recibir archivos de datos sincronizados
  • joinerd: el nodo ha completado la sincronización, tratando de mantener el progreso consistente con otros nodos en el clúster.
  • sincronizado: el estado del nodo que normalmente proporciona servicios, lo que indica que la sincronización se ha completado y el progreso del clúster es coherente.
  • doner: el nodo está en el estado en el que proporciona datos completos para el nodo recién agregado.

1.4 Parámetros de configuración importantes en PXC

En el proceso de construcción de PXC, debe establecer algunos parámetros en my.cnf

  • wsrep_cluster_name: especifique el nombre lógico del clúster. Para todos los nodos del clúster, el nombre del clúster debe ser el mismo.

  • wsrep_cluster_address: especifique la dirección IP de cada nodo en el clúster

  • wsrep_node_name: especifique el nombre lógico del nodo actual y las masas

  • wsrep_node_address: especifique la dirección IP del nodo actual

  • wwsrep_provider: especifique la ruta de la biblioteca Galera

  • wsrep_sst_method: en el modo, PXC usa XtraBackup para la transmisión SST. Se recomienda encarecidamente que este parámetro se refiera a xtrabackup-v2

  • wsrep_sst_auth: especifique la credencial de autenticación como SST como <sst_user> <sst_pwd>. Este usuario debe crearse después de iniciar el primer nodo y recibir los permisos necesarios.

  • pxc_strict_mode: modo estricto, la recomendación oficial es que el valor del parámetro sea ENFORCING.

    Otro módulo particularmente importante en PXC es Gcache. Su función principal es que cada nodo almacena en caché el último conjunto de escritura actual. Si un nuevo nodo se une al clúster, el nuevo incremento de datos en espera se puede pasar al nuevo nodo sin utilizar el método SST. Esto permite que los nodos se unan al clúster más rápido. El módulo GCache incluye los siguientes parámetros:

  • gcache.size: representa el tamaño utilizado para almacenar en caché la información incremental del conjunto de escritura. Su tamaño predeterminado es 128 MB, que se establece mediante el parámetro de variable wsrep_provider_options. Se recomienda ajustarse al rango de 2G-4G, suficiente espacio es conveniente para almacenar más información incremental.

  • gcache.page_size: Se puede entender que si la memoria no es suficiente (no hay suficiente Gcache), escriba el conjunto de escritura directamente en el archivo de disco.

  • gcache.mem_size: Representa el tamaño de la memoria caché en Gcache, un aumento moderado puede mejorar el rendimiento de todo el clúster.

1.5 Monitoreo del estado del clúster PXC

Una vez configurado el clúster, puede ver el estado de cada nodo del clúster a través de la siguiente variable de estado '% wsrep%'. A continuación, se muestran algunos parámetros importantes para facilitar el descubrimiento de problemas.

[Error en la transferencia de la imagen del enlace externo. El sitio de origen puede tener un mecanismo anti-hotlinking. Se recomienda guardar la imagen y subirla directamente (img-9D8PgsSp-1615780034030) (C: \ Users \ Administrator \ AppData \ Roaming \ Typora \ typora-user-images \ image-20210314180644599.png)]

2. Implementar PXC

2.1 Descripción ambiental

Descarga de archivo requerida: 1111

Planificación de direcciones:

Nombre de la CPU dirección IP
PxC-nodo1 192.168.1.61
PxC-node2 192.168.1.64
PxC-node3 192.168.1.65

Resolver paquetes dependientes

yum install -y libev lsof perl-Compress-Raw-Bzip2 perl-Compress-Raw-Zlib perl-DBD-MySQL perl-DBI perl-Digest perl-Digest-MD5 perl-IO-Compress perl-Net-Daemon perl-PlRPC qpress socat openssl openssl-devel

// Es posible que el paquete qpress no esté instalado, lo instalaremos manualmente y lo anterior proporcionará los paquetes necesarios

tar xf qpress-11-linux-x64.tar -C /usr/local/bin/

Instalar XtraBackup

yum -y install percona-xtrabackup-24-2.4.18-1.el7.x86_64.rpm

Desinstalar mariadb

rpm -e mariadb-libs --nodeps

Crear usuario y grupo de mysql

groupadd -r mysql && useradd -M -s /bin/false -r -g mysql mysql

Descomprima el paquete en / usr / local / mysql, cree un directorio de datos y otorgue permisos

tar zxf Percona-XtraDB-Cluster-5.7.28-rel31-31.41.1.Linux.x86_64.ssl101.tar.gz 
mv Percona-XtraDB-Cluster-5.7.28-rel31-31.41.1.Linux.x86_64.ssl101 /usr/local/mysql

mkdir /usr/local/mysql/data
chown -R mysql:mysql /usr/local/mysql/

Configurar variables de entorno

tail -1 /etc/profile
export PATH=/usr/local/mysql/bin:$PATH
. /etc/profile

Prepare el archivo de configuración, el formato binlog debe ser row, los archivos de configuración en pxc-node2 y pxc-node3 son los mismos, pero tenga en cuenta que debe cambiar server_id, wsrep_node_name, wsrep_node_address

[client]
port = 3306
socket = /tmp/mysql.sock
[mysql]
prompt="\u@\h \R:\m:\s[\d]> "
no-auto-rehash
[mysqld]
user = mysql
port = 3306
basedir = /usr/local/mysql
datadir = /usr/local/mysql/data
socket = /tmp/mysql.sock
pid-file = db.pid
character-set-server = utf8mb4
skip_name_resolve = 1
open_files_limit = 65535
back_log = 1024
max_connections = 512
max_connect_errors = 1000000
table_open_cache = 1024
table_definition_cache = 1024
table_open_cache_instances = 64
thread_stack = 512K
external-locking = FALSE
max_allowed_packet = 32M
sort_buffer_size = 4M
join_buffer_size = 4M
thread_cache_size = 768

interactive_timeout = 600
wait_timeout = 600
tmp_table_size = 32M
max_heap_table_size = 32M
slow_query_log = 1
slow_query_log_file = /usr/local/mysql/data/slow.log
log-error = /usr/local/mysql/data/error.log
long_query_time = 0.1
server-id = 1813306
log-bin = /usr/local/mysql/data/mysql-bin
sync_binlog = 1
binlog_cache_size = 4M
max_binlog_cache_size = 1G
max_binlog_size = 1G
expire_logs_days = 7
master_info_repository = TABLE
relay_log_info_repository = TABLE
gtid_mode = on
enforce_gtid_consistency = 1
log_slave_updates
binlog_format = row
relay_log_recovery = 1
relay-log-purge = 1
key_buffer_size = 32M
read_buffer_size = 8M
read_rnd_buffer_size = 4M
bulk_insert_buffer_size = 64M
lock_wait_timeout = 3600
explicit_defaults_for_timestamp = 1
innodb_thread_concurrency = 0
innodb_sync_spin_loops = 100
innodb_spin_wait_delay = 30
transaction_isolation = REPEATABLE-READ
innodb_buffer_pool_size = 1024M
innodb_buffer_pool_instances = 8
innodb_buffer_pool_load_at_startup = 1
innodb_buffer_pool_dump_at_shutdown = 1
innodb_data_file_path = ibdata1:1G:autoextend
innodb_flush_log_at_trx_commit = 1
innodb_log_buffer_size = 32M
innodb_log_file_size = 2G
innodb_log_files_in_group = 2

innodb_io_capacity = 2000
innodb_io_capacity_max = 4000
innodb_flush_neighbors = 0
innodb_write_io_threads = 4
innodb_read_io_threads = 4
innodb_purge_threads = 4
innodb_page_cleaners = 4
innodb_open_files = 65535
innodb_max_dirty_pages_pct = 50
innodb_flush_method = O_DIRECT
innodb_lru_scan_depth = 4000
innodb_checksum_algorithm = crc32

innodb_lock_wait_timeout = 10
innodb_rollback_on_timeout = 1
innodb_print_all_deadlocks = 1
innodb_file_per_table = 1
innodb_online_alter_log_max_size = 4G
internal_tmp_disk_storage_engine = InnoDB
innodb_stats_on_metadata = 0

wsrep_provider=/usr/local/mysql/lib/libgalera_smm.so
wsrep_provider_options="gcache.size=1G"
wsrep_cluster_name=pxc-test
wsrep_cluster_address=gcomm://192.168.1.61,192.168.1.64,192.168.1.65
wsrep_node_name=pxc-node1
wsrep_node_address=192.168.1.61
wsrep_sst_method=xtrabackup-v2
wsrep_sst_auth=sst:pwd@123
pxc_strict_mode=ENFORCING
default_storage_engine=InnoDB
innodb_autoinc_lock_mode=2
[mysqldump]
quick
max_allowed_packet = 32M

Cada nodo completa la inicialización de MySQL

mysqld --defaults-file=/etc/my.cnf --user=mysql --basedir=/usr/local/mysql/ --datadir=/usr/local/mysql/data/  --initialize

2.3 Arrancar el primer nodo para inicializar el clúster

Inicie MySQL en pxc-node1

mysqld --defaults-file=/etc/my.cnf --wsrep_new_cluster &
netstat -anput | grep mysql
tcp        0      0 0.0.0.0:4567            0.0.0.0:*               LISTEN      1691/mysqld         
tcp6       0      0 :::3306                 :::*                    LISTEN      1691/mysqld      

Obtenga la contraseña temporal del registro de errores, inicie sesión en MySQL para cambiar la contraseña de root

[root@pxc-node1 ~]# grep 'password' /usr/local/mysql/data/error.log 
2021-03-14T11:05:42.083115Z 1 [Note] A temporary password is generated for root@localhost: k-506%(lZJlu

root@localhost 19:09: [(none)]> alter user root@'localhost' identified by '123.com';

Crear cuenta de transferencia SST en PXC

root@localhost 19:09: [(none)]> grant all privileges on *.* to 'sst'@'localhost' identified by 'pwd@123';
root@localhost 19:13: [(none)]> flush privileges;

2.4 Agregar otros nodos al clúster

Inicie MySQL en pxc-node2 y pxc-node3, y agregue pxc-node2 y pxc-node3 al clúster. El proceso toma unos minutos, espere pacientemente

mysqld --defaults-file=/etc/my.cnf &
netstat -anput | grep mysql
tcp        0      0 0.0.0.0:4567            0.0.0.0:*               LISTEN      2653/mysqld     

En este momento, pxc-node2 y pxc-node3 están sincronizando datos de pxc-node1 al local

netstat -anput | grep mysql
tcp        0      0 0.0.0.0:4567            0.0.0.0:*               LISTEN      2653/mysqld         
tcp        0      0 192.168.1.64:4567       192.168.1.65:48590      ESTABLISHED 2653/mysqld         
tcp        0      0 192.168.1.64:41942      192.168.1.61:4567       ESTABLISHED 2653/mysqld         
tcp6       0      0 :::3306                 :::*                    LISTEN      2653/mysqld                

Los datos se han sincronizado con el local, por lo que puede iniciar sesión directamente en el terminal MySQL utilizando directamente la contraseña de usuario raíz establecida en pxc-node1

mysql -uroot -p123.com

Verifique el estado del clúster, puede ver que hay tres nodos en el clúster actual

root@localhost 11:30: [(none)]> show global status like '%wsrep_cluster_s%';
+--------------------------+--------------------------------------+
| Variable_name            | Value                                |
+--------------------------+--------------------------------------+
| wsrep_cluster_size       | 3                                    |
| wsrep_cluster_state_uuid | abd434e7-853e-11eb-b686-920f5f5a4d49 |
| wsrep_cluster_status     | Primary                              |
+--------------------------+--------------------------------------+
3 rows in set (0.00 sec)

root@localhost 11:33: [(none)]> show global status like '%wsrep_ready%';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| wsrep_ready   | ON    |
+---------------+-------+
1 row in set (0.00 sec)

2.5 Verificar copia

Cree una biblioteca en uno de ellos para ver si los otros dos están sincronizados.

root@localhost 11:35: [(none)]> create database pxc
root@localhost 11:41: [(none)]> use pxc
root@localhost 11:41: [pxc]> create table test_t1 (
    -> id int primary key auto_increment,
    -> name varchar(22)
    -> );

root@localhost 11:43: [pxc]> insert into test_t1(name) values('zhangsan'),('lisi');

// Comprueba si está sincronizado en otros nodos

root@localhost 11:45: [qin]> select * from pxc.test_t1;
+----+----------+
| id | name     |
+----+----------+
|  1 | zhangsan |
|  4 | lisi     |
+----+----------+
-> id int primary key auto_increment,
-> name varchar(22)
-> );

root @ localhost 11:43: [pxc]> insertar en test_t1 (nombre) valores ('zhangsan'), ('lisi');


//在其他节点查看是否同步

```bash
root@localhost 11:45: [qin]> select * from pxc.test_t1;
+----+----------+
| id | name     |
+----+----------+
|  1 | zhangsan |
|  4 | lisi     |
+----+----------+

Supongo que te gusta

Origin blog.csdn.net/weixin_45310323/article/details/114825269
Recomendado
Clasificación