शुक्रवार, 12 जुलाई 2019

MySQL आप टेबलस्पेस को कैसे पुनर्स्थापित करते हैं

MySQL आप टेबलस्पेस को कैसे पुनर्स्थापित करते हैं?

यह नई जानकारी नहीं है, लेकिन मैंने इसे अभी तक इसे कवर नहीं किया है, जो इसे इसकी आवश्यकता है।

यदि आप अपनी ibd फ़ाइलें खो देते हैं ... तो आप अपना डेटा खो देते हैं। इसलिए यदि आपके पास एक प्रति उपलब्ध है .. या यदि आप किसी अन्य डेटाबेस से सिंक्रनाइज़ कर रहे हैं, तो भी आप इसे आयात कर सकते हैं क्या / आप कैसे टेबलस्पेस खो देते हैं?

यहाँ टेबलस्पेस को पुनर्प्राप्त करने के लिए एक सरल उदाहरण है।



mysql> Create database demo;

mysql> use demo;

mysql> CREATE TABLE `demotable` (
-> `id` int(11) NOT NULL AUTO_INCREMENT,
-> `dts` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
-> PRIMARY KEY (`id`)
-> ) ENGINE=InnoDB;


अब हम कुछ डेटा स्टोर करते हैं ...


mysql> INSERT INTO demotable (id) VALUES (NULL);
Query OK, 1 row affected (0.10 sec)

mysql> INSERT INTO demotable (id) VALUES (NULL);
Query OK, 1 row affected (0.08 sec)

mysql> SELECT * FROM demotable;
+----+---------------------+
| id | dts |
+----+---------------------+
| 1 | 2019-07-12 23:31:34 |
| 2 | 2019-07-12 23:31:35 |
+----+---------------------+
2 rows in set (0.00 sec)


ठीक है अब इसे तोड़ने दो ।।


# systemctl stop mysqld
# cd /var/lib/mysql/demo/
# ls -ltr
total 80
-rw-r-----. 1 mysql mysql 114688 Jul 12 23:31 demotable.ibd
# mv demotable.ibd /tmp/

# systemctl start mysqld
# mysql demo

mysql> show tables;
+----------------+
| Tables_in_demo |
+----------------+
| demotable |
+----------------+
1 row in set (0.00 sec)

mysql> desc demotable;
+-------+-----------+------+-----+-------------------+-----------------------------------------------+
| Field | Type | Null | Key | Default | Extra |
+-------+-----------+------+-----+-------------------+-----------------------------------------------+
| id | int(11) | NO | PRI | NULL | auto_increment |
| dts | timestamp | NO | | CURRENT_TIMESTAMP | DEFAULT_GENERATED on update CURRENT_TIMESTAMP |
+-------+-----------+------+-----+-------------------+-----------------------------------------------+
2 rows in set (0.01 sec)

mysql> INSERT INTO demotable (id) VALUES (NULL);
ERROR 1812 (HY000): Tablespace is missing for table `demo`.`demotable`.


टूटी हुई और खोई हुई मेज़ ... अब हम इसे पुनः प्राप्त कर सकते हैं।


demo]# cp /tmp/demotable.ibd .

mysql> ALTER TABLE demotable DISCARD TABLESPACE;

demo]# cp /tmp/demotable.ibd .
demo]# ls -ltr
total 112
-rw-r-----. 1 root root 114688 Jul 12 23:50 demotable.ibd
demo]# chown mysql:mysql demotable.ibd
demo]# mysql demo
mysql> ALTER TABLE demotable IMPORT TABLESPACE;
ERROR 1034 (HY000): Incorrect key file for table 'demotable'; try to repair it

mysql> REPAIR TABLE demotable;
+----------------+--------+----------+---------------------------------------------------------+
| Table | Op | Msg_type | Msg_text |
+----------------+--------+----------+---------------------------------------------------------+
| demo.demotable | repair | note | The storage engine for the table doesn't support repair |
+----------------+--------+----------+---------------------------------------------------------+


ध्यान दें कि अब हमें एक और त्रुटि भी मिली .. यह आमतौर पर tmpdir के लिए उपलब्ध स्थान से जुड़ा होता है, और मरम्मत वैसे भी .ibd के लिए काम नहीं करता है।


mysql> select @@tmpdir;
+----------+
| @@tmpdir |
+----------+
| /tmp |
+----------+

# vi /etc/my.cnf
tmpdir=/var/lib/mysql-files/

# systemctl restart mysqld
# mysql demo


उदाहरण के लिए ओके ने mysql-files डायरेक्टरी का इस्तेमाल किया।
अब हम फिर से कोशिश कर सकते हैं।


mysql> ALTER TABLE demotable IMPORT TABLESPACE;
Query OK, 0 rows affected, 1 warning (0.61 sec)

mysql> INSERT INTO demotable (id) VALUES (NULL);
Query OK, 1 row affected (0.11 sec)

mysql> SELECT * FROM demotable;
+----+---------------------+
| id | dts |
+----+---------------------+
| 1 | 2019-07-12 23:31:34 |
| 2 | 2019-07-12 23:31:35 |
| 3 | 2019-07-12 23:56:08 |
+----+---------------------+


ठीक है काम किया।
अब, यह सब अच्छा और सरल है यदि आपके पास सिर्फ एक टेबल है। लेकिन 100 का क्या ...

इसे स्वचालित रूप से और निश्चित रूप से मदद करने के लिए अपने info_schema का उपयोग करें।

परीक्षण के लिए कुछ और प्रतियां बनाएं।

mysql> create table demotable1 like demotable;
Query OK, 0 rows affected (0.51 sec)

mysql> create table demotable2 like demotable;
Query OK, 0 rows affected (1.04 sec)

mysql> create table demotable3 like demotable;
Query OK, 0 rows affected (0.74 sec)

mysql> create table demotable4 like demotable;
Query OK, 0 rows affected (2.21 sec)


उन सब को तोड़ो ।।

