sábado, 13 de julio de 2019

MySQL ¿Cómo restaurar tablespace?

MySQL ¿Cómo restaurar tablespace?

Esta no es información nueva, pero no la he cubierto mucho, así que la dirijo ahora para aquellos que la necesitan.

Si pierdes tus archivos ibd ... pierdes tus datos. Entonces, si tiene una copia de una disponible ... o incluso si está sincronizando desde otra base de datos, aún puede importarla. ¿Qué / cómo pierdes tablespace?

Aquí hay un ejemplo simple para recuperar tablespace.



mysql> Create database demo;

mysql> use demo;

mysql> CREATE TABLE `demotable` (
-> `id` int(11) NOT NULL AUTO_INCREMENT,
-> `dts` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
-> PRIMARY KEY (`id`)
-> ) ENGINE=InnoDB;


Ahora almacenamos algunos datos ...


mysql> INSERT INTO demotable (id) VALUES (NULL);
Query OK, 1 row affected (0.10 sec)

mysql> INSERT INTO demotable (id) VALUES (NULL);
Query OK, 1 row affected (0.08 sec)

mysql> SELECT * FROM demotable;
+----+---------------------+
| id | dts |
+----+---------------------+
| 1 | 2019-07-12 23:31:34 |
| 2 | 2019-07-12 23:31:35 |
+----+---------------------+
2 rows in set (0.00 sec)


OK ahora vamos a romperlo ...


# systemctl stop mysqld
# cd /var/lib/mysql/demo/
# ls -ltr
total 80
-rw-r-----. 1 mysql mysql 114688 Jul 12 23:31 demotable.ibd
# mv demotable.ibd /tmp/

# systemctl start mysqld
# mysql demo

mysql> show tables;
+----------------+
| Tables_in_demo |
+----------------+
| demotable |
+----------------+
1 row in set (0.00 sec)

mysql> desc demotable;
+-------+-----------+------+-----+-------------------+-----------------------------------------------+
| Field | Type | Null | Key | Default | Extra |
+-------+-----------+------+-----+-------------------+-----------------------------------------------+
| id | int(11) | NO | PRI | NULL | auto_increment |
| dts | timestamp | NO | | CURRENT_TIMESTAMP | DEFAULT_GENERATED on update CURRENT_TIMESTAMP |
+-------+-----------+------+-----+-------------------+-----------------------------------------------+
2 rows in set (0.01 sec)

mysql> INSERT INTO demotable (id) VALUES (NULL);
ERROR 1812 (HY000): Tablespace is missing for table `demo`.`demotable`.


Espacio de tabla roto y perdido ... Ahora podemos recuperarlo ..


demo]# cp /tmp/demotable.ibd .

mysql> ALTER TABLE demotable DISCARD TABLESPACE;

demo]# cp /tmp/demotable.ibd .
demo]# ls -ltr
total 112
-rw-r-----. 1 root root 114688 Jul 12 23:50 demotable.ibd
demo]# chown mysql:mysql demotable.ibd
demo]# mysql demo
mysql> ALTER TABLE demotable IMPORT TABLESPACE;
ERROR 1034 (HY000): Incorrect key file for table 'demotable'; try to repair it

mysql> REPAIR TABLE demotable;
+----------------+--------+----------+---------------------------------------------------------+
| Table | Op | Msg_type | Msg_text |
+----------------+--------+----------+---------------------------------------------------------+
| demo.demotable | repair | note | The storage engine for the table doesn't support repair |
+----------------+--------+----------+---------------------------------------------------------+


Note que ahora también tenemos otro error. Esto generalmente está vinculado al espacio disponible para tmpdir, y la reparación no funciona para .ibd de todos modos.


mysql> select @@tmpdir;
+----------+
| @@tmpdir |
+----------+
| /tmp |
+----------+

# vi /etc/my.cnf
tmpdir=/var/lib/mysql-files/

# systemctl restart mysqld
# mysql demo


OK usé el directorio mysql-files solo por ejemplo.
Ahora podemos intentarlo de nuevo.


mysql> ALTER TABLE demotable IMPORT TABLESPACE;
Query OK, 0 rows affected, 1 warning (0.61 sec)

mysql> INSERT INTO demotable (id) VALUES (NULL);
Query OK, 1 row affected (0.11 sec)

mysql> SELECT * FROM demotable;
+----+---------------------+
| id | dts |
+----+---------------------+
| 1 | 2019-07-12 23:31:34 |
| 2 | 2019-07-12 23:31:35 |
| 3 | 2019-07-12 23:56:08 |
+----+---------------------+


