Mysql
 sql >> база данни >  >> RDS >> Mysql

Асинхронно репликация Автоматично отказване в MySQL 8.0.22

 

Oracle наскоро пусна MySQL 8.0.22 и тази нова версия дойде с нов механизъм за преодоляване на асинхронна връзка. Позволява на реплика автоматично да установи връзка за асинхронна репликация към нов източник, в случай че съществуващият не успее.

В този блог ще разгледаме този механизъм за преодоляване на връзката.

Общ преглед

Механизмът за асинхронно превключване при отказ може да се използва за поддържане на синхронизиране на реплика с група сървъри, които споделят данни (подчинен сървър с множество източници). Той ще премести връзката за репликация към нов източник, когато съществуващата връзка с източник се провали.

Принцип на работа

Когато съществуващият източник на връзка не успее, репликата първо пробва същата връзка за броя пъти, посочен от MASTER_RETRY_COUNT. Интервалът между опитите се задава от опцията MASTER_CONNECT_RETRY. Когато тези опити са изчерпани, механизмът за преодоляване на асинхронна връзка поема процеса на отказ.

Обърнете внимание, че по подразбиране MASTER_RETRY_COUNT е 86400 (1 ден --> 24 часа), а стойността по подразбиране MASTER_CONNECT_RETRY е 60.

За да гарантирате, че механизмът за преодоляване на асинхронна връзка може да бъде активиран незабавно, задайте MASTER_RETRY_COUNT на минимален брой, който позволява само няколко опита за повторен опит със същия източник, в случай че повредата на връзката е причинена от преходна мрежа прекъсване.

Как да активирате отказ на асинхронна връзка

  • За да активирате преодоляване на асинхронна връзка за канал за репликация, задайте SOURCE_CONNECTION_AUTO_FAILOVER=1 в оператора CHANGE MASTER TO за канала.
  • Имаме две нови функции, които ще ви помогнат да добавяте и изтривате записите на сървъра от списъка с източници.
    • asynchronous_connection_failover_add_source (добавете записите на сървъра от списъка с източници)
    • asynchronous_connection_failover_delete_source (изтрийте записите на сървъра от списъка с източници)

Докато използвате тези функции, трябва да посочите аргументите като ('channel','host',port,'network_namespace',weight).

Пример

mysql> select asynchronous_connection_failover_add_source('testing', '192.168.33.12', 3306, '', 100);

+----------------------------------------------------------------------------------------+

| asynchronous_connection_failover_add_source('testing', '192.168.33.12', 3306, '', 100) |

+----------------------------------------------------------------------------------------+

| The UDF asynchronous_connection_failover_add_source() executed successfully.           |

+----------------------------------------------------------------------------------------+

1 row in set (0.00 sec)

Изходните сървъри трябва да бъдат конфигурирани в таблицата "mysql.replication_asynchronous_connection_failover". Можем също да използваме таблицата „performance_schema.replication_asynchronous_connection_failover“, за да прегледаме наличните сървъри в списъка с източници.

Забележка:Ако не използвате репликация, базирана на канал, този механизъм за преодоляване на срив ще работи. Докато изпълнявате главния оператор за промяна, няма нужда да споменавате име на канал. Но се уверете, че GTID е активиран на всички сървъри.

Случаи на производствена употреба

Да приемем, че имате три PXC-5.7 възела с производствени данни, работещи зад ProxySQL. Сега ще конфигурираме базираната на канал асинхронна репликация под възел 1 (192.168.33.12).

  • възел 1 - 192.168.33.12
  • възел 2 - 192.168.33.13
  • възел 3 - 192.168.33.14
  • Прочетете реплика - 192.168.33.15
mysql> change master to master_user='repl',master_password='[email protected]',master_host='192.168.33.12',master_auto_position=1,source_connection_auto_failover=1,master_retry_count=3,master_connect_retry=6 for channel "prod_replica";

Query OK, 0 rows affected, 2 warnings (0.01 sec)



mysql> start replica for channel 'prod_replica';

Query OK, 0 rows affected (0.00 sec)

Архитектурна диаграма

Тестов случай 1

