MariaDB
 sql >> डेटाबेस >  >> RDS >> MariaDB

कम आरटीओ के साथ आपदा वसूली के लिए कई विलंबित प्रतिकृति दास

विलंबित प्रतिकृति एक प्रतिकृति दास को कम से कम एक निर्दिष्ट समय तक जानबूझकर मास्टर से पीछे रहने की अनुमति देती है। किसी ईवेंट को निष्पादित करने से पहले, दास पहले प्रतीक्षा करेगा, यदि आवश्यक हो, तब तक, जब तक कि मास्टर पर ईवेंट बनाए जाने के बाद दिया गया समय बीत न जाए। नतीजा यह होता है कि गुलाम कुछ समय पहले मालिक की स्थिति को प्रतिबिंबित करेगा। यह सुविधा MySQL 5.6 और MariaDB 10.2.3 से समर्थित है। यह आकस्मिक डेटा विलोपन के मामले में काम आ सकता है, और यह आपकी आपदा पुनर्प्राप्ति योजना का हिस्सा होना चाहिए।

विलंबित प्रतिकृति दास को स्थापित करते समय समस्या यह है कि हमें कितना विलंब करना चाहिए। बहुत कम समय और आप अपने विलंबित दास को प्राप्त होने से पहले खराब क्वेरी को जोखिम में डालते हैं, इस प्रकार विलंबित दास होने की बात को बर्बाद कर देते हैं। वैकल्पिक रूप से, आपके पास विलंबित समय इतना लंबा हो सकता है कि आपके विलंबित दास को उस स्थान तक पहुंचने में घंटों लग जाएं जहां त्रुटि के समय मास्टर था।

सौभाग्य से डॉकर के साथ, प्रक्रिया अलगाव इसकी ताकत है। डॉकर के साथ कई MySQL इंस्टेंस चलाना बहुत सुविधाजनक है। यह हमारे पुनर्प्राप्ति समय को बेहतर बनाने और हार्डवेयर संसाधनों को बचाने के लिए हमें एक ही भौतिक होस्ट के भीतर कई विलंबित दास रखने की अनुमति देता है। अगर आपको लगता है कि 15 मिनट की देरी बहुत कम है, तो हमारे पास हमारे डेटाबेस के पुराने स्नैपशॉट के लिए 1 घंटे की देरी या 6 घंटे के साथ एक और उदाहरण हो सकता है।

इस ब्लॉग पोस्ट में, हम डॉकर के साथ एक ही भौतिक होस्ट पर कई MySQL विलंबित दासों को तैनात करने जा रहे हैं, और कुछ पुनर्प्राप्ति परिदृश्य दिखाएंगे। निम्नलिखित आरेख हमारे अंतिम आर्किटेक्चर को दिखाता है जिसे हम बनाना चाहते हैं:

हमारे आर्किटेक्चर में पहले से ही तैनात 2-नोड MySQL प्रतिकृति शामिल है जो भौतिक सर्वर (नीला) पर चल रहा है और हम निम्नलिखित व्यवहार के साथ एक और तीन MySQL दास (हरा) स्थापित करना चाहते हैं:

  • 15 मिनट की देरी
  • 1 घंटे की देरी
  • 6 घंटे की देरी

ध्यान दें कि हमारे पास एक ही भौतिक सर्वर पर ठीक उसी डेटा की 3 प्रतियां होने जा रही हैं। सुनिश्चित करें कि हमारे डॉकर होस्ट के पास आवश्यक भंडारण है, इसलिए पहले से पर्याप्त डिस्क स्थान आवंटित करें।

MySQL मास्टर तैयारी

सबसे पहले, मास्टर सर्वर में लॉग इन करें और प्रतिकृति उपयोगकर्ता बनाएं:

mysql> GRANT REPLICATION SLAVE ON *.* TO [email protected]'%' IDENTIFIED BY 'YlgSH6bLLy';

फिर, मास्टर पर एक PITR-संगत बैकअप बनाएँ:

$ mysqldump -uroot -p --flush-privileges --hex-blob --opt --master-data=1 --single-transaction --skip-lock-tables --skip-lock-tables --triggers --routines --events --all-databases | gzip -6 -c > mysqldump_complete.sql.gz

