MySQLdump और MySQL शेल उपयोगिता का उपयोग करके प्रदर्शन परीक्षण

अपनी पिछली पोस्ट में मैंने समझाया था कि mysql शेल यूटिलिटीज का उपयोग करके लॉजिकल बैकअप कैसे लिया जाता है। इस पोस्ट में, हम बैकअप और बहाली प्रक्रिया की गति की तुलना करेंगे।

MySQL शेल स्पीड टेस्ट 

हम mysqldump और MySQL शेल यूटिलिटी टूल्स के बैकअप और रिकवरी स्पीड की तुलना करने जा रहे हैं।

गति तुलना के लिए नीचे दिए गए टूल का उपयोग किया जाता है:

• mysqldump
• util.dumpInstance
• util.loadDump

हार्डवेयर कॉन्फ़िगरेशन

समान कॉन्फ़िगरेशन वाले दो स्टैंडअलोन सर्वर।

सर्वर 1

   * आईपी:192.168.33.14

   * CPU:2 करोड़

   * RAM:4 GB

   * डिस्क:200 जीबी एसएसडी

सर्वर 2

   * आईपी:192.168.33.15

   * CPU:2 करोड़

   * RAM:4 GB

   * डिस्क:200 जीबी एसएसडी

कार्यभार की तैयारी

सर्वर 1 (192.168.33.14) पर, हमने लगभग 10 जीबी डेटा लोड किया है।

अब, हम सर्वर 1 (192.168.33.14) से सर्वर 2 (192.168.33.15) पर डेटा को पुनर्स्थापित करना चाहते हैं।

MySQL सेटअप

MySQL संस्करण:8.0.22

InnoDB बफर पूल का आकार:1 जीबी

InnoDB लॉग फ़ाइल का आकार:16 एमबी

बाइनरी लॉगिंग:चालू

हमने sysbench का उपयोग करके 50M रिकॉर्ड लोड किए।

[[email protected] sysbench]# sysbench oltp_insert.lua --table-size=5000000 --num-threads=8 --rand-type=uniform --db-driver=mysql --mysql-db=sbtest --tables=10 --mysql-user=root --mysql-password=****** prepare

WARNING: --num-threads is deprecated, use --threads instead

sysbench 1.0.20 (using bundled LuaJIT 2.1.0-beta2)

Initializing worker threads...

​Creating table 'sbtest3'...

Creating table 'sbtest4'...

Creating table 'sbtest7'...

Creating table 'sbtest1'...

Creating table 'sbtest2'...

Creating table 'sbtest8'...

Creating table 'sbtest5'...

Creating table 'sbtest6'...

Inserting 5000000 records into 'sbtest1'

Inserting 5000000 records into 'sbtest3'

Inserting 5000000 records into 'sbtest7

.

.

.

Creating a secondary index on 'sbtest9'...

Creating a secondary index on 'sbtest10'...

टेस्ट केस वन

इस मामले में हम mysqldump कमांड का उपयोग करके एक तार्किक बैकअप लेने जा रहे हैं।

उदाहरण 

[[email protected] vagrant]# time /usr/bin/mysqldump --defaults-file=/etc/my.cnf  --flush-privileges --hex-blob --opt --master-data=2 --single-transaction --triggers --routines --events  --set-gtid-purged=OFF  --all-databases  |gzip -6 -c > /home/vagrant/test/mysqldump_schemaanddata.sql.gz

start_time =2020-11-09 17:40:02

end_time   =2020-11-09 37:19:08

लगभग 10GB के कुल आकार वाले सभी डेटाबेस को डंप करने में लगभग 20 मिनट 19 सेकंड का समय लगा।

टेस्ट केस टू

अब MySQL शेल उपयोगिता के साथ प्रयास करते हैं। हम पूरा बैकअप लेने के लिए डंपइंस्टेंस का उपयोग करने जा रहे हैं।

उदाहरण 

MySQL  localhost:33060+ ssl  JS > util.dumpInstance("/home/vagrant/production_backup", {threads: 2, ocimds: true,compatibility: ["strip_restricted_grants"]})

Acquiring global read lock

Global read lock acquired

All transactions have been started

Locking instance for backup

Global read lock has been released

Checking for compatibility with MySQL Database Service 8.0.22

NOTE: Progress information uses estimated values and may not be accurate.

Data dump for table `sbtest`.`sbtest1` will be written to 38 files

Data dump for table `sbtest`.`sbtest10` will be written to 38 files

Data dump for table `sbtest`.`sbtest3` will be written to 38 files

Data dump for table `sbtest`.`sbtest2` will be written to 38 files

Data dump for table `sbtest`.`sbtest4` will be written to 38 files

Data dump for table `sbtest`.`sbtest5` will be written to 38 files

Data dump for table `sbtest`.`sbtest6` will be written to 38 files

Data dump for table `sbtest`.`sbtest7` will be written to 38 files

Data dump for table `sbtest`.`sbtest8` will be written to 38 files

Data dump for table `sbtest`.`sbtest9` will be written to 38 files