Ok funcionó
Ahora, todo esto es agradable y simple si solo tienes una mesa. Pero ¿qué hay de los 100?

Automatícelo, por supuesto, y use su esquema de información para ayudar.

Haga algunas copias más para la prueba.

mysql> create table demotable1 like demotable;
Query OK, 0 rows affected (0.51 sec)

mysql> create table demotable2 like demotable;
Query OK, 0 rows affected (1.04 sec)

mysql> create table demotable3 like demotable;
Query OK, 0 rows affected (0.74 sec)

mysql> create table demotable4 like demotable;
Query OK, 0 rows affected (2.21 sec)


Romperlos a todos ..

demo]# mv *.ibd /tmp/


Ahora, utilizando su tabla information_schema.tables, puede construir todos los comandos que necesitará.

# vi build_discard.sql
# cat build_discard.sql
SELECT CONCAT(" ALTER TABLE ",TABLE_SCHEMA,".",TABLE_NAME," DISCARD TABLESPACE; ") as CMD FROM information_schema.TABLES WHERE TABLE_SCHEMA='demo';

# vi build_import.sql
# cat build_import.sql
SELECT CONCAT(" ALTER TABLE ",TABLE_SCHEMA,".",TABLE_NAME," IMPORT TABLESPACE; ") as CMD FROM information_schema.TABLES WHERE TABLE_SCHEMA='demo';



# mysql -N < build_import.sql > import_tablespace.sql
# mysql -N < build_discard.sql | mysql demo

demo]# cp /tmp/*.ibd .
demo]# chown mysql:mysql *.ibd
# systemctl restart mysqld
# mysql demo < import_tablespace.sql
# mysql demo

mysql> INSERT INTO demotable (id) VALUES (NULL);
Query OK, 1 row affected (0.08 sec)

mysql> INSERT INTO demotable1 (id) VALUES (NULL);
Query OK, 1 row affected (0.05 sec)

mysql> INSERT INTO demotable2 (id) VALUES (NULL);
Query OK, 1 row affected (0.09 sec)