यदि आप ClusterControl का उपयोग कर रहे हैं, तो आप आसानी से PITR-संगत बैकअप बना सकते हैं। बैकअप पर जाएं -> बैकअप बनाएं और "डंप प्रकार" ड्रॉपडाउन के तहत "पूर्ण PITR-संगत" चुनें:

अंत में, इस बैकअप को डॉकर होस्ट में स्थानांतरित करें:

$ scp mysqldump_complete.sql.gz [email protected]:~

इस बैकअप फ़ाइल का उपयोग MySQL स्लेव कंटेनर द्वारा स्लेव बूटस्ट्रैपिंग प्रक्रिया के दौरान किया जाएगा, जैसा कि अगले भाग में दिखाया गया है।

विलंबित दास परिनियोजन

हमारी डॉकर कंटेनर निर्देशिका तैयार करें। प्रत्येक MySQL कंटेनर के लिए 3 निर्देशिकाएं बनाएं (mysql.conf.d, datadir और sql) जिसे हम लॉन्च करने जा रहे हैं (आप नीचे दिए गए आदेशों को सरल बनाने के लिए लूप का उपयोग कर सकते हैं):

$ mkdir -p /storage/mysql-slave-15m/mysql.conf.d
$ mkdir -p /storage/mysql-slave-15m/datadir
$ mkdir -p /storage/mysql-slave-15m/sql
$ mkdir -p /storage/mysql-slave-1h/mysql.conf.d
$ mkdir -p /storage/mysql-slave-1h/datadir
$ mkdir -p /storage/mysql-slave-1h/sql
$ mkdir -p /storage/mysql-slave-6h/mysql.conf.d
$ mkdir -p /storage/mysql-slave-6h/datadir
$ mkdir -p /storage/mysql-slave-6h/sql

"mysql.conf.d" निर्देशिका हमारी कस्टम MySQL कॉन्फ़िगरेशन फ़ाइल को संग्रहीत करेगी और /etc/mysql.conf.d के अंतर्गत कंटेनर में मैप की जाएगी। "डेटादिर" वह जगह है जहाँ हम चाहते हैं कि डॉकर MySQL डेटा निर्देशिका को संग्रहीत करे, जो कंटेनर के /var/lib/mysql पर मैप करता है और "sql" निर्देशिका हमारी SQL फ़ाइलों - बैकअप फ़ाइलों को .sql या .sql.gz प्रारूप में चरण में संग्रहीत करती है। प्रतिकृति से पहले दास और प्रतिकृति कॉन्फ़िगरेशन और स्टार्टअप को स्वचालित करने के लिए .sql फ़ाइलें भी।

15 मिनट विलंबित दास

हमारे 15 मिनट के विलंबित दास के लिए MySQL कॉन्फ़िगरेशन फ़ाइल तैयार करें:

$ vim /storage/mysql-slave-15m/mysql.conf.d/my.cnf

और निम्नलिखित पंक्तियाँ जोड़ें:

[mysqld]
server_id=10015
binlog_format=ROW
log_bin=binlog
log_slave_updates=1
gtid_mode=ON
enforce_gtid_consistency=1
relay_log=relay-bin
expire_logs_days=7
read_only=ON

** इस दास के लिए हमने जिस सर्वर-आईडी का उपयोग किया है वह 10015 है।

अगला, /storage/mysql-slave-15m/sql निर्देशिका के अंतर्गत, दो SQL फ़ाइलें बनाएं, एक RESET MASTER (1reset_master.sql) के लिए और दूसरी CHANGE MASTER कथन (3setup_slave.sql) का उपयोग करके प्रतिकृति लिंक स्थापित करने के लिए।

टेक्स्ट फ़ाइल 1reset_master.sql बनाएं और निम्न पंक्ति जोड़ें:

RESET MASTER;

टेक्स्ट फ़ाइल 3setup_slave.sql बनाएं और निम्न पंक्तियां जोड़ें:

CHANGE MASTER TO MASTER_HOST = '192.168.55.171', MASTER_USER = 'rpl_user', MASTER_PASSWORD = 'YlgSH6bLLy', MASTER_AUTO_POSITION = 1, MASTER_DELAY=900;
START SLAVE;

MASTER_DELAY=900 15 मिनट (सेकंड में) के बराबर है। फिर हमारे मास्टर से ली गई बैकअप फ़ाइल (जिसे हमारे डॉकर होस्ट में स्थानांतरित कर दिया गया है) को "sql" निर्देशिका में कॉपी करें और इसका नाम बदलकर 2mysqldump_complete.sql.gz:

कर दें। 
$ cp ~/mysqldump_complete.tar.gz /storage/mysql-slave-15m/sql/2mysqldump_complete.tar.gz

हमारी "sql" निर्देशिका का अंतिम रूप कुछ इस तरह होना चाहिए:

$ pwd
/storage/mysql-slave-15m/sql
$ ls -1
1reset_master.sql
2mysqldump_complete.sql.gz
3setup_slave.sql

ध्यान दें कि जब डॉकर MySQL कंटेनर को इनिशियलाइज़ करता है तो निष्पादन क्रम निर्धारित करने के लिए हम SQL फ़ाइल नाम को एक पूर्णांक के साथ उपसर्ग करते हैं।

एक बार सब कुछ हो जाने के बाद, हमारे 15 मिनट के विलंबित दास के लिए MySQL कंटेनर चलाएँ:

$ docker run -d \
--name mysql-slave-15m \
-e MYSQL_ROOT_PASSWORD=password \
--mount type=bind,source=/storage/mysql-slave-15m/datadir,target=/var/lib/mysql \
--mount type=bind,source=/storage/mysql-slave-15m/mysql.conf.d,target=/etc/mysql/mysql.conf.d \
--mount type=bind,source=/storage/mysql-slave-15m/sql,target=/docker-entrypoint-initdb.d \
mysql:5.7

** MYSQL_ROOT_PASSWORD मान मास्टर पर MySQL रूट पासवर्ड के समान होना चाहिए।

निम्नलिखित पंक्तियाँ हैं जो हम यह सत्यापित करने के लिए देख रहे हैं कि क्या MySQL सही ढंग से चल रहा है और हमारे स्वामी के दास के रूप में जुड़ा हुआ है (192.168.55.171):

$ docker logs -f mysql-slave-15m
...
2018-12-04T04:05:24.890244Z 0 [Note] mysqld: ready for connections.
Version: '5.7.24-log'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  MySQL Community Server (GPL)
2018-12-04T04:05:25.010032Z 2 [Note] Slave I/O thread for channel '': connected to master '[email protected]:3306',replication started in log 'FIRST' at position 4

फिर आप निम्नलिखित कथन के साथ प्रतिकृति स्थिति सत्यापित कर सकते हैं:

$ docker exec -it mysql-slave-15m mysql -uroot -p -e 'show slave status\G'
...
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
                    SQL_Delay: 900
                Auto_Position: 1
...

इस समय, हमारा 15-मिनट विलंबित स्लेव कंटेनर सही ढंग से नकल कर रहा है और हमारा आर्किटेक्चर कुछ इस तरह दिख रहा है:

1 घंटे विलंबित दास

हमारे 1 घंटे के विलंबित दास के लिए MySQL कॉन्फ़िगरेशन फ़ाइल तैयार करें:

$ vim /storage/mysql-slave-1h/mysql.conf.d/my.cnf

और निम्नलिखित पंक्तियाँ जोड़ें:

[mysqld]
server_id=10060
binlog_format=ROW
log_bin=binlog
log_slave_updates=1
gtid_mode=ON
enforce_gtid_consistency=1
relay_log=relay-bin
expire_logs_days=7
read_only=ON

** इस दास के लिए हमने जिस सर्वर-आईडी का उपयोग किया है वह 10060 है।

अगला, /storage/mysql-slave-1h/sql निर्देशिका के अंतर्गत, दो SQL फ़ाइलें बनाएं, एक RESET MASTER (1reset_master.sql) के लिए और दूसरी CHANGE MASTER कथन (3setup_slave.sql) का उपयोग करके प्रतिकृति लिंक स्थापित करने के लिए।

टेक्स्ट फ़ाइल 1reset_master.sql बनाएं और निम्न पंक्ति जोड़ें:

RESET MASTER;

टेक्स्ट फ़ाइल 3setup_slave.sql बनाएं और निम्न पंक्तियां जोड़ें:

CHANGE MASTER TO MASTER_HOST = '192.168.55.171', MASTER_USER = 'rpl_user', MASTER_PASSWORD = 'YlgSH6bLLy', MASTER_AUTO_POSITION = 1, MASTER_DELAY=3600;
START SLAVE;

