sql >> Database teknologi >  >> RDS >> Mysql

Asynkron replikering automatisk failover i MySQL 8.0.22

 

Oracle udgav for nylig MySQL 8.0.22, og denne nye version kom med en ny asynkron forbindelses-failover-mekanisme. Det giver en replika mulighed for automatisk at etablere en asynkron replikeringsforbindelse til en ny kilde, hvis dens eksisterende fejler.

I denne blog vil vi se på denne forbindelses failover-mekanisme.

Oversigt

Den asynkrone failover-mekanisme kan bruges til at holde en replika synkroniseret med en gruppe servere, der deler data (Multisource-slave). Det vil flytte replikeringsforbindelsen til en ny kilde, når den eksisterende kildeforbindelse mislykkes.

Arbejdsprincip

Når den eksisterende forbindelseskilde fejler, prøver replikaen først den samme forbindelse igen i det antal gange, der er angivet af MASTER_RETRY_COUNT. Intervallet mellem forsøg er indstillet af MASTER_CONNECT_RETRY-indstillingen. Når disse forsøg er udtømt, overtager den asynkrone forbindelse failover-mekanisme failover-processen.

Bemærk, at MASTER_RETRY_COUNT som standard er 86400 (1 dag --> 24 timer) og MASTER_CONNECT_RETRY standardværdien er 60.

For at sikre, at den asynkrone forbindelsesfejlmekanisme kan aktiveres omgående, skal du indstille MASTER_RETRY_COUNT til et minimalt antal, der kun tillader et par genforsøg med den samme kilde, i tilfælde af at forbindelsesfejlen er forårsaget af et forbigående netværk udfald.

Sådan aktiveres asynkron forbindelsesfejl

  • For at aktivere asynkron forbindelsesfejl for en replikeringskanal skal du indstille SOURCE_CONNECTION_AUTO_FAILOVER=1 på CHANGE MASTER TO-sætningen for kanalen.
  • Vi har to nye funktioner, som vil hjælpe med at tilføje og slette serverposterne fra kildelisten.
    • asynchronous_connection_failover_add_source (tilføj serverposterne fra kildelisten)
    • asynchronous_connection_failover_delete_source (slet serverposterne fra kildelisten)

Mens du bruger disse funktioner, skal du angive argumenter som ('kanal', 'vært', port, 'netværksnavneområde', vægt).

Eksempel

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)

Kildeserverne skal konfigureres i tabellen "mysql.replication_asynchronous_connection_failover". Vi kan også bruge tabellen "performance_schema.replication_asynchronous_connection_failover" til at se de tilgængelige servere på kildelisten.

Bemærk:Hvis du ikke bruger nogen kanalbaseret replikering, vil denne failover-mekanisme fungere. Mens du kører change master-sætningen, er der ingen grund til at nævne noget kanalnavn. Men sørg for, at GTID er aktiveret på alle serverne.

Produktionsbrug

Sig, at du har tre PXC-5.7 noder med produktionsdata, der kører bag ProxySQL. Nu vil vi konfigurere den kanalbaserede asynkrone replikering under node 1 (192.168.33.12).

  • node 1 - 192.168.33.12
  • node 2 - 192.168.33.13
  • node 3 - 192.168.33.14
  • Læs replika - 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)

Arkitekturdiagram

Testtilfælde 1

Vi vil tilføje failover-indstillingerne:

 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)

Ok alt godt, jeg kan aktivere auto_failover. Lad os stoppe node 1 (192.168.33.12) MySQL. ProxySQL vil promovere den næste passende master. 

[[email protected] lib]# service mysqld stop

Redirecting to /bin/systemctl stop mysqld.service

I replikaserveren

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-tråden er i "connecting"-tilstand. Det betyder, at den forsøger at etablere forbindelsen fra den eksisterende kilde (node ​​1) baseret på indstillingerne master_retry_count og master_connect_retry.

Efter et par sekunder kan du se, at source_host blev ændret til node 2 (192.168.33.13). Nu er failoveren udført.

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:

Fra fejlloggen

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)

Testcase 2 

Når du kører change master-sætningen, er der ingen grund til at nævne noget kanalnavn, uanset om du bruger kanalbaseret replikering eller ej.

Eksempel

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)

Tilføj derefter failover-indstillingerne som nedenfor,

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)

Nu vil jeg stoppe node 1 (192.168.33.12).

replikeringsfejl

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)

Fra fejlloggen 

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.

Brug af ClusterControl

Nu vil vi bruge ClusterControl til at gentage denne automatiske failover-proces. Jeg har tre noder pxc (5.7) implementeret af ClusterControl. Jeg har en 8.0.22 replikeringsslave under min PXC node2, og vi vil tilføje denne læsereplika ved hjælp af ClusterControl.

Trin 1

Konfigurer det adgangskodeløse SSH-login fra ClusterControl-knudepunktet for at læse replika-noden.

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

Trin 2

Gå til ClusterControl, klik på rullemenuen, og vælg Tilføj replikeringsslave.

Trin 3

Vælg derefter "Eksisterende replikeringsslave" og indtast den læste replika-IP, og klik derefter på "Tilføj replikeringsslave".

Trin 4

Et job vil blive udløst, og du kan overvåge fremskridtene på ClusterControl> Logs> Jobs. Når processen er fuldført, vil slaven dukke op på din oversigtsside som fremhævet på det følgende skærmbillede.

Nu kan du tjekke den aktuelle topologi på ClusterControl> Topologi 

Replica Auto Failover Process

Nu skal jeg lave failover-test og tilføjede nedenstående indstillinger til denne funktion (asynchronous_connection_failover_add_source) i min læsereplika.

 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)

Jeg vil stoppe node 2 (192.168.33.13). I ClusterControl er parameteren (enable_cluster_autorecovery) aktiveret, så den vil fremme den næste passende master.

Nu er min nuværende master nede, så læsereplikaen forsøger at oprette forbindelse igen mesteren.

replikeringsfejl fra læst replika

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)

Når ClusterControl promoverer den næste passende master, vil min læsereplika oprette forbindelse til en hvilken som helst af de tilgængelige klynge noder.

Den automatiske failover-proces er fuldført, og min læste replika er sluttet tilbage til node 1 (192.168.33.13) server.

Konklusion

Dette er en af ​​de fantastiske funktioner i MySQL, der er ingen manuel indgriben nødvendig. Denne automatiske failover-proces kan spare dig noget tid. Og det reducerer replika-serverafbrydelsen. Værd at bemærke, da min gamle master kom tilbage til rotation, ville replikeringsforbindelsen ikke skifte tilbage til den gamle master.


  1. Deaktiver root-login i phpMyAdmin

  2. Tilslutning af Ignition til Microsoft Access

  3. Sådan aktiveres den langsomme forespørgselslog i MySQL

  4. hvordan man lægger database og læser database fra aktivmappe android, som er oprettet og eksporteret i sqllite