Ще добавим настройките за отказ:

 mysql> select asynchronous_connection_failover_add_source('prod_replica', '192.168.33.12', 3306, '', 100);

+---------------------------------------------------------------------------------------------+

| asynchronous_connection_failover_add_source('prod_replica', '192.168.33.12', 3306, '', 100) |

+---------------------------------------------------------------------------------------------+

| The UDF asynchronous_connection_failover_add_source() executed successfully.            |

+---------------------------------------------------------------------------------------------+

1 row in set (0.00 sec)



mysql>  select asynchronous_connection_failover_add_source('prod_replica', '192.168.33.13', 3306, '', 80);

+--------------------------------------------------------------------------------------------+

| asynchronous_connection_failover_add_source('prod_replica', '192.168.33.13', 3306, '', 80) |

+--------------------------------------------------------------------------------------------+

| The UDF asynchronous_connection_failover_add_source() executed successfully.               |

+--------------------------------------------------------------------------------------------+

1 row in set (0.01 sec)



mysql>  select asynchronous_connection_failover_add_source('prod_replica', '192.168.33.14', 3306, '', 60);

+--------------------------------------------------------------------------------------------+

| asynchronous_connection_failover_add_source('prod_replica', '192.168.33.14', 3306, '', 60) |

+--------------------------------------------------------------------------------------------+

| The UDF asynchronous_connection_failover_add_source() executed successfully.            |

+--------------------------------------------------------------------------------------------+

1 row in set (0.00 sec)




mysql> select * from mysql.replication_asynchronous_connection_failover;

+-------------------+---------------+------+-------------------+--------+

| Channel_name | Host         | Port | Network_namespace | Weight |

+-------------------+---------------+------+-------------------+--------+

| prod_replica      | 192.168.33.12 | 3306 |                   |    100 |

| prod_replica      | 192.168.33.13 | 3306 |                   |     80 |

| prod_replica      | 192.168.33.14 | 3306 |                   |     60 |

+-------------------+---------------+------+-------------------+--------+

3 rows in set (0.00 sec)

Добре, всичко е наред, мога да активирам auto_failover. Нека спрем възел 1 (192.168.33.12) MySQL. ProxySQL ще популяризира следващия подходящ главен код. 

[[email protected] lib]# service mysqld stop

Redirecting to /bin/systemctl stop mysqld.service

В сървъра реплика

mysql> show replica status\G

*************************** 1. row ***************************

               Slave_IO_State: Reconnecting after a failed master event read

                  Master_Host: 192.168.33.12

                  Master_User: repl

                  Master_Port: 3306

                Connect_Retry: 6

              Master_Log_File: binlog.000004

          Read_Master_Log_Pos: 1143

               Relay_Log_File: relay-bin-testing.000006

                Relay_Log_Pos: 1352

        Relay_Master_Log_File: binlog.000004

             Slave_IO_Running: Connecting

            Slave_SQL_Running: Yes

              Replicate_Do_DB: 

Last_IO_Error: error reconnecting to master '[email protected]:3306' - retry-time: 10 retries: 2 message: Can't connect to MySQL server on '192.168.33.12' (111)

Нишката за IO е в състояние "свързване". Това означава, че се опитва да установи връзката от съществуващия източник (възел 1) въз основа на настройките master_retry_count и master_connect_retry .

След няколко секунди можете да видите, че source_host е променен на възел 2 (192.168.33.13). Сега преминаването при отказ е извършено.

mysql> show replica status\G

*************************** 1. row ***************************

               Slave_IO_State: Waiting for master to send event

                  Master_Host: 192.168.33.13

                  Master_User: repl

                  Master_Port: 3306

                Connect_Retry: 6

              Master_Log_File: binlog.000004

          Read_Master_Log_Pos: 1162

               Relay_Log_File: relay-bin-testing.000007

                Relay_Log_Pos: 487

        Relay_Master_Log_File: binlog.000004

             Slave_IO_Running: Yes

            Slave_SQL_Running: Yes

             Last_IO_Error:

От регистъра на грешките