mysql> INSERT INTO demotable3 (id) VALUES (NULL);
^[[AQuery OK, 1 row affected (0.37 sec)

mysql> INSERT INTO demotable4 (id) VALUES (NULL);
Query OK, 1 row affected (0.12 sec)



Y funcionó.

MySQL Binlogs :: Cómo recuperar

Entonces me di cuenta de que no había hecho una publicación sobre esto después de esta situación que surgió recientemente.

Aquí está el escenario: una copia de seguridad se realizó a medianoche, utilizaron volcados de MySQL por base de datos. Luego, a las diez de la mañana del día siguiente, la base de datos se estrelló. Una serie de eventos sucedieron antes de que me llamaran, pero lo llevaron a una versión de la base de datos con tablas MyISAM y los archivos IBD que faltan en el espacio de tablas.

Así que la opción 1, la restauración de la copia de seguridad nos llevaría a la medianoche y perderíamos horas de datos. Opción 2, reimportamos los miles de archivos ibd y guardamos todo. Luego tuvimos la opción 3, restaurar desde la copia de seguridad, luego aplicar los registros bin para los cambios recientes.

Para hacerlo más interesante, no tenían todos los archivos ibd que me dijeron, y vi algunos faltantes. Así que no estoy seguro de cómo fue posible, pero la opción 2 se convirtió en una opción no válida. Ellos, por supuesto, querían la menor pérdida de datos posible, así que optamos por la opción 3.

Para hacerlo de forma segura, inicié otra instancia de MySQL en el puerto 3307. Esto me permitió trabajar en un lugar seguro mientras el tráfico tenía acceso de lectura a los datos de MyISAM en la instancia del puerto 3306.

Una vez que todos los archivos de copia de seguridad se descomprimieron e importaron en la instancia 3307, pude concentrarme en los archivos binlog.

Al principio, este concepto suena mucho más riesgoso de lo que realmente es. En realidad es bastante sencillo y sencillo.

Así que primero tienes que encontrar los datos que buscas. Una revisión de los archivos binlog le da una ventaja en cuanto a qué archivos son relevantes. En mi caso, de alguna manera lograron restablecer el binlog para que el archivo 117 tuviera 2 rangos de fecha dentro.

Primero para la revisión de binlog, el siguiente comando genera los datos en un formato legible.
mysqlbinlog --defaults-file=/root/.my.cnf --base64-output=DECODE-ROWS --verbose mysql-bin.000117 > review_mysql-bin.000117.sql

* Nota ... Tenga cuidado al ejecutar el comando anterior. Tenga en cuenta que lo tengo descargando el archivo directamente en la misma ubicación que binlog. Entonces valida que tu nombre de archivo sea válido. Este mysql-bin.000117.sql es diferente a este mysql-bin.000117 .sql. Perderá su binlog con la segunda opción y un espacio antes de .sql.

Ahora para guardar los datos para que puedan ser aplicados. Como tenía varios binlogs, creé un archivo y, de todos modos, quería volver a verificar los rangos de tiempo.


mysqlbinlog --defaults-file=/root/.my.cnf --start-datetime="2019-07-09 00:00:00" --stop-datetime="2019-07-10 00:00:00" mysql-bin.000117 > binlog_restore.sql
mysqlbinlog --defaults-file=/root/.my.cnf mysql-bin.000118 >> binlog_restore.sql
mysqlbinlog --defaults-file=/root/.my.cnf mysql-bin.000119 >> binlog_restore.sql
mysqlbinlog --defaults-file=/root/.my.cnf --start-datetime="2019-07-10 00:00:00" --stop-datetime="2019-07-10 10:00:00" mysql-bin.000117 >> binlog_restore.sql
mysqlbinlog --defaults-file=/root/.my.cnf --stop-datetime="2019-07-10 10:00:00" mysql-bin.000120 >> binlog_restore.sql
mysqlbinlog --defaults-file=/root/.my.cnf --stop-datetime="2019-07-10 10:00:00" mysql-bin.000121 >> binlog_restore.sql

mysql --socket=/var/lib/mysql_restore/mysql.sock -e "source /var/lib/mysql/binlog_restore.sql"

Ahora apliqué todos los datos de esos binlogs para los rangos de tiempo dados. El cliente volvió a verificar todos los datos y estaba muy contento de tenerlos todos de vuelta.

Existían varias opciones diferentes para esta situación, esto sucedió para entrenar mejor con el cliente.

Una vez que todo lo validado estaba correcto en la versión restaurada, era simplemente detener ambas bases de datos, mover los directorios de datos (quería mantener los valores predeterminados de datadir intactos), revisar los directorios solo para estar seguro e iniciar MySQL. Ahora la instancia restaurada estaba en el puerto 3306. 

lunes, 17 de junio de 2019

Replicación de Grupos MySQL

Así que la replicación grupal de MySQL salió con MySQL 5.7. Ahora que ha pasado un poco de tiempo, la gente está empezando a preguntar más al respecto.
A continuación se muestra un ejemplo de cómo configurar esto y algunos ejemplos de puntos débiles a medida que lo hurgaba.
Estoy usando tres servidores diferentes,

Servidor CENTOSA

mysql> INSTALL PLUGIN group_replication SONAME 'group_replication.so';
Query OK, 0 rows affected (0.02 sec)

vi my.cnf
disabled_storage_engines="MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY"
server_id=1
gtid_mode=ON
enforce_gtid_consistency=ON
binlog_checksum=NONE

log_bin=binlog
log_slave_updates=ON
binlog_format=ROW
master_info_repository=TABLE
relay_log_info_repository=TABLE

transaction_write_set_extraction=XXHASH64
group_replication_group_name="90d8b7c8-5ce1-490e-a448-9c8d176b54a8"
group_replication_start_on_boot=off
group_replication_local_address= "192.168.111.17:33061"
group_replication_group_seeds= "192.168.111.17:33061,192.168.111.89:33061,192.168.111.124:33061"
group_replication_bootstrap_group=off

mysql> SET SQL_LOG_BIN=0;
mysql> CREATE USER repl@'%' IDENTIFIED BY 'replpassword';
mysql> GRANT REPLICATION SLAVE ON *.* TO repl@'%';
mysql> FLUSH PRIVILEGES;
mysql> SET SQL_LOG_BIN=1;


CHANGE MASTER TO
MASTER_USER='repl',
MASTER_PASSWORD='replpassword'
FOR CHANNEL 'group_replication_recovery';


mysql> SET GLOBAL group_replication_bootstrap_group=ON;
Query OK, 0 rows affected (0.00 sec)


mysql> START GROUP_REPLICATION;
Query OK, 0 rows affected (3.11 sec)


mysql> SET GLOBAL group_replication_bootstrap_group=OFF;
Query OK, 0 rows affected (0.00 sec)


mysql> SELECT * FROM performance_schema.replication_group_members \G

*************************** 1. row ***************************
CHANNEL_NAME: group_replication_applier
MEMBER_ID: 1ab30239-5ef6-11e9-9b4a-08002712f4b1
MEMBER_HOST: centosa
MEMBER_PORT: 3306
MEMBER_STATE: ONLINE
MEMBER_ROLE: PRIMARY
MEMBER_VERSION: 8.0.15
Así que ahora podemos agregar más servidores.
Servidor CENTOSB

vi my.cnf
disabled_storage_engines="MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY"
server_id=2
gtid_mode=ON
enforce_gtid_consistency=ON
binlog_checksum=NONE

log_bin=binlog
log_slave_updates=ON
binlog_format=ROW
master_info_repository=TABLE
relay_log_info_repository=TABLE


transaction_write_set_extraction=XXHASH64
group_replication_group_name="90d8b7c8-5ce1-490e-a448-9c8d176b54a8"
group_replication_start_on_boot=off
group_replication_local_address= "192.168.111.89:33061"
group_replication_group_seeds= "192.168.111.17:33061,192.168.111.89:33061,192.168.111.124:33061"
group_replication_bootstrap_group=off

mysql> CHANGE MASTER TO
MASTER_USER='repl',
MASTER_PASSWORD='replpassword'
FOR CHANNEL 'group_replication_recovery';
Query OK, 0 rows affected, 2 warnings (0.02 sec)

mysql> CHANGE MASTER TO GET_MASTER_PUBLIC_KEY=1;
Query OK, 0 rows affected (0.02 sec)

mysql> START GROUP_REPLICATION;
Query OK, 0 rows affected (4.03 sec)

mysql> SELECT * FROM performance_schema.replication_group_members;
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| group_replication_applier | 1ab30239-5ef6-11e9-9b4a-08002712f4b1 | centosa | 3306 | ONLINE | PRIMARY | 8.0.15 |
| group_replication_applier | 572ca2fa-5eff-11e9-8df9-08002712f4b1 | centosb | 3306 | RECOVERING | SECONDARY | 8.0.15 |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
2 rows in set (0.00 sec)


Servidor CENTOSC

vi my.cnf
disabled_storage_engines="MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY"
server_id=3
gtid_mode=ON
enforce_gtid_consistency=ON
binlog_checksum=NONE
log_bin=binlog
log_slave_updates=ON
binlog_format=ROW
master_info_repository=TABLE
relay_log_info_repository=TABLE

transaction_write_set_extraction=XXHASH64
group_replication_group_name="90d8b7c8-5ce1-490e-a448-9c8d176b54a8"
group_replication_start_on_boot=off
group_replication_local_address= "192.168.111.124:33061"
group_replication_group_seeds= "192.168.111.17:33061,192.168.111.89:33061,192.168.111.124:33061"
group_replication_bootstrap_group=off

mysql> CHANGE MASTER TO
-> MASTER_USER='repl',
-> MASTER_PASSWORD='replpassword'
-> FOR CHANNEL 'group_replication_recovery';
Query OK, 0 rows affected, 2 warnings (0.02 sec)

mysql> CHANGE MASTER TO GET_MASTER_PUBLIC_KEY=1;
Query OK, 0 rows affected (0.02 sec)

mysql> START GROUP_REPLICATION;
Query OK, 0 rows affected (3.58 sec)
mysql> SELECT * FROM performance_schema.replication_group_members \G
*************************** 1. row ***************************
CHANNEL_NAME: group_replication_applier
MEMBER_ID: 1ab30239-5ef6-11e9-9b4a-08002712f4b1
MEMBER_HOST: centosa
MEMBER_PORT: 3306
MEMBER_STATE: ONLINE
MEMBER_ROLE: PRIMARY
MEMBER_VERSION: 8.0.15

*************************** 2. row ***************************
CHANNEL_NAME: group_replication_applier
MEMBER_ID: 572ca2fa-5eff-11e9-8df9-08002712f4b1
MEMBER_HOST: centosb
MEMBER_PORT: 3306
MEMBER_STATE: ONLINE
MEMBER_ROLE: SECONDARY
MEMBER_VERSION: 8.0.15

*************************** 3. row ***************************
CHANNEL_NAME: group_replication_applier
MEMBER_ID: c5f3d1d2-8dd8-11e9-858d-08002773d1b6
MEMBER_HOST: centosc
MEMBER_PORT: 3306
MEMBER_STATE: ONLINE
MEMBER_ROLE: SECONDARY
MEMBER_VERSION: 8.0.15
3 rows in set (0.00 sec)


Así que todo esto es genial, pero no siempre significa que se conecten a Internet, a menudo pueden estar en modo de recuperación.
He visto que esto falla con MySQL hasta ahora, así que necesito asegurarte de que esté estable.
mysql> create database testcentosb;<br> ERROR 1290 (HY000): The MySQL server is running with the --super-read-only option so it cannot execute this statement<br>
Nota al margen para abordar algunos de esos factores -
mysql> START GROUP_REPLICATION;
ERROR 3094 (HY000): The START GROUP_REPLICATION command failed as the applier module failed to start.

mysql> reset slave all;
Query OK, 0 rows affected (0.03 sec)
- A continuación, vuelva a empezar desde el comando maestro de cambio
mysql> START GROUP_REPLICATION;
ERROR 3092 (HY000): The server is not configured properly to be an active member of the group. Please see more details on error log.

[ERROR] [MY-011735] [Repl] Plugin group_replication reported: '[GCS] Error on opening a connection to 192.168.111.17:33061 on local port: 33061.'
[ERROR] [MY-011526] [Repl] Plugin group_replication reported: 'This member has more executed transactions than those present in the group. Local transactions: c5f3d1d2-8dd8-11e9-858d-08002773d1b6:1-4 >
[ERROR] [MY-011522] [Repl] Plugin group_replication reported: 'The member contains transactions not present in the group. The member will now exit the group.'

https://ronniethedba.wordpress.com/2017/04/22/this-member-has-more-executed-transactions-than-those-present-in-the-group/


[ERROR] [MY-011620] [Repl] Plugin group_replication reported: 'Fatal error during the recovery process of Group Replication. The server will leave the group.'
[ERROR] [MY-013173] [Repl] Plugin group_replication reported: 'The plugin encountered a critical error and will abort: Fatal error during execution of Group Replication'

SELECT * FROM performance_schema.replication_connection_status\G


Mis pensamientos...
Tenga en cuenta que la replicación de grupo se puede configurar en modo primario único o multinodo
mysql> select @@group_replication_single_primary_mode\G
*************************** 1. row ***************************
@@group_replication_single_primary_mode: 1

mysql> create database testcentosb;
ERROR 1290 (HY000): The MySQL server is running with the --super-read-only option so it cannot execute this statement
Por supuesto, obtendrá un error si no escribe en ningún nodo primario.


group-replication-single-primary-mode = off <- agregado a los archivos cnf.
mysql> SELECT * FROM performance_schema.replication_group_members;
+ --------------------------- + --------------------- ----------------- + ------------- + ------------- + ---- ---------- + ------------- + ---------------- +
| NOMBRE DEL CANAL               | IDENTIFICACIÓN DE MIEMBRO                             | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION |
+ --------------------------- + --------------------- ----------------- + ------------- + ------------- + ---- ---------- + ------------- + ---------------- +
| replicación_grupo_grupo | 1ab30239-5ef6-11e9-9b4a-08002712f4b1 | centosa     |         3306 | RECUPERANTE   | PRIMARIO     | 8.0.15         |
| replicación_grupo_grupo | 572ca2fa-5eff-11e9-8df9-08002712f4b1 | centosb     |         3306 | EN LÍNEA       | PRIMARIO     | 8.0.15         |
| replicación_grupo_grupo | c5f3d1d2-8dd8-11e9-858d-08002773d1b6 | centosc     |         3306 | RECUPERANTE   | PRIMARIO     | 8.0.15         |
+ --------------------------- + --------------------- ----------------- + ------------- + ------------- + ---- ---------- + ------------- + ---------------- +

3 filas en conjunto (0,00 seg)


Sin embargo, ahora es si utiliza Keepalived, MySQL router, ProxySQL, etc., para manejar su tráfico y reinvertirlo automáticamente en caso de una falla. Podemos ver desde abajo que fracasó de inmediato cuando detuve la primaria.

mysql> SELECT * FROM performance_schema.replication_group_members ;
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| group_replication_applier | 1ab30239-5ef6-11e9-9b4a-08002712f4b1 | centosa | 3306 | ONLINE | PRIMARY | 8.0.15 |
| group_replication_applier | 572ca2fa-5eff-11e9-8df9-08002712f4b1 | centosb | 3306 | ONLINE | SECONDARY | 8.0.15 |
| group_replication_applier | c5f3d1d2-8dd8-11e9-858d-08002773d1b6 | centosc | 3306 | ONLINE | SECONDARY | 8.0.15 |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
3 rows in set (0.00 sec)

[root@centosa]# systemctl stop mysqld

mysql> SELECT * FROM performance_schema.replication_group_members ;
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| group_replication_applier | 572ca2fa-5eff-11e9-8df9-08002712f4b1 | centosb | 3306 | ONLINE | PRIMARY | 8.0.15 |
| group_replication_applier | c5f3d1d2-8dd8-11e9-858d-08002773d1b6 | centosc | 3306 | ONLINE | SECONDARY | 8.0.15 |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
2 rows in set (0.00 sec)

[root@centosa]# systemctl start mysqld
[root@centosa]# mysql
mysql> START GROUP_REPLICATION;
Query OK, 0 rows affected (3.34 sec)

mysql> SELECT * FROM performance_schema.replication_group_members ;
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| group_replication_applier | 1ab30239-5ef6-11e9-9b4a-08002712f4b1 | centosa | 3306 | RECOVERING | SECONDARY | 8.0.15 |
| group_replication_applier | 572ca2fa-5eff-11e9-8df9-08002712f4b1 | centosb | 3306 | ONLINE | PRIMARY | 8.0.15 |
| group_replication_applier | c5f3d1d2-8dd8-11e9-858d-08002773d1b6 | centosc | 3306 | ONLINE | SECONDARY | 8.0.15 |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
3 rows in set (0.00 sec)


Ahora la recuperación seguía siendo un problema, ya que no se uniría de nuevo. Tuve que revisar todas las cuentas y los pasos nuevamente, pero finalmente lo recuperé.

mysql> SELECT * FROM performance_schema.replication_group_members;
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| group_replication_applier | 1ab30239-5ef6-11e9-9b4a-08002712f4b1 | centosa | 3306 | ONLINE | SECONDARY | 8.0.15 |
| group_replication_applier | 572ca2fa-5eff-11e9-8df9-08002712f4b1 | centosb | 3306 | ONLINE | PRIMARY | 8.0.15 |
| group_replication_applier | c5f3d1d2-8dd8-11e9-858d-08002773d1b6 | centosc | 3306 | ONLINE | SECONDARY | 8.0.15 |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
3 rows in set (0.00 sec)


Necesito probar más con esto, ya que todavía no estoy 100% vendido, y necesito esto ya que me inclino hacia la replicación de Galera.

URLs de interés


  • https://dev.mysql.com/doc/refman/8.0/en/group-replication.html
  • https://dev.mysql.com/doc/refman/8.0/en/group-replication-deploying-in-single-primary-mode.html
  • http://datacharmer.blogspot.com/2017/01/mysql-group-replication-vs-multi-source.html
  • https://dev.mysql.com/doc/refman/8.0/en/group-replication-launching.html
  • https://dev.mysql.com/doc/refman/8.0/en/group-replication-configuring-instances.html
  • https://dev.mysql.com/doc/refman/8.0/en/group-replication-adding-instances.html
  • https://ronniethedba.wordpress.com/2017/04/22/how-to-setup-mysql-group-replication/
  • https://www.digitalocean.com/community/tutorials/how-to-configure-mysql-group-replication-on-ubuntu-16-04
  • https://dev.mysql.com/doc/refman/8.0/en/group-replication-options.html#sysvar_group_replication_group_seeds
  • https://bugs.mysql.com/bug.php?id=90534
  • https://www.percona.com/blog/2017/02/24/battle-for-synchronous-replication-in-mysql-galera-vs-group-replication/
  • https://lefred.be/content/mysql-group-replication-is-sweet-but-can-be-sour-if-you-misunderstand-it/
  • https://www.youtube.com/watch?v=IfZK-Up03Mw
  • https://mysqlhighavailability.com/mysql-group-replication-a-quick-start-guide/
  • lunes, 3 de junio de 2019

    Max_connections 214 4.15.0-46-generic # 49-Ubuntu



    Por lo tanto, el problema de que max_connections se reduzca del valor establecido en su archivo my.cnf a 214 ha existido por un tiempo en Ubuntu.

    Como ejemplo, se señaló aquí en 2015.



    Me encontré con esto nuevamente recientemente y se resolvió con los siguientes pasos.


    # cp /lib/systemd/system/mysql.service /etc/systemd/system/
    # cd /etc/systemd/system/
    # vi mysql.service

    LimitNOFILE=infinity
    LimitMEMLOCK=infinity

    # systemctl daemon-reload
    # systemctl restart mysql


    Una vez que se completaron esos pasos, las conexiones de MySQL se mantuvieron estables en el parámetro dado en el archivo my.cnf.

    lunes, 15 de abril de 2019

    Configuración sencilla de KeepaliveD

    Así que keepalived ha existido por bastante tiempo ahora ... sin embargo, todavía es un misterio para muchos.
    Este es un ejemplo muy simple de cómo keepalived puede trabajar con MySQL. Con suerte, esto puede ayudar a aquellos con preguntas.

    Tendremos un maestro simple para configurar esclavos. Es decir, escribimos en uno a menos que tengamos conmutación por error al segundo para algún evento.

    1º - instalar keepalived


    # yum search keepalived
    keepalived .x86_64: equilibrador de carga y servicio de alta disponibilidad

      Solo coincidencias de nombre y resumen, use "buscar todo" para todo.
    # yum -y install keepalived

    Ahora debería tener un archivo de configuración

    # ls -ltr /etc/keepalived/keepalived.conf  

    Guarde el original como siempre hace una copia de seguridad ... correcto ....
    # cp /etc/keepalived/keepalived.conf /etc/keepalived/keepalived.conf.orig

    Por lo tanto, debe averiguar una dirección IP que pueda usar para su IP virtual. Escogí 192.168.0.123 para este ejemplo.

    A continuación, configuraremos un script para usarlo en nuestro nuevo archivo de configuración.

    Algunas cosas que hice aqui ..
    Dejé un archivo .cnf para keepalived y un registro en el / etc / keepalived.
    Esto facilita el ejemplo para que pueda hacer esto o usar sus propios archivos cnf.

    Un guión:

    cat /etc/keepalived/keepalived_check.sh  
    #! / bin / bash

    # monitorear el estado de mysql

    # si este nodo mysql está muerto

    # y su esclavo está vivo, entonces deja de mantenerlo vivo. El otro nodo enlazará la IP.



    exportar MYSQL_HOME = / etc / keepalived /

    export PATH = $ MYSQL_HOME / bin: $ PATH



    mysql = "/ usr / bin / mysql"

    mysqladmin = "/ usr / bin / mysqladmin"

    delay_file = "$ MYSQL_HOME / slave_delay_second.log"

    slave_host = $ 1





    ALIVE = $ ($ mysqladmin --defaults-file = $ MYSQL_HOME / .my.localhost.cnf   ping grep vivo | wc -l);

    REMOTEALIVE = $ ($ mysqladmin --defaults-file = $ MYSQL_HOME / .my.remotehost.cnf   ping grep vivo | wc -l);



    si [[$ ALIVE -ne 1]]

    entonces

    #echo "MySQL está caído"

            si [[$ REMOTEALIVE -eq 1]]

            entonces

    #         echo "Shutdown mantener vivo"

                systemctl dejar de mantener vivo  

    #       echo "keepalived stop"

            fi

    #más

    #echo "MySQL está arriba"

    #fecha

    fi



    salida 0 # todo hecho

    Nuevo archivo de configuración

    cat /etc/keepalived/keepalived.conf
    global_defs {



          notification_email {

            anothermysqldba@gmail.com  

          }



          notification_email_from anothermysqldba@gmail.com  

          smtp_server localhost

          smtp_connect_timeout 30



          }







    vrrp_script check_mysql {

       script "/etc/keepalived/keepalived_check.sh"

       intervalo 2

       peso 2

    }







    vrrp_instance VI_1 {



          estado maestro

          interfaz enp0s8   # <--- QUE NOMBRE DE LA INTERFAZ CUMPLE TU REAL IP / sbin / ifconfig

            # encontrado con ip link show

          virtual_router_id 51

          prioridad 101

          advert_int 1

          imperdonable   # solo es necesario en el nodo de mayor prioridad

          autenticación {

            auth_type PASS

            auth_pass 1111

          }





          track_script {

            check_mysql

          }



          virtual_ipaddress {

            192.168.0.123  

          }




    }



    Todo esto es genial, pero funciona ...

    Así que tenemos 2 hosts

    [root @ centosa keepalived] # nombre de host

    centosa

    [root @ centosb keepalived] # nombre de host
    centosb

    Empezar a mantener vivo

    [root @ centosa keepalived] # systemctl status keepalived
    ● keepalived.service - LVS y VRRP High Availability Monitor
       Cargado: cargado (/usr/lib/systemd/system/keepalived.service; desactivado; valor predeterminado del proveedor: desactivado)
       Activo: inactivo (muerto)
    [root @ centosa keepalived] # systemctl restart keepalived
    [root @ centosa keepalived] # systemctl status keepalived
    keepalived.service - LVS y VRRP High Availability Monitor
       Cargado: cargado (/usr/lib/systemd/system/keepalived.service; desactivado; valor predeterminado del proveedor: desactivado)
        Activo: activo (en ejecución)

    [root @ centosa keepalived] # ssh 192.168.0.123 'nombre de host'
    Contraseña de root@192.168.0.123:  

    centosa

    Demuestra que las conexiones ya funcionan

    [root @ centosa keepalived] # mysql --defaults-file = .my.remotehost.cnf --host = 192.168.0.101   -e "seleccione @@ hostname"
    + ------------ +
    | @@ hostname |
    + ------------ +
    | centosb     |
    + ------------ +
    [root @ centosa keepalived] # mysql --defaults-file = .my.remotehost.cnf --host = 192.168.0.102   -e "seleccione @@ hostname"
    + ------------ +
    | @@ hostname |
    + ------------ +
    | centosa     |
    + ------------ +

    Compruebe que se está ejecutando ...

    [root @ centosa keepalived] # systemctl status keepalived | grep activo
        Activo: activo  

    [root @ centosb keepalived] # systemctl status keepalived | grep activo
        Activo: activo  

    Probar el VIP actual. Detener mysql y ver los mismos hosts de cambio VIP ...

    [root @ centosa keepalived] # mysql --defaults-file = .my.remotehost.cnf --host = 192.168.0.123   -e "seleccione @@ hostname"
    + ------------ +
    | @@ hostname |
    + ------------ +
    | centosa     |
    + ------------ +
    [root @ centosa keepalived] # systemctl stop mysqld  
    [root @ centosa keepalived] # mysql --defaults-file = .my.remotehost.cnf --host = 192.168.0.123   -e "seleccione @@ hostname"
    + ------------ +
    | @@ hostname |
    + ------------ +
    | centosb     |
    + ------------ +

    martes, 9 de abril de 2019

    A veces la base de datos lenta ... no es la base de datos ...

    Hace poco me pidieron que viera por qué el MySQL 5 actualizado, .6 era más lento que el 5.5 anterior.

    Así que empecé a hojear las variables y los cachés estándar, etc.

    El caso de prueba era una rutina simple que tardó aproximadamente el doble de tiempo en ejecutarse en 5.6 que en 5.5.

    Para agregar a la mezcla ... la versión 5.6 tenía el doble de Innodb_buffer_pool_size y, por supuesto, más RAM en general.

    Así que empecé algunas pruebas con MySQLslap ...

    Las pruebas Mysqlslap lo muestran más lento en 5.6

    5.6:
    mysqlslap --defaults-file =. /. my.cnf --concurrency = 150 --iterations = 130 -query = / test.sql --create-schema = applicationdata --verbose
    Punto de referencia
    Número promedio de segundos para ejecutar todas las consultas: 0.028 segundos
    Número mínimo de segundos para ejecutar todas las consultas: 0.019 segundos
    Número máximo de segundos para ejecutar todas las consultas: 0.071 segundos
    Número de clientes ejecutando consultas: 150
    Número medio de consultas por cliente: 1

    5.5:
    mysqlslap --defaults-file =. /. my.cnf --concurrency = 150 --iterations = 130 --query = / test.sql --create-schema = applicationdata --verbose
    Punto de referencia
    Número promedio de segundos para ejecutar todas las consultas: 0.015 segundos
    Número mínimo de segundos para ejecutar todas las consultas: 0.011 segundos
    Número máximo de segundos para ejecutar todas las consultas: 0.024 segundos
    Número de clientes ejecutando consultas: 150
    Número medio de consultas por cliente: 1


    Todo esto va en contra de los puntos de referencia públicos.
    http://dimitrik.free.fr/blog/archives/2013/02/mysql-performance-mysql-56-ga-vs-mysql-55-32cores.html

    Así que revisé el nivel del disco -

    5.6:
    # dd if = / dev / zero of = test bs = 1048576 count = 2048
    2048 + 0 registros en
    2048 + 0 registros
    2147483648 bytes (2.1 GB) copiados, 25.7401 s, 83.4 MB / s

    # dd if = prueba de = / dev / null bs = 1048576
    2048 + 0 registros en
    2048 + 0 registros
    2147483648 bytes (2.1 GB) copiados, 29.1527 s, 73.7 MB / s

    5.5:
    # dd if = / dev / zero of = test bs = 1048576 count = 2048
    2048 + 0 registros en
    2048 + 0 registros
    2147483648 bytes (2.1 GB) copiados, 19.9214 segundos, 108 MB / s

    # dd if = prueba de = / dev / null bs = 1048576
    2048 + 0 registros en
    2048 + 0 registros
    2147483648 bytes (2.1 GB) copiados, 20.0243 segundos, 107 MB / s



    Aquí los discos con 5.5 son más lentos, independientemente de MySQL. Entonces, en este caso ... Mire para arreglar la velocidad del disco ... MySQL estaba funcionando bien y funcionará.