उत्पादन के लिए एक MySQL या MariaDB सर्वर तैयार करना - भाग दो

पिछले ब्लॉग में, हमने सिस्टम व्यवस्थापक के दृष्टिकोण से MySQL सर्वर को उत्पादन उपयोग के लिए तैयार करने के लिए कुछ युक्तियों और युक्तियों को शामिल किया है। यह ब्लॉग पोस्ट निरंतरता है...

डेटाबेस बैकअप टूल का उपयोग करें

हर बैकअप टूल के अपने फायदे और नुकसान होते हैं। उदाहरण के लिए, Percona Xtrabackup (या MariaDB के लिए MariaDB बैकअप) डेटाबेस को लॉक किए बिना एक भौतिक हॉट-बैकअप कर सकता है, लेकिन इसे किसी अन्य उदाहरण पर केवल उसी संस्करण में पुनर्स्थापित किया जा सकता है। जबकि mysqldump के लिए, यह अन्य MySQL प्रमुख संस्करणों के साथ संगत है और आंशिक बैकअप के लिए सरल तरीका है, हालांकि बड़े डेटाबेस पर Percona Xtrabackup की तुलना में यह बहाली के दौरान अपेक्षाकृत धीमा है। MySQL 5.7 ने mysqlpump को भी पेश किया है, जो mysqldump के समान है और डंप प्रक्रिया को गति देने के लिए समानांतर प्रसंस्करण क्षमताओं के साथ है।

इन सभी बैकअप टूल को अपने MySQL सर्वर में कॉन्फ़िगर करना न भूलें क्योंकि ये डेटा रिकवरी के लिए स्वतंत्र रूप से उपलब्ध हैं और बहुत महत्वपूर्ण हैं। चूंकि mysqldump और mysqlpump पहले से ही MySQL 5.7 में शामिल हैं और बाद में, हमें केवल Percona Xtrabackup (या MariaDB के लिए MariaDB बैकअप) स्थापित करने की आवश्यकता है, लेकिन इसके लिए कुछ तैयारी की आवश्यकता है, जैसा कि निम्नलिखित चरणों में दिखाया गया है:

एक कदम

सुनिश्चित करें कि बैकअप टूल और उसकी निर्भरताएं स्थापित हैं:

$ yum install -y epel-release
$ yum install -y socat pv percona-xtrabackup

MariaDB सर्वर के लिए, इसके बजाय MariaDB बैकअप का उपयोग करें:

$ yum install -y socat pv MariaDB-Backup

दूसरा चरण

यदि यह मौजूद नहीं है तो मास्टर पर उपयोगकर्ता 'xtrabackup' बनाएं:

mysql> CREATE USER 'xtrabackup'@'localhost' IDENTIFIED BY 'Km4z9^sT2X';
mysql> GRANT RELOAD, LOCK TABLES, PROCESS, REPLICATION CLIENT ON *.* TO 'xtrabackup'@'localhost';

तीसरा चरण

मास्टर पर 'mysqldump' नाम का दूसरा उपयोगकर्ता बनाएं, अगर वह मौजूद नहीं है। इस उपयोगकर्ता का उपयोग 'mysqldump' और 'mysqlpump' के लिए किया जाएगा:

mysql> CREATE USER 'mysqldump'@'localhost' IDENTIFIED BY 'Km4z9^sT2X';
mysql> GRANT SELECT, SHOW VIEW, EVENT, TRIGGER, LOCK TABLES, RELOAD, REPLICATION CLIENT ON *.* TO 'mysqldump'@'localhost';

चरण चार

MySQL कॉन्फ़िगरेशन फ़ाइल के अंदर [xtrabackup], [mysqldump] और [mysqlpump] निर्देश के तहत बैकअप उपयोगकर्ताओं के क्रेडेंशियल जोड़ें:

$ cat /etc/my.cnf

...

[xtrabackup]
user=xtrabackup
password='Km4z9^sT2X'

[mysqldump]
user=mysqldump
password='Km4z9^sT2X'