2 thds dumping - 36% (17.74M rows / ~48.14M rows), 570.93K rows/s, 111.78 MB/s uncompressed, 50.32 MB/s compressed

1 thds dumping - 100% (50.00M rows / ~48.14M rows), 587.61K rows/s, 115.04 MB/s uncompressed, 51.79 MB/s compressed

Duration: 00:01:27s                                                                                                

Schemas dumped: 3                                                                                                  

Tables dumped: 10                                                                                                  

Uncompressed data size: 9.78 GB                                                                                    

Compressed data size: 4.41 GB                                                                                      

Compression ratio: 2.2                                                                                             

Rows written: 50000000                                                                                             

Bytes written: 4.41 GB                                                                                             

Average uncompressed throughput: 111.86 MB/s                                                                       

Average compressed throughput: 50.44 MB/s    

संपूर्ण डेटाबेस (mysqldump के लिए उपयोग किए गए समान डेटा) को डंप करने में कुल 1 मिनट 27 सेकंड का समय लगा और साथ ही यह इसकी प्रगति को भी दिखाता है जो यह जानने में मददगार होगा कि बैकअप का कितना हिस्सा पूरा हो गया है। यह बैकअप करने में लगने वाला समय देता है।

समानांतरता सर्वर में कोर की संख्या पर निर्भर करती है। मोटे तौर पर मूल्य बढ़ाना मेरे मामले में मददगार नहीं होगा। (मेरी मशीन में 2 कोर हैं)।

पुनर्स्थापन गति परीक्षण 

पुनर्स्थापन भाग में, हम एक अन्य स्टैंडअलोन सर्वर पर mysqldump बैकअप को पुनर्स्थापित करने जा रहे हैं। बैकअप फ़ाइल पहले ही rsync का उपयोग करके गंतव्य सर्वर पर ले जाया गया था।

टेस्ट केस 1 

उदाहरण 

[[email protected] vagrant]#time gunzip < /mnt/mysqldump_schemaanddata.sql.gz | mysql -u root -p

10GB डेटा को पुनर्स्थापित करने में लगभग 16 मिनट 26 सेकंड का समय लगा।

टेस्ट केस 2 

इस मामले में हम बैकअप फ़ाइल को किसी अन्य स्टैंडअलोन होस्ट पर लोड करने के लिए mysql शेल उपयोगिता का उपयोग कर रहे हैं। हम पहले ही बैकअप फ़ाइल को गंतव्य सर्वर पर स्थानांतरित कर चुके हैं। आइए बहाली प्रक्रिया शुरू करें।

उदाहरण 

​ MySQL  localhost:33060+ ssl  JS > util.loadDump("/home/vagrant/production_backup", {progressFile :"/home/vagrant/production_backup/log.json",threads :2})

Opening dump...

Target is MySQL 8.0.22. Dump was produced from MySQL 8.0.22

Checking for pre-existing objects...

Executing common preamble SQL

Executing DDL script for schema `cluster_control`

Executing DDL script for schema `proxydemo`

Executing DDL script for schema `sbtest`

.

.

.

2 thds loading \ 1% (150.66 MB / 9.78 GB), 6.74 MB/s, 4 / 10 tables done

2 thds loading / 100% (9.79 GB / 9.79 GB), 1.29 MB/s, 10 / 10 tables done

[Worker001] [email protected]@@37.tsv.zst: Records: 131614  Deleted: 0  Skipped: 0  Warnings: 0

[Worker002] [email protected]@@37.tsv.zst: Records: 131614  Deleted: 0  Skipped: 0  Warnings: 0

Executing common postamble SQL                                                        

380 chunks (50.00M rows, 9.79 GB) for 10 tables in 2 schemas were loaded in 40 min 6 sec (avg throughput 4.06 MB/s)

10GB डेटा को पुनर्स्थापित करने में लगभग 40 मिनट 6 सेकंड का समय लगा।

अब चलिए फिर से लॉग को अक्षम करने का प्रयास करते हैं और mysql का उपयोग करके डेटा आयात करना प्रारंभ करते हैं शेल उपयोगिता।

​mysql> alter instance disable innodb redo_log;

Query OK, 0 rows affected (0.00 sec)



 MySQL  localhost:33060+ ssl  JS >util.loadDump("/home/vagrant/production_backup", {progressFile :"/home/vagrant/production_backup/log.json",threads :2})

Opening dump...

Target is MySQL 8.0.22. Dump was produced from MySQL 8.0.22

Checking for pre-existing objects...

Executing common preamble SQL

.

.

.

380 chunks (50.00M rows, 9.79 GB) for 10 tables in 3 schemas were loaded in 19 min 56 sec (avg throughput 8.19 MB/s)

0 warnings were reported during the load.

फिर से लॉग को अक्षम करने के बाद, औसत प्रवाह क्षमता 2x तक बढ़ गई थी।