demo]# mv *.ibd /tmp/


अब अपनी information_schema.tables तालिका का उपयोग करके, आप उन सभी कमांड का निर्माण कर सकते हैं जिनकी आपको आवश्यकता होगी।

# vi build_discard.sql
# cat build_discard.sql
SELECT CONCAT(" ALTER TABLE ",TABLE_SCHEMA,".",TABLE_NAME," DISCARD TABLESPACE; ") as CMD FROM information_schema.TABLES WHERE TABLE_SCHEMA='demo';

# vi build_import.sql
# cat build_import.sql
SELECT CONCAT(" ALTER TABLE ",TABLE_SCHEMA,".",TABLE_NAME," IMPORT TABLESPACE; ") as CMD FROM information_schema.TABLES WHERE TABLE_SCHEMA='demo';



# mysql -N < build_import.sql > import_tablespace.sql
# mysql -N < build_discard.sql | mysql demo

demo]# cp /tmp/*.ibd .
demo]# chown mysql:mysql *.ibd
# systemctl restart mysqld
# mysql demo < import_tablespace.sql
# mysql demo

mysql> INSERT INTO demotable (id) VALUES (NULL);
Query OK, 1 row affected (0.08 sec)

mysql> INSERT INTO demotable1 (id) VALUES (NULL);
Query OK, 1 row affected (0.05 sec)

mysql> INSERT INTO demotable2 (id) VALUES (NULL);
Query OK, 1 row affected (0.09 sec)