[mysqlpump]
user=mysqldump
password='Km4z9^sT2X'

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

सुनिश्चित करें कि बैकअप टूल का पहले से ठीक से परीक्षण किया गया है। Xtrabackup के लिए जो नेटवर्क के माध्यम से बैकअप स्ट्रीमिंग का समर्थन करता है, यह सुनिश्चित करने के लिए पहले इसका परीक्षण किया जाना चाहिए कि संचार लिंक स्रोत और गंतव्य सर्वर के बीच सही ढंग से स्थापित किया जा सकता है। गंतव्य सर्वर पर, पोर्ट 9999 को सुनने के लिए और आने वाली स्ट्रीमिंग को स्वीकार करने के लिए तैयार करने के लिए निम्नलिखित कमांड चलाएँ:

$ socat -u tcp-listen:9999,reuseaddr stdout 2>/tmp/netcat.log | xbstream -x -C /var/lib/mysql

फिर, स्रोत सर्वर पर एक बैकअप बनाएं और इसे गंतव्य सर्वर पर पोर्ट 9999 पर स्ट्रीम करें:

$ innobackupex --socket=/var/lib/mysql/mysql.sock --stream=xbstream /var/lib/mysql/ | socat - TCP4:192.168.0.202:9999

बैकअप कमांड निष्पादित करने के बाद आपको आउटपुट की एक सतत स्ट्रीम मिलनी चाहिए। एक सफल बैकअप का संकेत देने वाली 'पूर्ण ठीक' लाइन दिखाई देने तक प्रतीक्षा करें।

pv के साथ, हम बैंडविड्थ उपयोग को कम कर सकते हैं या प्रगति को इसके माध्यम से एक प्रक्रिया के रूप में देख सकते हैं। आम तौर पर, स्ट्रीमिंग प्रक्रिया नेटवर्क को संतृप्त कर देगी यदि कोई थ्रॉटलिंग सक्षम नहीं है और इससे अन्य सर्वरों के साथ उसी सेगमेंट में दूसरे के साथ बातचीत करने में समस्या हो सकती है। pv का उपयोग करके, हम स्ट्रीमिंग प्रक्रिया को socat या netcat जैसे स्ट्रीमिंग टूल में पास करने से पहले उसे थ्रॉटल कर सकते हैं। निम्न उदाहरण दिखाता है कि इनकमिंग और आउटगोइंग दोनों कनेक्शनों के लिए बैकअप स्ट्रीमिंग लगभग 80 एमबी/सेकेंड की होगी:

$ innobackupex --slave-info --socket=/var/lib/mysql/mysql.sock --stream=xbstream /var/lib/mysql/ | pv -q -L 80m | socat - TCP4:192.168.0.202:9999

बैकअप को स्ट्रीम करना आमतौर पर किसी दास को चरणबद्ध करने या बैकअप को किसी अन्य सर्वर पर दूरस्थ रूप से संग्रहीत करने के लिए उपयोग किया जाता है।

mysqldump और mysqlpump के लिए, हम निम्नलिखित कमांड के साथ परीक्षण कर सकते हैं:

$ mysqldump --set-gtid-purged=OFF --all-databases
$ mysqlpump --set-gtid-purged=OFF --all-databases

सुनिश्चित करें कि आप आउटपुट में गैर-त्रुटि रेखाएं दिखाई देते हैं।

सर्वर का तनाव परीक्षण करें

डेटाबेस सर्वर का तनाव परीक्षण उस अधिकतम क्षमता को समझने के लिए महत्वपूर्ण है जिसका हम विशेष सर्वर के लिए अनुमान लगा सकते हैं। यह तब उपयोगी होगा जब आप बाद के चरण में दहलीज या बाधाओं के करीब पहुंच रहे हों। आप बाजार में उपलब्ध कई बेंचमार्किंग टूल जैसे mysqlslap, DBT2 और sysbench का उपयोग कर सकते हैं।

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

sysbench को स्थापित और कॉन्फ़िगर करने के लिए, आप इसे स्रोत से संकलित कर सकते हैं या Percona रिपॉजिटरी से पैकेज स्थापित कर सकते हैं:

$ yum install -y https://repo.percona.com/yum/percona-release-latest.noarch.rpm
$ yum install -y sysbench

MySQL सर्वर पर डेटाबेस स्कीमा और उपयोगकर्ता बनाएं:

mysql> CREATE DATABASE sbtest;
mysql> CREATE USER 'sbtest'@'localhost' IDENTIFIED BY 'sysbenchP4ss';
mysql> GRANT ALL PRIVILEGES ON sbtest.* TO [email protected]'localhost';

परीक्षण डेटा जेनरेट करें:

$ sysbench \
/usr/share/sysbench/oltp_common.lua \
--db-driver=mysql \
--mysql-host=localhost \
--mysql-user=sbtest \
--mysql-password=sysbenchP4ss \
--tables=50 \
--table-size=100000 \
prepare

फिर बेंचमार्क को 1 घंटे (3600 सेकंड) तक चलाएं:

$ sysbench \
/usr/share/sysbench/oltp_read_write.lua \
--report-interval=2 \
--threads=64 \
--max-requests=0 \
--db-driver=mysql \
--time=3600 \
--db-ps-mode=disable \
--mysql-host=localhost \
--mysql-user=sbtest \
--mysql-password=sysbenchP4ss \
--tables=50 \
--table-size=100000 \
run

जब परीक्षण चल रहा हो, डिस्क उपयोग, बैंडविड्थ, IOPS और I/O प्रतीक्षा की निगरानी के लिए दूसरे टर्मिनल में iostat (sysstat पैकेज में उपलब्ध) का उपयोग करें:

$ yum install -y sysstat
$ iostat -x 60

avg-cpu:  %user %nice %system %iowait  %steal %idle
          40.55    0.00 55.27    4.18 0.00 0.00

Device:         rrqm/s wrqm/s     r/s w/s rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await svctm  %util
sda               0.19 6.18 1236.23  816.92 61283.83 14112.44    73.44 4.00 1.96 2.83    0.65 0.34 69.29

उपरोक्त परिणाम हर 60 सेकंड में प्रिंट किया जाएगा। परीक्षण समाप्त होने तक प्रतीक्षा करें और r/s (पढ़ें/सेकंड), w/s (लिखता/सेकंड),% iowait,% उपयोग, rkB/s और wkB/s (बैंडविड्थ) का औसत लें। यदि आप डिस्क, सीपीयू, रैम या नेटवर्क का अपेक्षाकृत कम उपयोग देख रहे हैं, तो संभवतः आपको "--थ्रेड्स" मान को और भी अधिक संख्या तक बढ़ाने की आवश्यकता है ताकि यह सभी संसाधनों का सीमा तक उपयोग कर सके।

मापने के लिए निम्न पहलुओं पर विचार करें:

• क्वेरी प्रति सेकंड =Sysbench सारांश एक बार परीक्षण SQL आँकड़ों के तहत पूरा होने के बाद -> क्वेरीज़ -> प्रति सेकंड।
• क्वेरी लेटेंसी =Sysbench सारांश एक बार टेस्ट लेटेंसी (ms) -> 95वें पर्सेंटाइल के तहत पूरा हो जाता है।
• डिस्क IOPS =r/s + w/s का औसत
• डिस्क का उपयोग =%उपयोग का औसत
• डिस्क बैंडविड्थ R/W =rkB/s का औसत / wkB/s का औसत
• डिस्क IO प्रतीक्षा =%iowait का औसत
• औसत सर्वर लोड =औसत लोड औसत जैसा कि शीर्ष कमांड द्वारा रिपोर्ट किया गया है।
• MySQL CPU उपयोग =औसत CPU उपयोग जैसा कि शीर्ष कमांड द्वारा रिपोर्ट किया गया है।

ClusterControl के साथ, आप Nodes Overview पैनल के माध्यम से उपरोक्त जानकारी को आसानी से देख सकते हैं और प्राप्त कर सकते हैं, जैसा कि निम्नलिखित स्क्रीनशॉट में दिखाया गया है:

इसके अलावा, तनाव परीक्षण के दौरान एकत्र की गई जानकारी का उपयोग MySQL को ट्यून करने के लिए किया जा सकता है। और तदनुसार InnoDB चर जैसे innodb_buffer_pool_size, innodb_io_capacity, innodb_io_capacity_max, innodb_write_io_threads, innodb_read_io_threads और max_connections।

sysbench का उपयोग करके MySQL प्रदर्शन बेंचमार्क के बारे में अधिक जानने के लिए, इस ब्लॉग पोस्ट को देखें, SysBench का उपयोग करके MySQL और MariaDB के बेंचमार्क प्रदर्शन कैसे करें।

ऑनलाइन स्कीमा परिवर्तन टूल का उपयोग करें

स्कीमा परिवर्तन कुछ ऐसा है जो संबंधपरक डेटाबेस में अपरिहार्य है। जैसे-जैसे एप्लिकेशन बढ़ता है और समय के साथ और अधिक मांग हो जाता है, इसे निश्चित रूप से डेटाबेस में कुछ संरचना परिवर्तन की आवश्यकता होती है। कुछ डीडीएल ऑपरेशंस हैं जो टेबल का पुनर्निर्माण करेंगे और इस प्रकार अन्य डीएमएल स्टेटमेंट को चलाने के लिए अवरुद्ध कर देंगे और यदि आप एक विशाल टेबल पर संरचनात्मक परिवर्तन कर रहे हैं तो यह आपके डेटाबेस उपलब्धता को प्रभावित कर सकता है। डीडीएल संचालन को अवरुद्ध करने की सूची देखने के लिए, इस MySQL दस्तावेज़ पृष्ठ को देखें और उन संचालनों की तलाश करें जिनके पास "परमिट समवर्ती डीएमएल" =नहीं है।

यदि आप स्कीमा परिवर्तन करते समय उत्पादन सर्वर पर डाउनटाइम बर्दाश्त नहीं कर सकते हैं, तो संभवतः प्रारंभिक चरण में ऑनलाइन स्कीमा परिवर्तन उपकरण को कॉन्फ़िगर करना एक अच्छा विचार है। इस उदाहरण में, हम जीथब द्वारा निर्मित एक ऑनलाइन स्कीमा परिवर्तन, जीएच-ओस्ट को स्थापित और कॉन्फ़िगर करते हैं। घ-ओस्ट बाइनरी लॉग स्ट्रीम का उपयोग तालिका परिवर्तनों को कैप्चर करने के लिए करता है और अतुल्यकालिक रूप से उन्हें घोस्ट टेबल पर लागू करता है।

CentOS बॉक्स पर gh-ost स्थापित करने के लिए, बस निम्न चरणों का पालन करें:

एक कदम

 नवीनतम gh-ost यहां से डाउनलोड करें: 

$ wget https://github.com/github/gh-ost/releases/download/v1.0.48/gh-ost-1.0.48-1.x86_64.rpm

दूसरा चरण

पैकेज स्थापित करें:

$ yum localinstall gh-ost-1.0.48-1.x86_64.rpm 

तीसरा चरण

घ-ओस्ट के लिए एक डेटाबेस उपयोगकर्ता बनाएं यदि वह मौजूद नहीं है, और इसे उचित विशेषाधिकारों के साथ प्रदान करें:

mysql> CREATE USER 'gh-ost'@'{host}' IDENTIFIED BY 'ghostP455';
mysql> GRANT ALTER, CREATE, DELETE, DROP, INDEX, INSERT, LOCK TABLES, SELECT, TRIGGER, UPDATE ON {db_name}.* TO 'gh-ost'@'{host}';
mysql> GRANT SUPER, REPLICATION SLAVE ON *.* TO 'gh-ost'@'{host}';

** {होस्ट} और {db_name} को उनके उपयुक्त मानों से बदलें। आदर्श रूप से, {होस्ट} दास मेजबानों में से एक है जो ऑनलाइन स्कीमा परिवर्तन करेगा। विवरण के लिए gh-ost दस्तावेज़ देखें।