2020-10-29T22:22:05.679951Z 54 [ERROR] [MY-010584] [Repl] Slave I/O for channel 'prod_replica': error reconnecting to master '[email protected]:3306' - retry-time: 10 retries: 3 message: Can't connect to MySQL server on '192.168.33.12' (111), Error_code: MY-002003

2020-10-29T22:22:05.681121Z 58 [Warning] [MY-010897] [Repl] Storing MySQL user name or password information in the master info repository is not secure and is therefore not recommended. Please consider using the USER and PASSWORD connection options for START SLAVE; see the 'START SLAVE Syntax' in the MySQL Manual for more information.

2020-10-29T22:22:05.682830Z 58 [System] [MY-010562] [Repl] Slave I/O thread for channel 'prod_replica': connected to master '[email protected]:3306',replication started in log 'FIRST' at position 2660

2020-10-29T22:22:05.685175Z 58 [Warning] [MY-010549] [Repl] The master's UUID has changed, although this should not happen unless you have changed it manually. The old UUID was 31b5b7d0-1a25-11eb-8076-080027090068.

(END)

Тестов случай 2 

Докато изпълнявате главния израз за промяна, няма нужда да споменавате име на канал, независимо дали използвате репликация, базирана на канал, или не.

Пример

mysql> change master to master_user='repl',master_password='[email protected]',master_host='192.168.33.12',master_auto_position=1,source_connection_auto_failover=1,master_retry_count=3,master_connect_retry=10;

Query OK, 0 rows affected, 2 warnings (0.01 sec)



mysql> start replica;

Query OK, 0 rows affected (0.00 sec)

След това добавете настройките за преминаване при отказ, както е по-долу,

select asynchronous_connection_failover_add_source('', '192.168.33.12', 3306, '', 100);

select asynchronous_connection_failover_add_source('', '192.168.33.13', 3306, '', 80);

select asynchronous_connection_failover_add_source('', '192.168.33.14', 3306, '', 60);



 mysql> select * from mysql.replication_asynchronous_connection_failover;

+--------------+---------------+------+-------------------+--------+

| Channel_name | Host          | Port | Network_namespace | Weight |

+--------------+---------------+------+-------------------+--------+

|              | 192.168.33.12 | 3306 |                   |    100 |

|              | 192.168.33.13 | 3306 |                   |     80 |

|              | 192.168.33.14 | 3306 |                   |     60 |

+--------------+---------------+------+-------------------+--------+

3 rows in set (0.00 sec)

Сега ще спра възел 1 (192.168.33.12).

Грешка при репликация

Last_IO_Error: error connecting to master '[email protected]:3306' - retry-time: 10 retries: 2 message: Can't connect to MySQL server on '192.168.33.12' (111)

От регистъра на грешките 

2020-10-30T00:38:03.471482Z 27 [ERROR] [MY-010584] [Repl] Slave I/O for channel '': error connecting to master '[email protected]:3306' - retry-time: 10 retries: 3 message: Can't connect to MySQL server on '192.168.33.12' (111), Error_code: MY-002003

2020-10-30T00:38:03.472002Z 29 [Warning] [MY-010897] [Repl] Storing MySQL user name or password information in the master info repository is not secure and is therefore not recommended. Please consider using the USER and PASSWORD connection options for START SLAVE; see the 'START SLAVE Syntax' in the MySQL Manual for more information.

2020-10-30T00:38:03.473493Z 29 [System] [MY-010562] [Repl] Slave I/O thread for channel '': connected to master '[email protected]:3306',replication started in log 'FIRST' at position 234

2020-10-30T00:38:03.475471Z 29 [Warning] [MY-010549] [Repl] The master's UUID has changed, although this should not happen unless you have changed it manually. The old UUID was 1ff8a919-1a39-11eb-a27a-080027090068.

Използване на ClusterControl

Сега ще използваме ClusterControl, за да повторим този процес на автоматичен отказ. Имам три възела pxc (5.7), разположени от ClusterControl. Имам подчинен 8.0.22 под моя PXC node2 и ще добавим тази реплика за четене с помощта на ClusterControl.

Стъпка 1

Настройте SSH вход без парола от възела ClusterControl за четене на възел реплика.