mysql> INSERT INTO demotable3 (id) VALUES (NULL);
^[[AQuery OK, 1 row affected (0.37 sec)

mysql> INSERT INTO demotable4 (id) VALUES (NULL);
Query OK, 1 row affected (0.12 sec)



और इसने काम किया।

MySQL Binlogs :: कैसे पुनर्प्राप्त करें

इसलिए मुझे एहसास हुआ कि मैंने इस स्थिति के बाद इस बारे में एक पोस्ट नहीं किया था कि हाल ही में आया था।

यहाँ परिदृश्य है: एक बैकअप आधी रात को लिया गया था, उन्होंने प्रति डेटाबेस MySQL डंप का उपयोग किया। फिर अगले दिन सुबह दस बजे डेटाबेस क्रैश हो गया। मुझे बुलाए जाने से पहले घटनाओं की एक श्रृंखला हुई थी, लेकिन वे इसे डेटाबेस के एक संस्करण तक ले गए थे, जिसमें MyISAM तालिकाओं और तालिकाओं से गायब IBD फाइलें थीं।

तो विकल्प 1, बैकअप से बहाल करना हमें आधी रात को मिलेगा और हम घंटों डेटा खो देंगे। विकल्प 2, हम 1000 की ibd फ़ाइलों को फिर से जोड़ते हैं और सब कुछ रखते हैं। तब हमारे पास विकल्प 3 था, बैकअप से पुनर्स्थापित करें, फिर हाल के परिवर्तनों के लिए बिनलॉग लागू करें।

इसे और दिलचस्प बनाने के लिए, उनके पास मेरे द्वारा बताई गई सभी ibd फाइलें नहीं थीं, और मुझे कुछ याद नहीं था। तो यकीन नहीं है कि यह कैसे संभव था लेकिन विकल्प 2 एक अमान्य विकल्प बन गया। वे निश्चित रूप से, कम से कम डेटा हानि संभव चाहते थे, इसलिए हम विकल्प 3 के साथ गए।

इसे सुरक्षित रूप से करने के लिए मैंने पोर्ट 3307 के तहत MySQL का एक और उदाहरण शुरू किया। इससे मुझे काम करने के लिए एक सुरक्षित जगह मिल गई, जबकि यातायात ने बंदरगाह 3306 उदाहरण पर MyISAM डेटा तक पहुंच पढ़ी थी।

एक बार सभी बैकअप डंप फ़ाइलें असम्पीडित और 3307 उदाहरण में आयातित मैं Binlog फ़ाइलों पर ध्यान केंद्रित करने में सक्षम था।

पहले तो यह अवधारणा वास्तव में जितना कठिन है, उससे कहीं अधिक जोखिम भरा है। यह वास्तव में बहुत आगे और सरल है।

इसलिए सबसे पहले आपको अपने बाद का डेटा ढूंढना होगा। बिनलॉग फाइलों की समीक्षा आपको यह बताती है कि क्या फाइलें प्रासंगिक हैं। मेरे मामले में, किसी तरह वे बिनलॉग को रीसेट करने में कामयाब रहे, इसलिए 117 फ़ाइल में 2 तारीख सीमाएं थीं।

पहले बिनलॉग समीक्षा के लिए, निम्न कमांड मानव-पठनीय प्रारूप में डेटा को आउटपुट करता है।
mysqlbinlog --defaults-file=/root/.my.cnf --base64-output=DECODE-ROWS --verbose mysql-bin.000117 > review_mysql-bin.000117.sql

* नोट ... उपरोक्त कमांड को चलाने में सावधानी बरतें। ध्यान दें कि मेरे पास फ़ाइल को सीधे उसी स्थान पर डंप करना है जैसे कि बिनलॉग। इसलिए मान्य करें कि आपका फ़ाइल नाम मान्य है। यह mysql-bin.000117.sql, इस mysql-bin.000101 .sql से अलग है। आप अपने बिनलॉग को 2 विकल्प और .sql से पहले एक स्थान के साथ ढीला कर देंगे।

अब डेटा को बचाने के लिए इसे लागू किया जा सकता है। चूँकि मेरे पास कई सारे बैनॉगल्स थे, जिससे मैंने एक फाइल बनाई और मैं वैसे भी समय-सीमा की दोबारा जाँच करना चाहता था।


mysqlbinlog --defaults-file=/root/.my.cnf --start-datetime="2019-07-09 00:00:00" --stop-datetime="2019-07-10 00:00:00" mysql-bin.000117 > binlog_restore.sql
mysqlbinlog --defaults-file=/root/.my.cnf mysql-bin.000118 >> binlog_restore.sql
mysqlbinlog --defaults-file=/root/.my.cnf mysql-bin.000119 >> binlog_restore.sql
mysqlbinlog --defaults-file=/root/.my.cnf --start-datetime="2019-07-10 00:00:00" --stop-datetime="2019-07-10 10:00:00" mysql-bin.000117 >> binlog_restore.sql
mysqlbinlog --defaults-file=/root/.my.cnf --stop-datetime="2019-07-10 10:00:00" mysql-bin.000120 >> binlog_restore.sql
mysqlbinlog --defaults-file=/root/.my.cnf --stop-datetime="2019-07-10 10:00:00" mysql-bin.000121 >> binlog_restore.sql

mysql --socket=/var/lib/mysql_restore/mysql.sock -e "source /var/lib/mysql/binlog_restore.sql"

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

इस स्थिति के लिए कई अलग-अलग विकल्प मौजूद थे, यह क्लाइंट के साथ सबसे अच्छी कसरत करने के लिए हुआ।

एक बार जब सभी को पुनर्स्थापित किए गए संस्करण पर सभी मान्य थे, तो यह दोनों डेटाबेसों का एक सरल पड़ाव था, डेटा निर्देशिकाओं को स्थानांतरित कर दिया (डेटादिर डिफॉल्ट्स को अक्षुण्ण रखना चाहता था), निर्देशिकाओं को केवल सुरक्षित होने के लिए और MySQL को शुरू करने के लिए चुना। अब बहाल किया गया उदाहरण 3306 पोर्ट पर था। 

सोमवार, 17 जून 2019

MySQL ग्रुप प्रतिकृति

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

सर्वर CENTOSA

mysql> INSTALL PLUGIN group_replication SONAME 'group_replication.so';
Query OK, 0 rows affected (0.02 sec)

vi my.cnf
disabled_storage_engines="MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY"
server_id=1
gtid_mode=ON
enforce_gtid_consistency=ON
binlog_checksum=NONE

log_bin=binlog
log_slave_updates=ON
binlog_format=ROW
master_info_repository=TABLE
relay_log_info_repository=TABLE

transaction_write_set_extraction=XXHASH64
group_replication_group_name="90d8b7c8-5ce1-490e-a448-9c8d176b54a8"
group_replication_start_on_boot=off
group_replication_local_address= "192.168.111.17:33061"
group_replication_group_seeds= "192.168.111.17:33061,192.168.111.89:33061,192.168.111.124:33061"
group_replication_bootstrap_group=off

mysql> SET SQL_LOG_BIN=0;
mysql> CREATE USER repl@'%' IDENTIFIED BY 'replpassword';
mysql> GRANT REPLICATION SLAVE ON *.* TO repl@'%';
mysql> FLUSH PRIVILEGES;
mysql> SET SQL_LOG_BIN=1;


CHANGE MASTER TO
MASTER_USER='repl',
MASTER_PASSWORD='replpassword'
FOR CHANNEL 'group_replication_recovery';


mysql> SET GLOBAL group_replication_bootstrap_group=ON;
Query OK, 0 rows affected (0.00 sec)


mysql> START GROUP_REPLICATION;
Query OK, 0 rows affected (3.11 sec)


mysql> SET GLOBAL group_replication_bootstrap_group=OFF;
Query OK, 0 rows affected (0.00 sec)


mysql> SELECT * FROM performance_schema.replication_group_members \G

*************************** 1. row ***************************
CHANNEL_NAME: group_replication_applier
MEMBER_ID: 1ab30239-5ef6-11e9-9b4a-08002712f4b1
MEMBER_HOST: centosa
MEMBER_PORT: 3306
MEMBER_STATE: ONLINE
MEMBER_ROLE: PRIMARY
MEMBER_VERSION: 8.0.15
इसलिए अब हम और सर्वर जोड़ सकते हैं।
सर्वर CENTOSB

vi my.cnf
disabled_storage_engines="MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY"
server_id=2
gtid_mode=ON
enforce_gtid_consistency=ON
binlog_checksum=NONE

log_bin=binlog
log_slave_updates=ON
binlog_format=ROW
master_info_repository=TABLE
relay_log_info_repository=TABLE


transaction_write_set_extraction=XXHASH64
group_replication_group_name="90d8b7c8-5ce1-490e-a448-9c8d176b54a8"
group_replication_start_on_boot=off
group_replication_local_address= "192.168.111.89:33061"
group_replication_group_seeds= "192.168.111.17:33061,192.168.111.89:33061,192.168.111.124:33061"
group_replication_bootstrap_group=off

mysql> CHANGE MASTER TO
MASTER_USER='repl',
MASTER_PASSWORD='replpassword'
FOR CHANNEL 'group_replication_recovery';
Query OK, 0 rows affected, 2 warnings (0.02 sec)

mysql> CHANGE MASTER TO GET_MASTER_PUBLIC_KEY=1;
Query OK, 0 rows affected (0.02 sec)

mysql> START GROUP_REPLICATION;
Query OK, 0 rows affected (4.03 sec)

mysql> SELECT * FROM performance_schema.replication_group_members;
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| group_replication_applier | 1ab30239-5ef6-11e9-9b4a-08002712f4b1 | centosa | 3306 | ONLINE | PRIMARY | 8.0.15 |
| group_replication_applier | 572ca2fa-5eff-11e9-8df9-08002712f4b1 | centosb | 3306 | RECOVERING | SECONDARY | 8.0.15 |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
2 rows in set (0.00 sec)


सर्वर CENTOSC

vi my.cnf
disabled_storage_engines="MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY"
server_id=3
gtid_mode=ON
enforce_gtid_consistency=ON
binlog_checksum=NONE
log_bin=binlog
log_slave_updates=ON
binlog_format=ROW
master_info_repository=TABLE
relay_log_info_repository=TABLE

transaction_write_set_extraction=XXHASH64
group_replication_group_name="90d8b7c8-5ce1-490e-a448-9c8d176b54a8"
group_replication_start_on_boot=off
group_replication_local_address= "192.168.111.124:33061"
group_replication_group_seeds= "192.168.111.17:33061,192.168.111.89:33061,192.168.111.124:33061"
group_replication_bootstrap_group=off

mysql> CHANGE MASTER TO
-> MASTER_USER='repl',
-> MASTER_PASSWORD='replpassword'
-> FOR CHANNEL 'group_replication_recovery';
Query OK, 0 rows affected, 2 warnings (0.02 sec)

mysql> CHANGE MASTER TO GET_MASTER_PUBLIC_KEY=1;
Query OK, 0 rows affected (0.02 sec)

mysql> START GROUP_REPLICATION;
Query OK, 0 rows affected (3.58 sec)
mysql> SELECT * FROM performance_schema.replication_group_members \G
*************************** 1. row ***************************
CHANNEL_NAME: group_replication_applier
MEMBER_ID: 1ab30239-5ef6-11e9-9b4a-08002712f4b1
MEMBER_HOST: centosa
MEMBER_PORT: 3306
MEMBER_STATE: ONLINE
MEMBER_ROLE: PRIMARY
MEMBER_VERSION: 8.0.15

*************************** 2. row ***************************
CHANNEL_NAME: group_replication_applier
MEMBER_ID: 572ca2fa-5eff-11e9-8df9-08002712f4b1
MEMBER_HOST: centosb
MEMBER_PORT: 3306
MEMBER_STATE: ONLINE
MEMBER_ROLE: SECONDARY
MEMBER_VERSION: 8.0.15

*************************** 3. row ***************************
CHANNEL_NAME: group_replication_applier
MEMBER_ID: c5f3d1d2-8dd8-11e9-858d-08002773d1b6
MEMBER_HOST: centosc
MEMBER_PORT: 3306
MEMBER_STATE: ONLINE
MEMBER_ROLE: SECONDARY
MEMBER_VERSION: 8.0.15
3 rows in set (0.00 sec)


तो यह सब बहुत अच्छा है, लेकिन इसका मतलब यह नहीं है कि वे ऑनलाइन जाते हैं, वे अक्सर वसूली मोड में बैठ सकते हैं।
मैंने देखा है कि यह MySQL दुर्घटनाओं के साथ अभी तक इसे स्थिर रखने की आवश्यकता है।
mysql> create database testcentosb;<br> ERROR 1290 (HY000): The MySQL server is running with the --super-read-only option so it cannot execute this statement<br>
साइड नोट उन कारकों में से कुछ को संबोधित करने के लिए -
mysql> START GROUP_REPLICATION;
ERROR 3094 (HY000): The START GROUP_REPLICATION command failed as the applier module failed to start.

mysql> reset slave all;
Query OK, 0 rows affected (0.03 sec)
- इसके बाद चेंज मास्टर कमांड से शुरुआत करें
mysql> START GROUP_REPLICATION;
ERROR 3092 (HY000): The server is not configured properly to be an active member of the group. Please see more details on error log.

[ERROR] [MY-011735] [Repl] Plugin group_replication reported: '[GCS] Error on opening a connection to 192.168.111.17:33061 on local port: 33061.'
[ERROR] [MY-011526] [Repl] Plugin group_replication reported: 'This member has more executed transactions than those present in the group. Local transactions: c5f3d1d2-8dd8-11e9-858d-08002773d1b6:1-4 >
[ERROR] [MY-011522] [Repl] Plugin group_replication reported: 'The member contains transactions not present in the group. The member will now exit the group.'

https://ronniethedba.wordpress.com/2017/04/22/this-member-has-more-executed-transactions-than-those-present-in-the-group/


[ERROR] [MY-011620] [Repl] Plugin group_replication reported: 'Fatal error during the recovery process of Group Replication. The server will leave the group.'
[ERROR] [MY-013173] [Repl] Plugin group_replication reported: 'The plugin encountered a critical error and will abort: Fatal error during execution of Group Replication'

SELECT * FROM performance_schema.replication_connection_status\G


मेरे विचार...
ध्यान रखें कि समूह प्रतिकृति एकल प्राथमिक मोड या बहु-नोड में स्थापित की जा सकती है
mysql> select @@group_replication_single_primary_mode\G
*************************** 1. row ***************************
@@group_replication_single_primary_mode: 1

mysql> create database testcentosb;
ERROR 1290 (HY000): The MySQL server is running with the --super-read-only option so it cannot execute this statement
यदि आप कोई भी प्राथमिक नोड नहीं लिखते हैं तो आपको निश्चित रूप से एक त्रुटि मिलेगी।


समूह-प्रतिकृति-एकल-प्राथमिक-मोड = बंद <- cnf फ़ाइलों में जोड़ा गया।
mysql> SELECT * FROM performance_schema.replication_group_members;
+ --------------------------- + --------------------- ----------------- + ------------- + ------------- + ---- ---------- + ------------- + ---------------- +
| चैनल का नाम               | सदस्य आईडी                             | Cross.tv_HOST | Cross.tv_PORT | Cross.tv_STATE | Cross.tv_ROLE | Cross.tv_VERSION |
+ --------------------------- + --------------------- ----------------- + ------------- + ------------- + ---- ---------- + ------------- + ---------------- +
| group_replication_applier | 1ab30239-5ef6-11e9-9b4a-08002712f4b1 | centosa     |         3306 | ठीक हो   | प्राथमिक     | 8.0.15         |
| group_replication_applier | 572ca2fa-5eff-11e9-8df9-08002712f4b1 | centosb     |         3306 | ऑनलाइन       | प्राथमिक     | 8.0.15         |
| group_replication_applier | c5f3d1d2-8dd8-11e9-858d-08002773d1b6 | centosc     |         3306 | ठीक हो   | प्राथमिक     | 8.0.15         |
+ --------------------------- + --------------------- ----------------- + ------------- + ------------- + ---- ---------- + ------------- + ---------------- +

सेट में 3 पंक्तियाँ (0.00 सेकंड)


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

mysql> SELECT * FROM performance_schema.replication_group_members ;
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| group_replication_applier | 1ab30239-5ef6-11e9-9b4a-08002712f4b1 | centosa | 3306 | ONLINE | PRIMARY | 8.0.15 |
| group_replication_applier | 572ca2fa-5eff-11e9-8df9-08002712f4b1 | centosb | 3306 | ONLINE | SECONDARY | 8.0.15 |
| group_replication_applier | c5f3d1d2-8dd8-11e9-858d-08002773d1b6 | centosc | 3306 | ONLINE | SECONDARY | 8.0.15 |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
3 rows in set (0.00 sec)

[root@centosa]# systemctl stop mysqld

mysql> SELECT * FROM performance_schema.replication_group_members ;
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| group_replication_applier | 572ca2fa-5eff-11e9-8df9-08002712f4b1 | centosb | 3306 | ONLINE | PRIMARY | 8.0.15 |
| group_replication_applier | c5f3d1d2-8dd8-11e9-858d-08002773d1b6 | centosc | 3306 | ONLINE | SECONDARY | 8.0.15 |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
2 rows in set (0.00 sec)

[root@centosa]# systemctl start mysqld
[root@centosa]# mysql
mysql> START GROUP_REPLICATION;
Query OK, 0 rows affected (3.34 sec)

mysql> SELECT * FROM performance_schema.replication_group_members ;
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| group_replication_applier | 1ab30239-5ef6-11e9-9b4a-08002712f4b1 | centosa | 3306 | RECOVERING | SECONDARY | 8.0.15 |
| group_replication_applier | 572ca2fa-5eff-11e9-8df9-08002712f4b1 | centosb | 3306 | ONLINE | PRIMARY | 8.0.15 |
| group_replication_applier | c5f3d1d2-8dd8-11e9-858d-08002773d1b6 | centosc | 3306 | ONLINE | SECONDARY | 8.0.15 |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
3 rows in set (0.00 sec)


अब रिकवरी अभी भी एक मुद्दा था, क्योंकि यह केवल वापस शामिल नहीं होगा। फिर से सभी खातों और चरणों की समीक्षा करनी थी, लेकिन मैंने इसे अंततः वापस ले लिया।

mysql> SELECT * FROM performance_schema.replication_group_members;
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| group_replication_applier | 1ab30239-5ef6-11e9-9b4a-08002712f4b1 | centosa | 3306 | ONLINE | SECONDARY | 8.0.15 |
| group_replication_applier | 572ca2fa-5eff-11e9-8df9-08002712f4b1 | centosb | 3306 | ONLINE | PRIMARY | 8.0.15 |
| group_replication_applier | c5f3d1d2-8dd8-11e9-858d-08002773d1b6 | centosc | 3306 | ONLINE | SECONDARY | 8.0.15 |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
3 rows in set (0.00 sec)


मुझे इसके साथ और अधिक परीक्षण करने की आवश्यकता है क्योंकि मैं अभी तक 100% बेचा नहीं गया हूं क्योंकि मुझे इसकी आवश्यकता है क्योंकि मैं गैलेरा प्रतिकृति की ओर झुक रहा हूं।

ब्याज का URLS


  • https://dev.mysql.com/doc/refman/8.0/en/group-replication.html
  • https://dev.mysql.com/doc/refman/8.0/en/group-replication-deploying-in-single-primary-mode.html
  • http://datacharmer.blogspot.com/2017/01/mysql-group-replication-vs-multi-source.html
  • https://dev.mysql.com/doc/refman/8.0/en/group-replication-launching.html
  • https://dev.mysql.com/doc/refman/8.0/en/group-replication-configuring-instances.html
  • https://dev.mysql.com/doc/refman/8.0/en/group-replication-adding-instances.html
  • https://ronniethedba.wordpress.com/2017/04/22/how-to-setup-mysql-group-replication/
  • https://www.digitalocean.com/community/tutorials/how-to-configure-mysql-group-replication-on-ubuntu-16-04
  • https://dev.mysql.com/doc/refman/8.0/en/group-replication-options.html#sysvar_group_replication_group_seeds
  • https://bugs.mysql.com/bug.php?id=90534
  • https://www.percona.com/blog/2017/02/24/battle-for-synchronous-replication-in-mysql-galera-vs-group-replication/
  • https://lefred.be/content/mysql-group-replication-is-sweet-but-can-be-sour-if-you-misunderstand-it/
  • https://www.youtube.com/watch?v=IfZK-Up03Mw
  • https://mysqlhighavailability.com/mysql-group-replication-a-quick-start-guide/
  • सोमवार, 3 जून 2019

    Max_connections 214 4.15.0-46-जेनेरिक # 49-उबंटू

    तो आपके my.cnf फ़ाइल में 214 तक के मान से सेट होने वाले अधिकतम_कनेक्ट का मुद्दा उबंटू पर थोड़ी देर के लिए रहा है।

    एक उदाहरण के रूप में, यह 2015 में यहां वापस नोट किया गया था



    मैं हाल ही में फिर से इसमें भाग गया और निम्न चरणों के साथ हल किया गया।


    # cp /lib/systemd/system/mysql.service /etc/systemd/system/
    # cd /etc/systemd/system/
    # vi mysql.service

    LimitNOFILE=infinity
    LimitMEMLOCK=infinity

    # systemctl daemon-reload
    # systemctl restart mysql


    एक बार उन चरणों को पूरा करने के बाद MySQL कनेक्शन my.cnf फ़ाइल में दिए गए पैरामीटर पर स्थिर थे।

    रविवार, 14 अप्रैल 2019

    सरल KeepaliveD की स्थापना की

    इसलिए अभी काफी समय से आसपास रखा गया है .... हालांकि यह अभी भी कई लोगों के लिए एक रहस्य है।
    तो यह एक बहुत ही सरल उदाहरण है कि MySQL के साथ कैसे काम किया जा सकता है। उम्मीद है, यह सवालों के साथ उन लोगों की मदद कर सकता है।

    हम दास स्थापित करने के लिए एक सरल गुरु होगा। अर्थ .. हम एक को लिखते हैं जब तक कि हम किसी घटना के लिए दूसरे को विफल नहीं करते।

    पहली - स्थापित रखें


    # यम खोज को रखा गया
    Keepaliven .x86_64: लोड बैलेंसर और उच्च उपलब्धता सेवा

      नाम और सारांश केवल मेल खाते हैं , हर चीज के लिए "सभी खोजें" का उपयोग करें।
    # yum -y स्थापित रखें

    अब आपके पास एक config फाइल होनी चाहिए

    # ls -ltr /etc/keepalived/keepalived.conf  

    ऑरिजनल रखें क्योंकि आप हमेशा बैकअप लेते हैं ... सही है ...।
    # cp /etc/keepalived/keepalived.conf /etc/keepalived/keepalived.conf.orig

    तो आपको एक ipaddress पता लगाने की आवश्यकता है जिसे आप अपने वर्चुअल आईपी के लिए उपयोग कर सकते हैं। मैंने इस उदाहरण के लिए 192.168.0.123 उठाया।

    इसके बाद, हम अपनी नई कॉन्फिगर फाइल के लिए उपयोग की जाने वाली स्क्रिप्ट सेट करेंगे।

    कुछ बातें मैंने यहाँ कीं ।।
    मैं रखने के लिए एक .cnf फ़ाइल को छोड़ दिया और एक लॉग इन / / / सब रखा।
    यह उदाहरण के लिए सरल बनाता है ताकि आप ऐसा कर सकें या अपनी स्वयं की cnf फ़ाइलों का उपयोग कर सकें।

    पटकथा:

    cat /etc/keepalived/keepalived_check.sh  
    #! / bin / bash

    # मॉनिटर mysql स्टेटस

    # अगर यह नोड mysql मर चुका है

    # और इसका गुलाम जिंदा है, तो इसकी रखवाली बंद करो। अन्य नोड आईपी को बांध देगा।



    निर्यात MYSQL_HOME = / etc / रखवाली /

    निर्यात पथ = $ MYSQL_HOME / बिन: $ पथ



    mysql = "/ usr / bin / mysql"

    mysqladmin = "/ usr / bin / mysqladmin"

    delay_file = "$ MYSQL_HOME / slave_delay_second.log"

    slave_host = $ 1





    ALIVE = $ ($ mysqladmin --defaults-file = $ MYSQL_HOME / .my.localhost.nf   पिंग | grep जिंदा | wc -l);

    REMOTEALIVE = $ ($ mysqladmin --defaults-file = $ MYSQL_HOME / .my.remotehost.cnf   पिंग | grep जिंदा | wc -l);



    अगर [[$ ALIVE-1]]

    फिर

    #echo "MySQL नीचे है"

            अगर [[$ REMOTEALIVE -eq 1]]

            फिर

    #         गूंज "चुप रहो जिंदा रहो"

                systemctl रोक रखना  

    #       गूंज "रखवाले रोक"

            फाई

    #अन्य

    # माय "MySQL ऊपर है"

    #दिनांक

    फाई



    बाहर निकलें 0 # किया गया

    नई कॉन्फ़िग फ़ाइल

    cat /etc/keepalived/keepalived.conf
    Global_defs {



          सूचना_मेल {

            anothermysqldba@gmail.com  

          }



          notification_email_from othermysqldba@gmail.com  

          smtp_server लोकलहोस्ट

          smtp_connect_timeout 30



          }







    vrrp_script check_mysql {

       स्क्रिप्ट "/etc/keepalived/keepalived_check.sh"

       अंतराल २

       वजन 2

    }







    vrrp_instance VI_1 {



          राज्य मास्टर

          इंटरफ़ेस enp0s8   # <--- व्हाट्स इंटरफेम नॉमल योर रियल आईपी / sbin / ifconfig

            # आईपी लिंक शो के साथ मिला

          virtual_router_id 51

          प्राथमिकता १०१

          advert_int 1

          nopreempt   # केवल उच्च प्राथमिकता नोड पर आवश्यक है

          प्रमाणीकरण {

            ऑरल_टाइप PASS

            11_11 पर

          }





          track_script {

            check_mysql

          }



          virtual_ipaddress {

            192.168.0.123  

          }




    }



    यह सब बहुत अच्छा है लेकिन क्या यह काम करता है ...।

    तो हमारे पास 2 होस्ट हैं

    [रूट @ सेंटोसा रखा हुआ] # होस्टनाम

    centosa

    [root @ centosb Keepalived] # hostname
    centosb

    रखना शुरू कर दिया

    [रूट @ सेंटोसा को रखा गया है] # सिस्टमटाल की स्थिति को बनाए रखा गया है
    ● Keepalived.service - LVS और VRRP उच्च उपलब्धता मॉनिटर
       भरी हुई: भरी हुई (/usr/lib/systemd/system/keepalived.service; विकलांग; वेंडर प्रेसर: अक्षम)
       सक्रिय: निष्क्रिय (मृत)
    [रूट @ सेंटोसा को रखा गया] # सिस्टेक्टल को फिर से रखा गया
    [रूट @ सेंटोसा को रखा गया है] # सिस्टमटाल की स्थिति को बनाए रखा गया है
    Keepalived.service - LVS और VRRP उच्च उपलब्धता मॉनिटर
       भरी हुई: भरी हुई (/usr/lib/systemd/system/keepalived.service; विकलांग; वेंडर प्रेसर: अक्षम)
        सक्रिय: सक्रिय (चल रहा है)

    [रूट @ सेंटोसा को रखा गया] # ssh 192.168.0.123 'hostname'
    root@192.168.0.123 का पासवर्ड:  

    centosa

    कनेक्शन कार्य पहले से ही साबित करें

    [रूट @ सेंटोसा रखा हुआ] # mysql --defaults-file = .my.remotehost.cnf --host = 192.168.0.101   -host "select @@ hostname"
    + ------------ +
    | @@ होस्टनाम |
    + ------------ +
    | centosb     |
    + ------------ +
    [रूट @ सेंटोसा को रखा गया] # mysql --defaults-file = .my.remotehost.cnf --host = 192.168.0.102   -host "select @@ hostname"
    + ------------ +
    | @@ होस्टनाम |
    + ------------ +
    | centosa     |
    + ------------ +

    डबल चेक करें कि यह चल रहा है ...

    [root @ centosa keepalived] # सिस्टेक्स्टल स्टेटस कीपेल्ड | grep सक्रिय
        सक्रिय: सक्रिय  

    [root @ centosb Keepalived] # systemctl स्टेटस को सुरक्षित रखा गया | grep सक्रिय
        सक्रिय: सक्रिय  

    वर्तमान वीआईपी का परीक्षण करें ... mysql को रोकें और वही वीआईपी परिवर्तन होस्ट देखें ...

    [रूट @ सेंटोसा को रखा गया] # mysql --defaults-file = .my.remotehost.cnf --host = 192.168.0.123   -host "select @@ hostname"
    + ------------ +
    | @@ होस्टनाम |
    + ------------ +
    | centosa     |
    + ------------ +
    [रूट @ सेंटोसा को रखा गया] # सिस्टेक्स्ल ने मायस्कल्ड को रोक दिया  
    [रूट @ सेंटोसा को रखा गया] # mysql --defaults-file = .my.remotehost.cnf --host = 192.168.0.123   -host "select @@ hostname"
    + ------------ +
    | @@ होस्टनाम |
    + ------------ +
    | centosb     |
    + ------------ +

    मंगलवार, 9 अप्रैल 2019

    कभी-कभी धीमा डेटाबेस .. डेटाबेस नहीं है ...

    इसलिए मुझे हाल ही में यह देखने के लिए कहा गया था कि अपडेटेड MySQL 5, .6 पुराने 5.5 की तुलना में धीमा क्यों था

    इसलिए मैंने मानक चर और कैश और इत्यादि को देखते हुए चारों ओर से शुरुआत की

    परीक्षण मामला एक साधारण दिनचर्या थी जो 5.5 की तुलना में 5.6 पर चलने के लिए लगभग दोगुनी थी।

    मिश्रण में जोड़ने के लिए .. 5.6 संस्करण में Innodb_buffer_pool_size और कुल मिलाकर अधिक राम दोगुना था।

    इसलिए मैंने MySQLslap के साथ कुछ परीक्षण शुरू किए ...

    मैसकल्सलैप परीक्षण इसे 5.6 पर धीमा दिखाता है

    5.6:
    mysqlslap --defaults-file = ./। my.cnf --concurrency = 150 - मान = 130 -query = / test.sql --create-schema = applicationdata --verbose
    बेंचमार्क
    सभी प्रश्नों को चलाने के लिए सेकंड की औसत संख्या: 0.028 सेकंड
    सभी प्रश्नों को चलाने के लिए सेकंड की न्यूनतम संख्या: 0.019 सेकंड
    सभी प्रश्नों को चलाने के लिए अधिकतम सेकंड: 0.071 सेकंड
    प्रश्नों को चलाने वाले ग्राहकों की संख्या: 150
    प्रति ग्राहक औसत प्रश्नों की संख्या: 1

    5.5:
    mysqlslap --defaults-file = ./। my.cnf --concurrency = 150 - मान = 130 --query = / test.sql --create-schema = applicationdata --verbose
    बेंचमार्क
    सभी प्रश्नों को चलाने के लिए सेकंड की औसत संख्या: 0.015 सेकंड
    सभी प्रश्नों को चलाने के लिए न्यूनतम सेकंड: 0.011 सेकंड
    सभी प्रश्नों को चलाने के लिए अधिकतम सेकंड: 0.024 सेकंड
    प्रश्नों को चलाने वाले ग्राहकों की संख्या: 150
    प्रति ग्राहक औसत प्रश्नों की संख्या: 1


    यह सब सार्वजनिक बेंचमार्क के खिलाफ जाता है
    http://dimitrik.free.fr/blog/archives/2013/02/mysql-performance-mysql-56-ga-vs-mysql-55-32cores.html

    इसलिए मैंने डिस्क स्तर की जाँच की -

    5.6:
    # dd if = / dev / zero of = test bs = 1048576 count = 2048
    में 2048 + 0 रिकॉर्ड
    2048 + 0 रिकॉर्ड बनाया
    2147483648 बाइट्स (2.1 जीबी) की नकल, 25.7401 एस, 83.4 एमबी / एस

    # dd if = का परीक्षण = / dev / null bs = 1048576
    में 2048 + 0 रिकॉर्ड
    2048 + 0 रिकॉर्ड बनाया
    2147483648 बाइट्स (2.1 जीबी) कॉपी, 29.1527 एस, 73.7 एमबी / एस

    5.5:
    # dd if = / dev / zero of = test bs = 1048576 count = 2048
    में 2048 + 0 रिकॉर्ड
    2048 + 0 रिकॉर्ड बनाया
    2147483648 बाइट्स (2.1 जीबी) कॉपी, 19.9214 सेकंड, 108 एमबी / एस

    # dd if = का परीक्षण = / dev / null bs = 1048576
    में 2048 + 0 रिकॉर्ड
    2048 + 0 रिकॉर्ड बनाया
    2147483648 बाइट्स (2.1 जीबी) कॉपी, 20.0243 सेकंड, 107 एमबी / एस



    यहाँ 5.5 के साथ डिस्क MySQL की परवाह किए बिना धीमी है। तो इस मामले में .... डिस्क की गति को ठीक करने के लिए देखो .. MySQL ठीक चल रहा था और होगा।

    बुधवार, 23 मई 2018

    प्रॉक्सी MySQL :: HAproxy || ProxySQL और KeepAlived

    तो जब आपके MySQL ट्रैफ़िक को रूट करने की बात आती है तो कई विकल्प मौजूद होते हैं। 

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

    व्यक्तिगत रूप से मुझे ProxySQL पसंद है। पेर्कोनिया के पास भी कुछ ब्लॉग हैं
    पेर्कोन में प्रॉक्सीएसक्यूएल संस्करण भी उपलब्ध है

    मैं सोच रहा था कि मैं कुछ उदाहरण लिखूंगा लेकिन कुल परकोना ने इसे सब कुछ समझाया है। मैं उन पदों से कुछ भी नहीं लेना चाहता हूं, इसके बजाय इंगित करता हूं कि उन यूआरएल के माध्यम से बहुत अच्छी जानकारी उपलब्ध है। तो जो पहले से लिखा गया है उसे फिर से लिखने की बजाय, मैं रुचि रखने वालों के लिए जानकारी का संग्रह तैयार करूंगा।

    सबसे पहले तुलना करें और खुद को तय करें कि आपको क्या चाहिए और चाहिए। पाठ्यक्रम का निम्नलिखित लिंक ProxySQL की ओर पक्षपातपूर्ण होने जा रहा है लेकिन यह आपको विचार करने के लिए एक समग्र दायरा देता है।
    यदि आपके पास मास्टर के लिए क्लस्टर या मास्टर है और आपको परवाह नहीं है कि कौन से सर्वर लिखते हैं बनाम पढ़ते हैं, बस जब तक आपके पास कनेक्शन हो;तो HAproxy आपके लिए एक सरल तेज़ सेट अप की संभावना है।

    ProxySQL के साथ बोनस एक भारित फैशन, आसानी से यातायात को सॉर्ट करने की क्षमता है। तो आप लिख सकते हैं कि नोड 1 पर जाएं, और नोड 2 और नोड 3 से खींचें का चयन करें। इस पर दस्तावेज़ीकरण यहां पाया जा सकता है:
    हां यह HAproxy के साथ किया जा सकता है लेकिन आपको तदनुसार आवेदन को निर्देश देना होगा।
    यह आपके क्वेरी नियमों के आधार पर ProxySQL में संभाला जाता है।

    अब यहां स्पष्ट प्रश्न: ठीक है तो आप ProxySQL को विफलता के एक बिंदु बनने से कैसे रोकते हैं?

    आप निवेश कर सकते हैं एक मजबूत लोड बैलेंसर और इत्यादि आदि ... इस पर हार्डवेयर टॉस करें .... या इसे अपने आप को आसान बनाएं और ओपन सोर्स का समर्थन करें और KeepAlive डी का उपयोग करें। यह सेट अप करना बहुत आसान है और इसमें से सभी को फिर से दस्तावेज किया गया है:
    यदि आपने कभी लुआ और mysql-proxy से निपटाया है, तो ProxySQL और Keepalived आपके लिए बहुत आसान होना चाहिए। यदि आप अभी भी इसे किसी कारण से चाहते हैं: https://launchpad.net/mysql-proxy

    भले ही आप HAproxy, ProxySQL या किसी अन्य समाधान का चयन करते हैं, आपको यह सुनिश्चित करने की ज़रूरत है कि एक बार दूसरे के साथ विफलता के एक बिंदु को प्रतिस्थापित न करें और इसके लिए बनाए रखा जाए। यदि आप प्रॉक्सी का उपयोग कर रहे हैं तो ऐसा करने के लिए बहुत कम कारण नहीं है।

    तो ProxySQL पर कुछ और चीजें।
    • यदि आप उन होस्ट्स को ट्रैक करते हैं जो आपकी रिपोर्टिंग या निगरानी के माध्यम से आपके डेटाबेस से कनेक्ट होते हैं, तो उन आईपीएस या होस्टनाम का एहसास हो रहा है जो अब प्रॉक्सी सर्वर होने जा रहे हैं।
    • फिर आपके पास पहले से ही MySQL में मौजूद सभी उपयोगकर्ताओं के बारे में क्या है? क्या आप उन्हें proxysql में माइग्रेट कर सकते हैं? हाँ तुम कर सकते हो। इसमें कुछ कदम उठाए जाते हैं लेकिन यह सक्षम है। यहां इसका एक उदाहरण दिया गया है:
    • सुनिश्चित करें कि आप मल्टी लेयर कॉन्फ़िगरेशन सिस्टम को समझते हैं। डिस्क पर अपनी जानकारी बचाओ!
    • ProxySQL MySQL डिफ़ॉल्ट पोर्ट 3306 पर चला सकता है
    • अब अपने अधिकतम_कनेक्शन को ध्यान में रखें। यदि आपके पास mysql में Max_connections 500 पर सेट है, तो यह मानक उपयोगकर्ताओं के लिए आपकी सीमा की सीमा है। ProxySQL के साथ अब आप सिस्टम भर में उपयोगकर्ताओं को फैला सकते हैं और अधिकतम प्रति नोड सेट कर सकते हैं। तो यह सुनिश्चित करने में सहायता के लिए कि आप 500 कनेक्शन हिट नहीं करते हैं, MySQL-max_connections को MySQL मान से थोड़ा कम सेट करें।
    • मॉनीटर मॉड्यूल और स्टेटस का लाभ उठाएं .. जानें कि आपके प्रॉक्सी और ट्रैफिक के साथ क्या चल रहा है।
    • यदि आपके आवेदन के लिए लागू हो तो क्वेरी कैशिंग का लाभ उठाएं।
    http://anothermysqldba.blogspot.com/2018/05/proxy-mysql-haproxy-proxysql-keepalived.html