Mostrando entradas con la etiqueta replication. Mostrar todas las entradas
Mostrando entradas con la etiqueta replication. Mostrar todas las entradas

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/
  • jueves, 15 de mayo de 2014

    Una mirada a MySQL 5.7 DMR

    Original post: http://anothermysqldba.blogspot.com/2014/05/a-look-at-mysql-57-dmr.html

    Así que pensé que ya era hora Miré a MySQL 5.7. Esta es una visión general de alto nivel, pero yo estaba mirando por encima de la MySQL 5.7 en un documento de síntesis: 
    Así que estoy empezando con una fresca Fedora 20 (Xfce) instalar. 
    En general, voy a revisar algunos artículos que he encontrado curioso e interesante con MySQL 5.7. El resumen tiene una gran cantidad de información tan bien merece una revisión.

    He descargado el MySQL-5.7.4-m14-1.linux_glibc2.5.x86_64.rpm-bundle.tar 

    La instalación fue planeado en hacer lo siguiente 
    # tar -vxf MySQL-5.7.4-m14-1.linux_glibc2.5.x86_64.rpm-bundle.tar 
    # rm -f mysql-community-embedded* 
    ]# ls -a MySQL-*.rpm 
    MySQL-client-5.7.4_m14-1.linux_glibc2.5.x86_64.rpm 
    MySQL-embedded-5.7.4_m14-1.linux_glibc2.5.x86_64.rpm 
    MySQL-shared-5.7.4_m14-1.linux_glibc2.5.x86_64.rpm 
    MySQL-devel-5.7.4_m14-1.linux_glibc2.5.x86_64.rpm 
    MySQL-server-5.7.4_m14-1.linux_glibc2.5.x86_64.rpm 
    MySQL-test-5.7.4_m14-1.linux_glibc2.5.x86_64.rpm 
    # yum -y install MySQL-*.rpm 
    Complete! 

    Si bien dijo que completa también noté un error. Debería haber no ha terminado la instalación si se detecta un error, pero está bien .... 
    FATAL ERROR: please install the following Perl modules before executing /usr/bin/mysql_install_db: 
    Data::Dumper 

    Se confirmó Este error .. 
    # /etc/init.d/mysql start 
    Starting MySQL............ ERROR! The server quit without updating PID file 
    # tail /var/lib/mysql/fedora20mysql57.localdomain.err 
    ERROR] Fatal error: Can't open and lock privilege tables: Table 'mysql.user' doesn't exist 
    # /usr/bin/mysql_install_db 
    FATAL ERROR: please install the following Perl modules before executing /usr/bin/mysql_install_db: 
    Data::Dumper 
    # yum -y install perl-Data-Dumper 
    # /usr/bin/mysql_install_db 
    A RANDOM PASSWORD HAS BEEN SET FOR THE MySQL root USER ! 
    You will find that password in '/root/.mysql_secret'. 

    You must change that password on your first connect, 
    no other statement but 'SET PASSWORD' will be accepted. 
    # chown -R mysql:mysql /var/lib/mysql/mysql/ 
    # cat /root/.mysql_secret 
    # mysql -u root -p 
    mysql> SET PASSWORD FOR 'root'@'localhost' = PASSWORD('somepassword'); 
    Query OK, 0 rows affected (0.01 sec) 

    mysql> select @@version; 
    +-----------+ 
    | @@version | 
    +-----------+ 
    | 5.7.4-m14 | 
    +-----------+ 

    Un proceso más sólido para las actualizaciones y etc se documenta aquí: 
    http://dev.mysql.com/doc/refman/5.7/en/upgrading-from-previous-series.html 
    Revise para asegurarse de que tiene GLIBC_2.15 si va a instalarlo en su sistema operativo. 

    Aceptar lo que ahora que ya está instalado, ¿qué es lo que tenemos. 
    mysql> select User , Host,plugin from mysql.user \G 
    *************************** 1. row *************************** 
    User: root 
    Host: localhost 
    plugin : mysql_native_password 
    mysql> show databases; 
    +--------------------+ 
    | Database | 
    +--------------------+ 
    | information_schema | 
    | mysql | 
    | performance_schema | 
    +--------------------+ 
    mysql> SELECT @@default_password_lifetime \G 
    *************************** 1. row *************************** 
    @@default_password_lifetime: 360 

    Estas son todas las mejoras largamente esperadas, y gracias a todos por las mejoras. 
    Así que ahora a mirar por encima de los demás, por lo menos queremos algún tipo de datos y el esquema. Así que voy a instalar la base de datos mundial de las pruebas. 
    # wget http://downloads.mysql.com/docs/world_innodb.sql.gz 
    # gzip -d world_innodb.sql.gz 
    # mysql -u root -p -e "create database world"; 
    # mysql -u root -p world < world_innodb.sql 
    # mysql -u root -p world 
    mysql> show create table City; 
    CREATE TABLE `City` ( 
    `ID` int(11) NOT NULL AUTO_INCREMENT, 
    `Name` char(35) NOT NULL DEFAULT '', 
    `CountryCode` char(3) NOT NULL DEFAULT '', 
    `District` char(20) NOT NULL DEFAULT '', 
    `Population` int(11) NOT NULL DEFAULT '0', 
    PRIMARY KEY (`ID`), 
    KEY ` CountryCode ` (`CountryCode`), 
    CONSTRAINT `city_ibfk_1` FOREIGN KEY (`CountryCode`) REFERENCES `Country` (`Code`) 
    ) ENGINE=InnoDB
     
    mysql> ALTER TABLE City ALGORITHM=INPLACE, RENAME KEY CountryCode TO THECountryCode; 
    Query OK
     
    mysql> show create table City; 
    CREATE TABLE `City` ( 
    `ID` int(11) NOT NULL AUTO_INCREMENT, 
    `Name` char(35) NOT NULL DEFAULT '', 
    `CountryCode` char(3) NOT NULL DEFAULT '', 
    `District` char(20) NOT NULL DEFAULT '', 
    `Population` int(11) NOT NULL DEFAULT '0', 
    PRIMARY KEY (`ID`), 
    KEY ` THECountryCode ` (`CountryCode`), 
    CONSTRAINT `city_ibfk_1` FOREIGN KEY (`CountryCode`) REFERENCES `Country` (`Code`) 
    ) ENGINE=InnoDB 

    mysql> DROP TABLE test.no_such_table; 
    ERROR 1051 (42S02): Unknown table 'test.no_such_table' 
    mysql> GET DIAGNOSTICS CONDITION 1 @p1 = RETURNED_SQLSTATE, @p2 = MESSAGE_TEXT; 
    Query OK, 0 rows affected (0.45 sec) 

    mysql> SELECT @p1, @p2 \G 
    *************************** 1. row *************************** 
    @p1: 42S02 
    @p2: Unknown table 'test.no_such_table' 
    1 row in set (0.01 sec)
    • Los disparadores 
      La limitación de disparo ha sido levantada y no se permiten múltiples factores desencadenantes. Por favor, consulte la documentación, ya que dan un buen ejemplo. Voy a una demostración de que algunos aquí sólo para mostrar que son posibles múltiples disparadores en una misma mesa.
    mysql> CREATE TABLE account (acct_num INT, amount DECIMAL(10,2)); 
    mysql> CREATE TRIGGER ins_sum BEFORE INSERT ON account FOR EACH ROW SET @sum = @sum + NEW.amount; 
    mysql> SET @sum = 0; 
    mysql> INSERT INTO account VALUES(137,14.98),(141,1937.50),(97,-100.00); 
    SELECT @sum AS 'Total amount inserted'; 
    +-----------------------+ 
    | Total amount inserted | 
    +-----------------------+ 
    | 1852.48 | 
    +-----------------------+
     
    mysql> CREATE TRIGGER ins_transaction BEFORE INSERT ON account 
    -> FOR EACH ROW PRECEDES ins_sum 
    -> SET 
    -> @deposits = @deposits + IF(NEW.amount>0,NEW.amount,0), 
    -> @withdrawals = @withdrawals + IF(NEW.amount<0,-NEW.amount,0);
     
    mysql> SHOW triggers \G 
    *************************** 1. row *************************** 
    Trigger: ins_transaction 
    Event: INSERT 
    Table: account 
    Statement: SET 
    @deposits = @deposits + IF(NEW.amount>0,NEW.amount,0), 
    @withdrawals = @withdrawals + IF(NEW.amount<0,-NEW.amount,0) 
    Timing: BEFORE 
    Created: 2014-05-14 21:23:49.66 
    sql_mode: STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION 
    Definer: root@localhost 
    character_set_client: utf8 
    collation_connection: utf8_general_ci 
    Database Collation: latin1_swedish_ci 
    *************************** 2. row *************************** 
    Trigger: ins_sum 
    Event: INSERT 
    Table: account 
    Statement: SET @sum = @sum + NEW.amount 
    Timing: BEFORE 
    Created: 2014-05-14 21:22:47.91 
    sql_mode: STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION 
    Definer: root@localhost 
    character_set_client: utf8 
    collation_connection: utf8_general_ci 
    Database Collation: latin1_swedish_ci
    mysql> CREATE TABLE t1 
    -> ( c1 CHAR(10) CHARACTER SET latin1 
    -> ) DEFAULT CHARACTER SET gb18030 COLLATE gb18030_chinese_ci ; 
    Query OK 
    mysql> HANDLER City OPEN AS city_handle; 
    mysql> HANDLER city_handle READ FIRST; 
    +----+-------+-------------+----------+------------+ 
    | ID | Name | CountryCode | District | Population | 
    +----+-------+-------------+----------+------------+ 
    | 1 | Kabul | AFG | Kabol | 1780000 | 
    +----+-------+-------------+----------+------------+
     
    mysql> HANDLER city_handle READ NEXT LIMIT 3; 
    +----+-----------+-------------+---------------+------------+ 
    | ID | Name | CountryCode | District | Population | 
    +----+-----------+-------------+---------------+------------+ 
    | 5 | Amsterdam | NLD | Noord-Holland | 731200 | 
    | 6 | Rotterdam | NLD | Zuid-Holland | 593321 | 
    | 7 | Haag | NLD | Zuid-Holland | 440900 | 
    +----+-----------+-------------+---------------+------------+
     
    mysql> CREATE TABLE `t2` ( 
    -> `t2_id` int(10) unsigned NOT NULL AUTO_INCREMENT, 
    -> `inserttimestamp` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, 
    -> `somevalue` int(10) unsigned DEFAULT NULL, 
    -> `rowLastUpdateTime` datetime DEFAULT NULL, 
    -> PRIMARY KEY (`t2_id`,`inserttimestamp`) 
    -> ) ENGINE=InnoDB;
     
    mysql> ALTER TABLE t2 
    -> PARTITION BY RANGE ( TO_DAYS(inserttimestamp) ) ( 
    -> PARTITION Jan2014 VALUES LESS THAN (TO_DAYS('2014-02-01')), 
    -> PARTITION Feb2014 VALUES LESS THAN (TO_DAYS('2014-03-01')), 
    -> PARTITION Mar2014 VALUES LESS THAN (TO_DAYS('2014-04-01')), 
    -> PARTITION Apr2014 VALUES LESS THAN (TO_DAYS('2014-05-01')), 
    -> PARTITION May2014 VALUES LESS THAN (TO_DAYS('2014-06-01')), 
    -> PARTITION Jun2014 VALUES LESS THAN (TO_DAYS('2014-07-01')), 
    -> PARTITION Jul2014 VALUES LESS THAN (TO_DAYS('2014-08-01')), 
    -> PARTITION Aug2014 VALUES LESS THAN (TO_DAYS('2014-09-01')), 
    -> PARTITION Sep2014 VALUES LESS THAN (TO_DAYS('2014-10-01')), 
    -> PARTITION Oct2014 VALUES LESS THAN (TO_DAYS('2014-11-01')), 
    -> PARTITION Nov2014 VALUES LESS THAN (TO_DAYS('2014-12-01')), 
    -> PARTITION Dec2014 VALUES LESS THAN (TO_DAYS('2015-01-01')), 
    -> PARTITION Jan2015 VALUES LESS THAN (TO_DAYS('2015-02-01')) 
    -> );
     
    mysql> INSERT INTO t2 VALUES (NULL,NOW(),1,NOW()); 
    mysql> HANDLER t2 OPEN AS t_handle; 
    mysql> HANDLER t_handle READ FIRST; 
    +-------+---------------------+-----------+---------------------+ 
    | t2_id | inserttimestamp | somevalue | rowLastUpdateTime | 
    +-------+---------------------+-----------+---------------------+ 
    | 1 | 2014-05-14 21:53:28 | 1 | 2014-05-14 21:53:28 | 
    +-------+---------------------+-----------+---------------------+ 
    mysql> select @@binlog_format\G 
    *************************** 1. row *************************** 
    @@binlog_format: ROW
     

    # mysqlbinlog --database=world mysql-bin.000002 | grep world | wc -l 
    22543# mysqlbinlog --rewrite-db='world->renameddb' mysql-bin.000002 | grep renameddb | wc -l 
    22542

    domingo, 19 de enero de 2014

    Puede replicación MySQL ponerse al día

    Original post: http://anothermysqldba.blogspot.com/2014/01/can-mysql-replication-catch-up.html

    Así que la replicación se ha mejorado recientemente en MySQL 5.6. Sin embargo, la gente sigue utilizando 5.1 y 5.5 por lo que algunas de estas mejoras tendrán que esperar para golpear el mundo real.

    Recientemente ayudé a paso en esta dirección con una solución de replicación de geo-localizada. Una parte del país tenía un servidor MySQL 5.1 y la otra parte del país tuvo un nuevo servidor MySQL 5.6 instalado.

    Después de lidiar con los problemas de obtener la copia de seguridad inicial de los datos desde el primario al servidor secundario (tardó varias horas para decir lo menos), tuve que decidir podría replicación ponerse al día y mantener el ritmo. El servidor principal tenía algunos grandes consultas y optimización es siempre un buen lugar para empezar. Tuve que hacer el servidor secundario tirando y aplicar lo más rápido que pude primero sin embargo.

    Así que aquí hay algunas cosas que debe revisar y tener en cuenta cuando se trata de la réplica. He añadido algunos enlaces de abajo que ayudan a apoyar mis pensamientos mientras trabajaba en esto.

    La replicación puede ser muy de E / S pesada. Dependiendo de su aplicación. Un sitio blog no tiene que muchas escrituras por lo que la replicación de E / S es la luz, pero un servidor primario en gran medida por escrito y actualizado va a conducir a un servidor de replicación escribir mucho relay_logs y binary_logs si están habilitadas. Los logs binarios pueden ser activados en la secundaria que le permite ejecutar copias de seguridad o usted puede ser que este servidor sea un primario a otros.

    Dividí los registros en una partición de datos diferente del directorio de datos.
    Esto se establece en el archivo my.cnf - relay-log

    El buffer de InnoDB ya se estableció en un valor de más de 10 GB. Esto fue suficiente para este servidor.
    El camarero fue más de 90.000 segundos por detrás todavía.

    Así que empecé a hacer algunos ajustes en el servidor y terminamos con estos ajustes en el final. Concedido cada servidor es diferente.

    mysql> select @ @ sync_relay_log_info \ G
    *************************** 1. fila ***************************
    @ @ Sync_relay_log_info: 0
    1 row in set (0.08 sec)

    mysql> select @ @ innodb_flush_log_at_trx_commit \ G
    *************************** 1. fila ***************************
    @ @ Innodb_flush_log_at_trx_commit: 2
    1 row in set (0.00 sec)

    mysql> select @ @ log_slave_updates \ G
    *************************** 1. fila ***************************
    @ @ Log_slave_updates: 0

    mysql> select @ @ sync_binlog \ G
    *************************** 1. fila ***************************
    @ @ Sync_binlog: 0
    1 row in set (0.00 sec)

    mysql> select @ @ max_relay_log_size \ G
    *************************** 1. fila ***************************
    @ @ Max_relay_log_size: 268435456

    Me volví el registro binario fuera como yo supervisé diferentes configuraciones y opciones para ayudar a la replicación de ponerse al día. Me tomó un tiempo. Algunos de los ajustes que ves arriba puede o no se han aplicado a medida que trabajaba dentro de este marco de tiempo. Sin embargo, no ponerse al día en 0 segundos atrás. Ahora usted puede notar que muchos de estos ajustes anteriores se relacionan en y alrededor del registro binario. Así que me encontré una pequeña prueba. Por lo tanto, he reiniciado y permitió a los registros de basura. Me registré en el servidor más tarde y encontró que 10,000 + segundos atrás. Así que una vez más, reinicié y desactivado los registros de basura. Se alcanzó (0 segundos detrás) con el servidor principal en menos de 15 minutos. Solía ​​Aurimas ' herramienta mientras veía a ponerse al día también. Si aún no lo use antes, es una herramienta muy agradable y práctico.

    Lo que todo esto significa es que el servidor principal debe ser conforme a ACID. Con esta configuración también está en función del sistema operativo para el caché y limpiar. Este es el servidor se puede utilizar como un servidor de lectura principalmente para alimentar a la información a los demás. También quiere decir que sí, la replicación geo-localizada puede mantenerse al día con un servidor primario.

    ¿Qué pasa si usted necesita parar el esclavo, se sigue ponerse al día rápidamente?

    ¿Cómo y por qué te detienes el esclavo es mi primera respuesta. Usted debe entrar en el hábito de usar SLAVE STOP SQL_THREAD , en lugar de SLAVE STOP ; Esto permite que los logs retardados continúen para recopilar datos y no aplicarlo a su servidor principal. Así que si usted puede tomar ventaja de que va a ayudar a reducir el tiempo que toma para que usted pueda rellenar los logs retardados después.

    Algunos de lectura adicional para usted:

    sábado, 7 de septiembre de 2013

    Acceso y replicación MySQL bloqueado por secure_auth

    Original post: http://anothermysqldba.blogspot.com/2013/09/mysql-access-and-replication-blocked-by.html

    ERROR 2049 (HY000): Connection using old (pre-4.1.1) authentication protocol refused (client option 'secure_auth' enabled)

    Si ha intentado conectarse a una base de datos MySQL y nos vemos este error, entonces usted necesita para tener hash de contraseña 41byte válida. Si no está seguro de que usted tiene ejecutar el SQL a continuación. Si usted tiene 16 contraseñas de caracteres que son contraseñas antiguas.

    select Password from mysql.user;

    Lo que sigue es cómo resolví esto como parte de una migración de MySQL 5.0 a MySQL 5.6.

    El servidor MySQL 5.0 tiene una mezcla de los mayores pre 4.1 passwords y contraseñas 41byte válidos. Dado que el servidor MySQL 5.0 tenía algunas cuentas con las contraseñas de más edad, decidí no volcar la tabla MySQL como parte de la configuración de replicación. Hice volcar todas las bases de datos, excepto la base de datos mysql. Esto permite aseguré que iba a mantener las mejoras de la tabla de MySQL 5.6 válidos.

    El servidor MySQL 5.6 instala fácilmente y se había levantado y he cargado los datos de volcado. Parte de la migración era utilizar la replicación mientras evaluaban la nueva base de datos. Mientras que en el servidor de MySQL 5.6 probé la cuenta de usuario de replicación. La respuesta que obtuve fue el error en la parte superior de esta página. Replicación no funciona, por supuesto, sin una cuenta de usuario válida. Por ello, los registros de error me estaba dando este error:
    [ERROR] Slave I/O: error connecting to master '<user>@<hostname>:3306' - retry-time: 10 retries: 68, Error_code: 2049

    Una rápida revisión de la cuenta en el servidor de MySQL 5.0 muestra que la nueva cuenta se estableció con el 4.1 pre contraseña. Así que tenía que actualizar la cuenta a un 41 byte contraseña válida.

    La siguiente consulta demostró que, efectivamente, tienen contraseñas antiguas habilitados. Así que tengo que desactivar eso y actualizar la cuenta de usuario de nuevo para establecer la contraseña como válidos 41 bytes hash.

    >SELECT @@session.old_passwords, @@global.old_passwords;
    +-------------------------+------------------------+
    | @@session.old_passwords | @@global.old_passwords |
    +-------------------------+------------------------+
    | 1 | 1 |
    +-------------------------+------------------------+
    1 row in set (0.00 sec)


    >SET @@session.old_passwords = 0;
    Query OK, 0 rows affected (0.00 sec)

    >GRANT REPLICATION SLAVE ON *.* TO '<user>'@'<ip_address>' IDENTIFIED BY '<Password>';
    Query OK, 0 rows affected (0.00 sec)

    Una verificación de la contraseña mostró la contraseña como la contraseña 41byte ahora. Esto me podía conectar al servidor principal desde el servidor secundario y evitar el error secure_auth. replicación muy sencillo conectar problema estaba resuelto.

    De cara al futuro que necesitaba para conseguir las cuentas de usuario de MySQL 5.0 en el servidor de MySQL 5.6. (Ya que ellos salté como parte de la construcción del servidor secundario.)

    El cliente necesitaba para establecer las subvenciones de nuevo para cada usuario independientemente de una contraseña válidos o no.
    Así que le di instrucciones a ejecutar el siguiente sql. Yo podría haber hecho esto, pero yo tendría que saber todas sus contraseñas y que no era necesario.

    Para cada usuario en su sistema. Usted no tiene que hacer el usuario root, porque ya tiene una cuenta de administrador válida en el sistema 5.6.

    >SET @@session.old_passwords = 0;
    >show grants for '<User>'@'<Host>';
    Para recopilar la sql necesaria para cada usuario ejecute el siguiente:
    SELECT CONCAT("SHOW GRANTS FOR '",User,"'@'",Host,"';") as sql_command from mysql.user;

    Para cada resultado dado ejecutar la sentencia "mostrar subvenciones" y luego ejecutar la instrucción dada.
    Los estados deben ser similar a la siguiente:

    GRANT USAGE ON *.* TO 'bob'@'%.example.org' IDENTIFIED BY 'cleartext password';

    Replicación y luego crea y se rellena la tabla de MySQL en el servidor de MySQL 5.6.

    Más se puede encontrar aquí:
    http://dev.mysql.com/doc/refman/5.6/en/password-hashing.html

    sábado, 10 de agosto de 2013

    Cree un servidor esclavo (secundario) con Percona Xtrabackup

    Original post: http://anothermysqldba.blogspot.com/2013/08/create-slave-secondary-server-with.html

    Así que primero usted podría ahorrar un poco de tiempo y leer el ejemplo Percona para esto:
    http://www.percona.com/doc/percona-xtrabackup/2.1/howtos/setting_up_replication.html

    Pero por si acaso aquí es un ejemplo basado en una situación real.

    SERVIDOR PRIMARIO

    # innobackupex /tmp/ <---- this is whatever directory you want to store the backup in. This is a very basic no fluff hot backup.

    InnoDB Backup Utility v1.5.1-xtrabackup; Copyright 2003, 2009 Innobase Oy
    .........
    130809 14:40:11 innobackupex: Connection to database server closed
    130809 14:40:11 innobackupex: completed OK!

    Asegúrese de ver el archivo xtrabackup_binlog_info. Si no lo hace no tendrá fácilmente la posición y la información de registro. Usted tendrá que excavar en los binlogs basadas en el tiempo, etc ¿Qué es más trabajo de lo que sea necesario.

    innobackupex --apply-log /tmp/<Timestamp Directory Here>

    Ahora depende de usted. Puede rsync el directorio al esclavo o alquitrán [gzip] y scp al esclavo. Independientemente del método para mover al esclavo, usted tiene una hotbackup creado y listo para funcionar.


    SERVIDOR SECUNDARIO

    # /etc/init.d/mysql stop
    mv /var/lib/mysql /var/lib/mysql_ORIG

    Sin embargo ha movido el archivo desde el maestro al esclavo, poner el contenido en la carpeta datadir, asumida por ejemplo: / var / lib / mysql.

    # chown -R mysql:mysql mysql
    /etc/init.d/mysql start
    Starting MySQL... [ OK ]

    Ahora en su servidor MySQL esclavo, puede configurar la información del usuario de replicación fácilmente.

    CHANGE MASTER TO
    MASTER_HOST='<MASTER_HOST>',
    MASTER_USER='<MASTER_USER>',
    MASTER_PASSWORD='<MASTER_PASSWORD>',
    MASTER_CONNECT_RETRY = 10 ;

    Obtener el registro y la posición del archivo xtrabackup.

    # more xtrabackup_binlog_info
    <BinLog info> <POSITION INFO>

    CHANGE MASTER TO MASTER_LOG_FILE='<BinLog info>', MASTER_LOG_POS=<POSITION INFO>;

    Start slave;


    Eso es en pocas palabras. Para más información revise la url Percona dada al principio.