चरण चार

उपयोगकर्ता नाम और पासवर्ड को /root/.gh-ost.cnf के अंतर्गत संग्रहीत करने के लिए gh-ost कॉन्फ़िगरेशन फ़ाइल बनाएं:

[client]
user=gh-ost
password=ghostP455

इसी तरह, आप डेटाबेस सर्वर पर Percona टूलकिट ऑनलाइन स्कीमा चेंज (pt-osc) कॉन्फ़िगर कर सकते हैं। विचार यह सुनिश्चित करने के लिए है कि आप पहले इस उपकरण के साथ डेटाबेस सर्वर पर तैयार हैं जो भविष्य में इस ऑपरेशन को चलाने की संभावना है।

पेरकोना टूलकिट का उपयोग करें

पेरकोना टूलकिट उन्नत ओपन सोर्स कमांड-लाइन टूल्स का एक संग्रह है, जिसे पेरकोना द्वारा विकसित किया गया है, जो कि विभिन्न प्रकार के MySQL, MongoDB और PostgreSQL सर्वर और सिस्टम कार्यों को करने के लिए इंजीनियर हैं जो बहुत कठिन या जटिल हैं। मैन्युअल रूप से प्रदर्शन करें। ये उपकरण अंतिम तारणहार बन गए हैं, जिनका उपयोग दुनिया भर के DBA द्वारा MySQL और MariaDB सर्वर में पाए जाने वाले तकनीकी मुद्दों को हल करने या हल करने के लिए किया जाता है।

Percona टूलकिट स्थापित करने के लिए, बस निम्न आदेश चलाएँ:

$ yum install https://repo.percona.com/yum/percona-release-latest.noarch.rpm
$ yum install percona-toolkit

इस पैकेज में 30 से अधिक टूल उपलब्ध हैं। उनमें से कुछ विशेष रूप से MongoDB और PostgreSQL के लिए डिज़ाइन किए गए हैं। MySQL समस्या निवारण और प्रदर्शन ट्यूनिंग के लिए कुछ सबसे लोकप्रिय उपकरण हैं pt-stalk, pt-mysql-summary, pt-query-digest, pt-table-checksum, pt-table-sync और pt-archiver। यह टूलकिट डीबीए को मास्टर और प्रतिकृति डेटा स्थिरता की जांच करके, कुशलतापूर्वक पंक्तियों को संग्रहित करके, डुप्लिकेट इंडेक्स ढूंढकर, लॉग और tcpdump से MySQL क्वेरी का विश्लेषण करके और बहुत कुछ करके MySQL प्रतिकृति अखंडता को सत्यापित करने में मदद कर सकता है।

निम्न उदाहरण एक उपकरण (पीटी-टेबल-चेकसम) आउटपुट दिखाता है जहां यह मास्टर पर चेकसम क्वेरी निष्पादित करके ऑनलाइन प्रतिकृति स्थिरता जांच कर सकता है, जो मास्टर के साथ असंगत प्रतिकृतियों पर अलग-अलग परिणाम उत्पन्न करता है:

$ pt-table-checksum --no-check-binlog-format --replicate-check-only
Checking if all tables can be checksummed ...
Starting checksum ...

Differences on mysql2.local

TABLE CHUNK CNT_DIFF CRC_DIFF CHUNK_INDEX LOWER_BOUNDARY UPPER_BOUNDARY
mysql.proc 1 0 1
mysql.tables_priv 1 0 1
mysql.user 1 1 1

उपरोक्त आउटपुट से पता चलता है कि स्लेव (mysql2.local) पर 3 टेबल हैं जो मास्टर के साथ असंगत हैं। फिर हम मास्टर से लापता डेटा को पैच करने के लिए पीटी-टेबल-सिंक टूल का उपयोग कर सकते हैं, या बस दास को एक बार फिर से सिंक कर सकते हैं।

सर्वर को लॉक करें

