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 को एक न्यूनतम संख्या पर सेट करें जो एक ही स्रोत के साथ कुछ पुन:प्रयास करने की अनुमति देता है, यदि कनेक्शन विफलता एक क्षणिक नेटवर्क के कारण होती है आउटेज।

एसिंक्रोनस कनेक्शन विफलता को कैसे सक्रिय करें

  • प्रतिकृति चैनल के लिए एसिंक्रोनस कनेक्शन विफलता को सक्रिय करने के लिए, चैनल के लिए CHANGE MASTER TO स्टेटमेंट पर SOURCE_CONNECTION_AUTO_FAILOVER=1 सेट करें।
  • हमारे पास दो नए कार्य हैं, जो स्रोत सूची से सर्वर प्रविष्टियों को जोड़ने और हटाने में मदद करेंगे।
    • asynchronous_connection_failover_add_source (स्रोत सूची से सर्वर प्रविष्टियां जोड़ें)
    • asynchronous_connection_failover_delete_source (स्रोत सूची से सर्वर प्रविष्टियां हटाएं)

इन फ़ंक्शंस का उपयोग करते समय, आपको ('चैनल', 'होस्ट', पोर्ट, 'नेटवर्क_नेमस्पेस', वज़न) जैसे तर्क निर्दिष्ट करने होंगे।

उदाहरण

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)

आईओ थ्रेड "कनेक्टिंग" स्थिति में है। इसका मतलब है कि यह मास्टर_रेट्री_काउंट और मास्टर_कनेक्ट_रेट्री सेटिंग्स के आधार पर मौजूदा स्रोत (नोड 1) से कनेक्शन स्थापित करने का प्रयास कर रहा है।

कुछ सेकंड के बाद, आप देख सकते हैं कि 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 का उपयोग करेंगे। मेरे पास क्लस्टरकंट्रोल द्वारा तैनात तीन नोड्स पीएक्ससी (5.7) हैं। मेरे पास मेरे पीएक्ससी नोड2 के तहत 8.0.22 प्रतिकृति दास है और हम क्लस्टरकंट्रोल का उपयोग करके इस रीड प्रतिकृति को जोड़ने जा रहे हैं।

चरण 1

प्रतिकृति नोड को पढ़ने के लिए ClusterControl नोड से पासवर्ड रहित SSH लॉगिन सेटअप करें।

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

चरण 2

ClusterControl पर जाएं और ड्रॉप डाउन आइकन पर क्लिक करें और प्रतिकृति स्लेव जोड़ें विकल्प चुनें।

चरण 3

फिर "मौजूदा प्रतिकृति स्लेव" विकल्प चुनें और रीड रेप्लिका आईपी दर्ज करें और फिर "प्रतिकृति स्लेव जोड़ें" पर क्लिक करें।

चरण 4

एक कार्य शुरू हो जाएगा और आप ClusterControl> Logs> Jobs पर प्रगति की निगरानी कर सकते हैं। एक बार प्रक्रिया पूरी हो जाने के बाद, दास आपके अवलोकन पृष्ठ में दिखाई देगा जैसा कि निम्न स्क्रीनशॉट में हाइलाइट किया गया है।

अब आप ClusterControl> टोपोलॉजी 

पर वर्तमान टोपोलॉजी की जांच कर सकते हैं

प्रतिकृति स्वतः विफलता प्रक्रिया

अब मैं फेलओवर टेस्टिंग करने जा रहा हूं और मेरी रीड रेप्लिका में इस फंक्शन (एसिंक्रोनस_कनेक्शन_फेलओवर_एड_सोर्स) में नीचे दी गई सेटिंग्स को जोड़ा है।

 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.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Linux में MySQL या MariaDB का रूट पासवर्ड कैसे बदलें

  2. Oracle डाटाबेस लिंक - MySQL समतुल्य?

  3. MySQL के लिए सर्वश्रेष्ठ DBaaS समाधान

  4. MySQL में MID () फ़ंक्शन कैसे काम करता है

  5. एक अतिरिक्त क्षेत्र के साथ सिद्धांत 2 और कई-से-अनेक लिंक तालिका