$ ssh-copy-id -i ~/.ssh/id_rsa 192.168.33.15

Стъпка 2

Отидете на ClusterControl и щракнете върху иконата на падащото меню и изберете опцията Добавяне на подчинен елемент за репликация.

Стъпка 3

След това изберете опцията „Съществуващо подчинено устройство за репликация“ и въведете IP адреса на репликата за четене, след което щракнете върху „Добавяне на подчинено устройство за репликация“.

Стъпка 4

Ще се задейства задание и можете да наблюдавате напредъка в ClusterControl> Регистри> Задачи. След като процесът приключи, подчиненият ще се покаже във вашата страница с преглед, както е подчертано на следващата екранна снимка.

Сега можете да проверите текущата топология в ClusterControl> Топология 

Процес за автоматично преодоляване на репликата

Сега ще направя тест за преминаване при отказ и ще добавя следните настройки към тази функция (asynchronous_connection_failover_add_source) в моята реплика за четене.

 select asynchronous_connection_failover_add_source('prod_replica', '192.168.33.12', 3306, '', 100);

 select asynchronous_connection_failover_add_source('prod_replica', '192.168.33.13', 3306, '', 80);

 select asynchronous_connection_failover_add_source('prod_replica', '192.168.33.14', 3306, '', 60);



mysql> select * from mysql.replication_asynchronous_connection_failover;

+--------------+---------------+------+-------------------+--------+

| Channel_name | Host          | Port | Network_namespace | Weight |

+--------------+---------------+------+-------------------+--------+

| prod_replica | 192.168.33.12 | 3306 |                   |    100 |

| prod_replica | 192.168.33.13 | 3306 |                   |     80 |

| prod_replica | 192.168.33.14 | 3306 |                   |     60 |

+--------------+---------------+------+-------------------+--------+

3 rows in set (0.00 sec)



mysql> select CONNECTION_RETRY_INTERVAL,CONNECTION_RETRY_COUNT,SOURCE_CONNECTION_AUTO_FAILOVER from performance_schema.replication_connection_conf

iguration;

+---------------------------+------------------------+---------------------------------+

| CONNECTION_RETRY_INTERVAL | CONNECTION_RETRY_COUNT | SOURCE_CONNECTION_AUTO_FAILOVER |

+---------------------------+------------------------+---------------------------------+

|                         6 |                      3 | 1                               |

+---------------------------+------------------------+---------------------------------+

1 row in set (0.00 sec)

Ще спра възел 2 (192.168.33.13). В ClusterControl параметърът (enable_cluster_autorecovery) е активиран, така че ще популяризира следващия подходящ главен код.

Сега текущият ми главен код не работи, така че репликата за четене се опитва да се свърже отново господарят.

Грешка при репликация от реплика за четене

Last_IO_Error: error connecting to master '[email protected]:3306' - retry-time: 6 retries: 2 message: Can't connect to MySQL server on '192.168.33.13' (111)

След като ClusterControl популяризира следващия подходящ главен код, моята реплика за четене ще се свърже с всеки един от наличните възли на клъстера.

Процесът за автоматично преминаване при отказ е завършен и моята реплика за четене се присъедини обратно към възел 1 (192.168.33.13) сървър.

Заключение

Това е една от страхотните функции в MySQL, не е необходима ръчна намеса. Този процес на автоматичен отказ може да ви спести известно време. И намалява прекъсването на сървъра за реплика. Заслужава да се отбележи, че когато старият ми главен код се върне към ротация, връзката за репликация нямаше да се превключи обратно към стария главен код.


  1. Database
    2.   
  2. Mysql
    3.   
  3. Oracle
    4.   
  4. Sqlserver
    5.   
  5. PostgreSQL
    6.   
  6. Access
    7.   
  7. SQLite
    8.   
  8. MariaDB

  1. SQL SERVER 2016 – Сравняване на планове за изпълнение

  2. Търсете всички срещания на низ в база данни на mysql

  3. MySQL INSERT INTO table VALUES.. срещу INSERT INTO table SET

  4. Ръководство за проектиране на база данни за бюлетин в MySQL

  5. Как да получите данни за последните 12 месеца в MySQL