आखिरकार, कॉन्फ़िगरेशन और तैयारी चरण पूरा होने के बाद, हम डेटाबेस नोड को सार्वजनिक नेटवर्क से अलग कर सकते हैं और सर्वर की पहुंच को ज्ञात होस्ट और नेटवर्क तक सीमित कर सकते हैं। आप फ़ायरवॉल (iptables, फ़ायरवॉल, ufw), सुरक्षा समूह, host.allow और/या host.deny का उपयोग कर सकते हैं या यदि आपके पास एक से अधिक नेटवर्क इंटरफ़ेस हैं तो इंटरनेट का सामना करने वाले नेटवर्क इंटरफ़ेस को अक्षम कर सकते हैं।

iptables के लिए, '-m comment --comment' ध्वज का उपयोग करके प्रत्येक नियम के लिए एक टिप्पणी निर्दिष्ट करना महत्वपूर्ण है:

$ iptables -A INPUT -p tcp -s 192.168.0.0/24 --dport 22 -m comment --comment 'Allow local net to SSH port' -j ACCEPT
$ iptables -A INPUT -p tcp -s 192.168.0.0/24 --dport 3306 -m comment --comment 'Allow local net to MySQL port' -j ACCEPT
$ iptables -A INPUT -p tcp -s 192.168.0.0/24 --dport 9999 -m comment --comment 'Allow local net to backup streaming port' -j ACCEPT
$ iptables -A INPUT -p tcp -s 0.0.0.0/0 -m comment --comment 'Drop everything apart from the above' -j DROP

उबंटू के फ़ायरवॉल (ufw) के समान, हमें पहले डिफ़ॉल्ट नियम को परिभाषित करने की आवश्यकता है और फिर इसी तरह MySQL/MariaDB के लिए एक समान नियम बना सकते हैं:

$ sudo ufw default deny incoming comment 'Drop everything apart from the above'
$ sudo ufw default allow outgoing comment 'Allow outgoing everything'
$ sudo ufw allow from 192.168.0.0/24 to any port 22 comment 'Allow local net to SSH port'
$ sudo ufw allow from 192.168.0.0/24 to any port 3306 comment 'Allow local net to MySQL port'
$ sudo ufw allow from 192.168.0.0/24 to any port 9999 comment 'Allow local net to backup streaming port'

फ़ायरवॉल सक्षम करें:

$ ufw enable

फिर, सत्यापित करें कि नियम सही तरीके से लोड किए गए हैं:

$ ufw status verbose
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)

New profiles: skip

To                         Action From
--                         ------ ----
22                         ALLOW IN 192.168.0.0/24             # Allow local net to SSH port
3306                       ALLOW IN 192.168.0.0/24             # Allow local net to MySQL port
9999                       ALLOW IN 192.168.0.0/24             # Allow local net to backup streaming port

फिर से, नियम को बेहतर ढंग से समझने में हमारी सहायता करने के लिए प्रत्येक नियम पर टिप्पणियां निर्दिष्ट करना बहुत महत्वपूर्ण है।

दूरस्थ डेटाबेस एक्सेस प्रतिबंध के लिए, हम इस ब्लॉग पोस्ट में दिखाए गए वीपीएन सर्वर का भी उपयोग कर सकते हैं, क्लाउड में अपने डेटाबेस क्लस्टर तक सुरक्षित पहुंच के लिए ओपनवीपीएन का उपयोग करना।

निष्कर्ष

एक प्रोडक्शन सर्वर तैयार करना स्पष्ट रूप से एक आसान काम नहीं है, जिसे हमने इस ब्लॉग श्रृंखला में दिखाया है। यदि आप चिंतित हैं कि आप खराब हो जाएंगे, तो आप अपने डेटाबेस क्लस्टर को परिनियोजित करने के लिए ClusterControl का उपयोग क्यों नहीं करते? ClusterControl का डेटाबेस परिनियोजन में बहुत अच्छा ट्रैक रिकॉर्ड है और इसने अब तक सभी परिवेशों के लिए 70,000 से अधिक MySQL और MariaDB परिनियोजन को सक्षम किया है।