नोट:किसी प्रोडक्शन सिस्टम पर फिर से लॉगिंग को अक्षम न करें। यह फिर से लॉगिंग अक्षम होने पर सर्वर को शटडाउन और पुनरारंभ करने की अनुमति देता है, लेकिन फिर से लॉगिंग अक्षम होने पर एक अप्रत्याशित सर्वर स्टॉपेज डेटा हानि और उदाहरण भ्रष्टाचार का कारण बन सकता है।

भौतिक बैकअप 

जैसा कि आपने देखा होगा, तार्किक बैकअप विधियां, भले ही मल्टीथ्रेडेड हों, एक छोटे से डेटा सेट के लिए भी काफी समय लेने वाली होती हैं, जिसके खिलाफ हमने उनका परीक्षण किया था। यह एक कारण है कि ClusterControl भौतिक बैकअप विधि प्रदान करता है जो फ़ाइलों की प्रतिलिपि पर आधारित है - ऐसे मामले में हम SQL परत द्वारा सीमित नहीं हैं जो तार्किक बैकअप को संसाधित करता है बल्कि हार्डवेयर द्वारा - डिस्क कितनी तेजी से फ़ाइलों को पढ़ सकता है और नेटवर्क कितनी तेजी से डेटाबेस नोड और बैकअप सर्वर के बीच डेटा ट्रांसफर कर सकता है।

ClusterControl भौतिक बैकअप को लागू करने के विभिन्न तरीकों के साथ आता है, कौन सी विधि उपलब्ध है यह क्लस्टर प्रकार और कभी-कभी विक्रेता पर भी निर्भर करेगा। आइए ClusterControl द्वारा निष्पादित Xtrabackup पर एक नज़र डालें जो हमारे परीक्षण वातावरण पर डेटा का पूर्ण बैकअप बनाएगा।

हम इस बार एक एड-हॉक बैकअप बनाने जा रहे हैं लेकिन ClusterControl देता है आप एक पूर्ण बैकअप शेड्यूल भी बनाते हैं।

यहां हम बैकअप विधि (xtrabackup) के साथ-साथ होस्ट भी चुनते हैं। से बैकअप लेने जा रहे हैं। हम इसे स्थानीय रूप से नोड पर भी स्टोर कर सकते हैं या इसे ClusterControl इंस्टेंस पर स्ट्रीम किया जा सकता है। इसके अतिरिक्त, आप बैकअप को क्लाउड पर अपलोड कर सकते हैं (AWS, Google Cloud और Azure समर्थित हैं)।

बैकअप को पूरा होने में लगभग 10 मिनट का समय लगा। यहाँ cmon_backup.metadata फ़ाइल के लॉग हैं।

​[[email protected] BACKUP-9]# cat cmon_backup.metadata 

{

    "class_name": "CmonBackupRecord",

    "backup_host": "192.168.33.14",

    "backup_tool_version": "2.4.21",

    "compressed": true,

    "created": "2020-11-17T23:37:15.000Z",

    "created_by": "",

    "db_vendor": "oracle",

    "description": "",

    "encrypted": false,

    "encryption_md5": "",

    "finished": "2020-11-17T23:47:47.681Z"

 }

अब चलिए ClusterControl का उपयोग करके इसे पुनर्स्थापित करने का प्रयास करते हैं। ClusterControl> बैकअप> बैकअप पुनर्स्थापित करें 

यहां हम रिस्टोर बैकअप विकल्प चुनते हैं, यह समय और लॉग आधारित का समर्थन करेगा वसूली भी।

यहां हम बैकअप फ़ाइल स्रोत पथ और फिर गंतव्य सर्वर चुनते हैं। आपको यह भी सुनिश्चित करना होगा कि इस होस्ट तक SSH का उपयोग करके ClusterControl नोड से पहुंचा जा सकता है।

हम नहीं चाहते कि ClusterControl सॉफ़्टवेयर सेट करे, इसलिए हमने उस विकल्प को अक्षम कर दिया। बहाली के बाद यह सर्वर को चालू रखेगा।

10GB डेटा को पुनर्स्थापित करने में लगभग 4 मिनट 18 सेकंड का समय लगा। बैकअप प्रक्रिया के दौरान Xtrabackup आपके डेटाबेस को लॉक नहीं करता है। बड़े डेटाबेस (100+ GB) के लिए, यह mysqldump/shell उपयोगिता की तुलना में बहुत बेहतर पुनर्स्थापना समय प्रदान करता है। साथ ही, लस्टरकंट्रोल आंशिक बैकअप और बहाली का समर्थन करता है, जैसा कि मेरे एक सहयोगी ने अपने ब्लॉग में बताया है:आंशिक बैकअप और पुनर्स्थापना।

निष्कर्ष

प्रत्येक विधि के अपने फायदे और नुकसान हैं। जैसा कि हम देख चुके हैं, कोई एक तरीका नहीं है जो हर उस चीज़ के लिए सबसे अच्छा काम करता है जो आपको करने की ज़रूरत है। हमें अपने उत्पादन परिवेश और पुनर्प्राप्ति के लिए लक्षित समय के आधार पर अपना उपकरण चुनने की आवश्यकता है।