MASTER_DELAY=3600 1 घंटे (सेकंड में) के बराबर है। फिर हमारे मास्टर से ली गई बैकअप फ़ाइल (जिसे हमारे डॉकर होस्ट में स्थानांतरित कर दिया गया है) को "sql" निर्देशिका में कॉपी करें और इसका नाम बदलकर 2mysqldump_complete.sql.gz:

कर दें। 
$ cp ~/mysqldump_complete.tar.gz /storage/mysql-slave-1h/sql/2mysqldump_complete.tar.gz

हमारी "sql" निर्देशिका का अंतिम रूप कुछ इस तरह होना चाहिए:

$ pwd
/storage/mysql-slave-1h/sql
$ ls -1
1reset_master.sql
2mysqldump_complete.sql.gz
3setup_slave.sql

ध्यान दें कि जब डॉकर MySQL कंटेनर को इनिशियलाइज़ करता है तो निष्पादन क्रम निर्धारित करने के लिए हम SQL फ़ाइल नाम को एक पूर्णांक के साथ उपसर्ग करते हैं।

एक बार सब कुछ हो जाने के बाद, हमारे 1 घंटे के विलंबित दास के लिए MySQL कंटेनर चलाएँ:

$ docker run -d \
--name mysql-slave-1h \
-e MYSQL_ROOT_PASSWORD=password \
--mount type=bind,source=/storage/mysql-slave-1h/datadir,target=/var/lib/mysql \
--mount type=bind,source=/storage/mysql-slave-1h/mysql.conf.d,target=/etc/mysql/mysql.conf.d \
--mount type=bind,source=/storage/mysql-slave-1h/sql,target=/docker-entrypoint-initdb.d \
mysql:5.7

** MYSQL_ROOT_PASSWORD मान मास्टर पर MySQL रूट पासवर्ड के समान होना चाहिए।

निम्नलिखित पंक्तियाँ हैं जो हम यह सत्यापित करने के लिए देख रहे हैं कि क्या MySQL सही ढंग से चल रहा है और हमारे स्वामी के दास के रूप में जुड़ा हुआ है (192.168.55.171):

$ docker logs -f mysql-slave-1h
...
2018-12-04T04:05:24.890244Z 0 [Note] mysqld: ready for connections.
Version: '5.7.24-log'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  MySQL Community Server (GPL)
2018-12-04T04:05:25.010032Z 2 [Note] Slave I/O thread for channel '': connected to master '[email protected]:3306',replication started in log 'FIRST' at position 4

फिर आप निम्नलिखित कथन के साथ प्रतिकृति स्थिति सत्यापित कर सकते हैं:

$ docker exec -it mysql-slave-1h mysql -uroot -p -e 'show slave status\G'
...
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
                    SQL_Delay: 3600
                Auto_Position: 1
...

इस बिंदु पर, हमारे 15-मिनट और 1 घंटे के MySQL विलंबित स्लेव कंटेनर मास्टर से नकल कर रहे हैं और हमारी वास्तुकला कुछ इस तरह दिख रही है:

6 घंटे विलंबित दास

हमारे 6 घंटे के विलंबित दास के लिए MySQL कॉन्फ़िगरेशन फ़ाइल तैयार करें:

$ vim /storage/mysql-slave-15m/mysql.conf.d/my.cnf

और निम्नलिखित पंक्तियाँ जोड़ें:

[mysqld]
server_id=10006
binlog_format=ROW
log_bin=binlog
log_slave_updates=1
gtid_mode=ON
enforce_gtid_consistency=1
relay_log=relay-bin
expire_logs_days=7
read_only=ON

** इस दास के लिए हमने जिस सर्वर-आईडी का उपयोग किया है वह 10006 है।

अगला, /storage/mysql-slave-6h/sql निर्देशिका के अंतर्गत, दो SQL फ़ाइलें बनाएं, एक RESET MASTER (1reset_master.sql) के लिए और दूसरी CHANGE MASTER कथन (3setup_slave.sql) का उपयोग करके प्रतिकृति लिंक स्थापित करने के लिए।

टेक्स्ट फ़ाइल 1reset_master.sql बनाएं और निम्न पंक्ति जोड़ें:

RESET MASTER;

टेक्स्ट फ़ाइल 3setup_slave.sql बनाएं और निम्न पंक्तियां जोड़ें:

CHANGE MASTER TO MASTER_HOST = '192.168.55.171', MASTER_USER = 'rpl_user', MASTER_PASSWORD = 'YlgSH6bLLy', MASTER_AUTO_POSITION = 1, MASTER_DELAY=21600;
START SLAVE;

MASTER_DELAY=21600 6 घंटे (सेकंड में) के बराबर है। फिर हमारे मास्टर से ली गई बैकअप फ़ाइल (जिसे हमारे डॉकर होस्ट में स्थानांतरित कर दिया गया है) को "sql" निर्देशिका में कॉपी करें और इसका नाम बदलकर 2mysqldump_complete.sql.gz:

कर दें। 
$ cp ~/mysqldump_complete.tar.gz /storage/mysql-slave-6h/sql/2mysqldump_complete.tar.gz

हमारी "sql" निर्देशिका का अंतिम रूप कुछ इस तरह होना चाहिए:

$ pwd
/storage/mysql-slave-6h/sql
$ ls -1
1reset_master.sql
2mysqldump_complete.sql.gz
3setup_slave.sql

ध्यान दें कि जब डॉकर MySQL कंटेनर को इनिशियलाइज़ करता है तो निष्पादन क्रम निर्धारित करने के लिए हम SQL फ़ाइल नाम को एक पूर्णांक के साथ उपसर्ग करते हैं।

एक बार सब कुछ हो जाने के बाद, हमारे 6 घंटे के विलंबित दास के लिए MySQL कंटेनर चलाएँ:

$ docker run -d \
--name mysql-slave-6h \
-e MYSQL_ROOT_PASSWORD=password \
--mount type=bind,source=/storage/mysql-slave-6h/datadir,target=/var/lib/mysql \
--mount type=bind,source=/storage/mysql-slave-6h/mysql.conf.d,target=/etc/mysql/mysql.conf.d \
--mount type=bind,source=/storage/mysql-slave-6h/sql,target=/docker-entrypoint-initdb.d \
mysql:5.7

** MYSQL_ROOT_PASSWORD मान मास्टर पर MySQL रूट पासवर्ड के समान होना चाहिए।

निम्नलिखित पंक्तियाँ हैं जो हम यह सत्यापित करने के लिए देख रहे हैं कि क्या MySQL सही ढंग से चल रहा है और हमारे स्वामी के दास के रूप में जुड़ा हुआ है (192.168.55.171):

$ docker logs -f mysql-slave-6h
...
2018-12-04T04:05:24.890244Z 0 [Note] mysqld: ready for connections.
Version: '5.7.24-log'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  MySQL Community Server (GPL)
2018-12-04T04:05:25.010032Z 2 [Note] Slave I/O thread for channel '': connected to master '[email protected]:3306',replication started in log 'FIRST' at position 4

फिर आप निम्नलिखित कथन के साथ प्रतिकृति स्थिति सत्यापित कर सकते हैं:

$ docker exec -it mysql-slave-6h mysql -uroot -p -e 'show slave status\G'
...
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
                    SQL_Delay: 21600
                Auto_Position: 1
...

इस समय, हमारे 5 मिनट, 1 घंटे और 6 घंटे विलंबित स्लेव कंटेनर सही ढंग से नकल कर रहे हैं और हमारी वास्तुकला कुछ इस तरह दिख रही है:

आपदा पुनर्प्राप्ति परिदृश्य

मान लीजिए कि किसी उपयोगकर्ता ने गलती से एक बड़ी टेबल पर गलत कॉलम गिरा दिया है। निम्नलिखित कथन पर विचार करें जो मास्टर पर निष्पादित किया गया था:

mysql> USE shop;
mysql> ALTER TABLE settings DROP COLUMN status;

यदि आप भाग्यशाली हैं कि इसे तुरंत महसूस किया जा सकता है, तो आप आपदा होने से पहले के पल को पकड़ने के लिए 15 मिनट की देरी वाले दास का उपयोग कर सकते हैं और इसे मास्टर बनने के लिए बढ़ावा दे सकते हैं, या लापता डेटा को निर्यात कर सकते हैं और इसे मास्टर पर पुनर्स्थापित कर सकते हैं।

सबसे पहले, हमें आपदा होने से पहले बाइनरी लॉग स्थिति का पता लगाना होगा। मास्टर पर अभी () समय लें:

mysql> SELECT now();
+---------------------+
| now()               |
+---------------------+
| 2018-12-04 14:55:41 |
+---------------------+

