एक और MySQL DBA: 2019

शुक्रवार, 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

https://dev.mysql.com/doc/refman/8.0/en/group-replication-adding-instances.html

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

https://dev.mysql.com/doc/refman/8.0/en/group-replication-adding-instances.html

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;

+ --------------------------- + --------------------- ----------------- + ------------- + ------------- + ---- ---------- + ------------- + ---------------- +

+ --------------------------- + --------------------- ----------------- + ------------- + ------------- + ---- ---------- + ------------- + ---------------- +

+ --------------------------- + --------------------- ----------------- + ------------- + ------------- + ---- ---------- + ------------- + ---------------- +

सेट में 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 में यहां वापस नोट किया गया था

https://codepoets.co.uk/2015/mysql-max_connections-stuck-on-214/

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

# 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 ठीक चल रहा था और होगा।

Pages

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

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

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

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

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

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

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

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

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

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

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