फिर, मास्टर पर सक्रिय बाइनरी लॉग फ़ाइल प्राप्त करें:

mysql> SHOW MASTER STATUS;
+---------------+----------+--------------+------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| File          | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set                                                                                                                                                                     |
+---------------+----------+--------------+------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| binlog.000004 | 20260658 |              |                  | 1560665e-ed2b-11e8-93fa-000c29b7f985:1-12031,
1b235f7a-d37b-11e8-9c3e-000c29bafe8f:1-62519,
1d8dc60a-e817-11e8-82ff-000c29bafe8f:1-326575,
791748b3-d37a-11e8-b03a-000c29b7f985:1-374 |
+---------------+----------+--------------+------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+

उसी दिनांक प्रारूप का उपयोग करते हुए, बाइनरी लॉग, binlog.000004 से वह जानकारी निकालें जो हम चाहते हैं। हम लगभग 20 मिनट पहले (2018-12-04 14:35:00) बिनलॉग से पढ़ने के लिए प्रारंभ समय का अनुमान लगाते हैं और "ड्रॉप कॉलम" स्टेटमेंट से पहले 25 लाइनें दिखाने के लिए आउटपुट को फ़िल्टर करते हैं:

$ mysqlbinlog --start-datetime="2018-12-04 14:35:00" --stop-datetime="2018-12-04 14:55:41" /var/lib/mysql/binlog.000004 | grep -i -B 25 "drop column"
'/*!*/;
# at 19379172
#181204 14:54:45 server id 1  end_log_pos 19379232 CRC32 0x0716e7a2     Table_map: `shop`.`settings` mapped to number 766
# at 19379232
#181204 14:54:45 server id 1  end_log_pos 19379460 CRC32 0xa6187edd     Write_rows: table id 766 flags: STMT_END_F

BINLOG '
tSQGXBMBAAAAPAAAACC0JwEAAP4CAAAAAAEABnNidGVzdAAHc2J0ZXN0MgAFAwP+/gME/nj+PBCi
5xYH
tSQGXB4BAAAA5AAAAAS1JwEAAP4CAAAAAAEAAgAF/+AYwwAAysYAAHc0ODYyMjI0NjI5OC0zNDE2
OTY3MjY5OS02MDQ1NTQwOTY1Ny01MjY2MDQ0MDcwOC05NDA0NzQzOTUwMS00OTA2MTAxNzgwNC05
OTIyMzM3NzEwOS05NzIwMzc5NTA4OC0yODAzOTU2NjQ2MC0zNzY0ODg3MTYzOTswMTM0MjAwNTcw
Ni02Mjk1ODMzMzExNi00NzQ1MjMxODA1OS0zODk4MDQwMjk5MS03OTc4MTA3OTkwNQEAAADdfhim
'/*!*/;
# at 19379460
#181204 14:54:45 server id 1  end_log_pos 19379491 CRC32 0x71f00e63     Xid = 622405
COMMIT/*!*/;
# at 19379491
#181204 14:54:46 server id 1  end_log_pos 19379556 CRC32 0x62b78c9e     GTID    last_committed=11507    sequence_number=11508   rbr_only=no
SET @@SESSION.GTID_NEXT= '1560665e-ed2b-11e8-93fa-000c29b7f985:11508'/*!*/;
# at 19379556
#181204 14:54:46 server id 1  end_log_pos 19379672 CRC32 0xc222542a     Query   thread_id=3162  exec_time=1     error_code=0
SET TIMESTAMP=1543906486/*!*/;
/*!\C utf8 *//*!*/;
SET @@session.character_set_client=33,@@session.collation_connection=33,@@session.collation_server=8/*!*/;
ALTER TABLE settings DROP COLUMN status

Mysqlbinlog आउटपुट की निचली कुछ पंक्तियों में, आपके पास गलत कमांड होनी चाहिए जिसे 19379556 की स्थिति में निष्पादित किया गया था। जिस स्थिति को हमें पुनर्स्थापित करना चाहिए वह इससे एक कदम पहले है, जो 19379491 की स्थिति में है। यह बिनलॉग स्थिति है जहां हम अपनी चाहते हैं विलंबित दास तक पहुंचने के लिए।

फिर, चुने हुए विलंबित दास पर, विलंबित प्रतिकृति दास को रोकें और दास को एक निश्चित अंत स्थिति में फिर से शुरू करें जिसे हमने ऊपर सोचा था:

$ docker exec -it mysql-slave-15m mysql -uroot -p
mysql> STOP SLAVE;
mysql> START SLAVE UNTIL MASTER_LOG_FILE = 'binlog.000004', MASTER_LOG_POS = 19379491;

प्रतिकृति स्थिति की निगरानी करें और तब तक प्रतीक्षा करें जब तक Exec_Master_Log_Pos जब तक_Log_Pos मान के बराबर न हो जाए। इसमें कुछ समय लग सकता है। एक बार पकड़े जाने पर, आपको निम्नलिखित देखना चाहिए:

$ docker exec -it mysql-slave-15m mysql -uroot -p -e 'SHOW SLAVE STATUS\G'
... 
          Exec_Master_Log_Pos: 19379491
              Relay_Log_Space: 50552186
              Until_Condition: Master
               Until_Log_File: binlog.000004
                Until_Log_Pos: 19379491
...

अंत में सत्यापित करें कि क्या लापता डेटा जो हम खोज रहे थे वह वहां है (कॉलम "स्थिति" अभी भी मौजूद है):

mysql> DESCRIBE shop.settings;
+--------+------------------+------+-----+---------+----------------+
| Field  | Type             | Null | Key | Default | Extra          |
+--------+------------------+------+-----+---------+----------------+
| id     | int(10) unsigned | NO   | PRI | NULL    | auto_increment |
| sid    | int(10) unsigned | NO   | MUL | 0       |                |
| param  | varchar(100)     | NO   |     |         |                |
| value  | varchar(255)     | NO   |     |         |                |
| status | int(11)          | YES  |     | 1       |                |
+--------+------------------+------+-----+---------+----------------+

फिर हमारे दास कंटेनर से तालिका निर्यात करें और इसे मास्टर सर्वर पर स्थानांतरित करें:

$ docker exec -it mysql-slave-1h mysqldump -uroot -ppassword --single-transaction shop settings > shop_settings.sql

समस्याग्रस्त तालिका को छोड़ दें और उसे वापस मास्टर पर पुनर्स्थापित करें:

$ mysql -uroot -p -e 'DROP TABLE shop.settings'
$ mysqldump -uroot -p -e shop < shop_setttings.sql

हमने अब विनाशकारी घटना से पहले अपनी मेज को उसकी मूल स्थिति में वापस पा लिया है। संक्षेप में, विलंबित प्रतिकृति का उपयोग कई उद्देश्यों के लिए किया जा सकता है:

  • मास्टर पर उपयोगकर्ता की गलतियों से बचाने के लिए। एक डीबीए एक विलंबित दास को आपदा से ठीक पहले के समय में वापस ले सकता है।
  • यह परीक्षण करने के लिए कि अंतराल होने पर सिस्टम कैसे व्यवहार करता है। उदाहरण के लिए, किसी एप्लिकेशन में, दास पर भारी भार के कारण अंतराल हो सकता है। हालांकि, इस लोड स्तर को उत्पन्न करना मुश्किल हो सकता है। विलंबित प्रतिकृति लोड को अनुकरण किए बिना अंतराल का अनुकरण कर सकती है। इसका उपयोग लैगिंग स्लेव से संबंधित स्थितियों को डीबग करने के लिए भी किया जा सकता है।
  • बैकअप को फिर से लोड किए बिना, यह निरीक्षण करने के लिए कि डेटाबेस अतीत में कैसा दिखता था। उदाहरण के लिए, यदि विलंब एक सप्ताह है और DBA को यह देखने की आवश्यकता है कि पिछले कुछ दिनों के विकास से पहले डेटाबेस कैसा दिखता है, तो विलंबित दास का निरीक्षण किया जा सकता है।

अंतिम विचार

डॉकर के साथ, एक ही भौतिक होस्ट पर कई 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. कैसे MONTH () मारियाडीबी में काम करता है

  2. मारियाडीबी में CHAR () कैसे काम करता है

  3. कैसे HEX () मारियाडीबी में काम करता है

  4. सेंटोस 7 / आरएचईएल 7 . पर मारियाडीबी कैसे स्थापित करें

  5. पंक्तियों को वापस करने के 2 तरीके जिनमें केवल मारियाडीबी में गैर-अल्फ़ान्यूमेरिक वर्ण होते हैं