2019年7月13日星期六

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


OK只使用了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多歲......

當然,自動化它,並使用您的information_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,從備份恢復,然後應用binlogs進行最近的更改。

為了使它更有趣,他們沒有我被告知的所有ibd文件,我確實看到一些丟失。 所以不確定這是怎麼可能的,但是選項2變成了無效選項。 當然,他們希望盡可能減少數據丟失,因此我們選擇了3。

為了安全地做到這一點,我在端口3307下啟動了另一個MySQL實例。這使我有了一個安全的工作場所,同時流量對端口3306實例上的MyISAM數據具有讀訪問權限。

一旦所有備份轉儲文件解壓縮並導入3307實例,我就可以專注於binlog文件。

起初,這個概念聽起來比實際風險要大得多。 它實際上很簡單直接。

首先,您必須找到您之後的數據。 通過查看binlog文件,您可以了解哪些文件是相關的。 在我的情況下,他們設法重置了binlog,因此117文件中有2個日期範圍。

首先對於binlog審查,以下命令以人類可讀的格式輸出數據。
mysqlbinlog --defaults-file=/root/.my.cnf --base64-output=DECODE-ROWS --verbose mysql-bin.000117 > review_mysql-bin.000117.sql

*注意......小心運行上面的命令。 請注意,我將文件直接轉儲到binlog所在的位置。 因此,確認您的文件名有效。 這個mysql-bin.000117.sql與這個mysql-bin.000117 .sql不同。 您將使用第二個選項和.sql之前的空格來丟失binlog。

現在保存數據,以便可以應用它。 由於我有幾個binlogs,我創建了一個文件,我想要仔細檢查時間範圍。


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"

現在我將這些binlog中的所有數據應用於給定的時間範圍。 客戶端仔細檢查了所有數據,並非常高興能夠全部恢復。

對於這種情況存在幾種不同的選擇,這恰好與客戶一起鍛煉。

一旦驗證的all在恢復的版本上沒問題,它就是一個簡單的停止兩個數據庫,移動數據目錄(想要保持datadir默認完整),chown目錄只是為了安全並啟動MySQL。 現在,已恢復的實例已在端口3306上啟動。

2019年6月17日星期一

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)
- 然後從Change master命令重新開始
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
如果您寫入無主節點,您當然會收到錯誤。


group-replication-single-primary-mode = off < - 添加到cnf文件中。
mysql> SELECT * FROM performance_schema.replication_group_members;
+ --------------------------- + --------------------- ----------------- + ------------- ------------- + + ---- ---------- + ------------- + ---------------- +
| CHANNEL_NAME               | 會員ID                             | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION |
+ --------------------------- + --------------------- ----------------- + ------------- ------------- + + ---- ---------- + ------------- + ---------------- +
| group_replication_applier | 1ab30239-5ef6-11e9-9b4a-08002712f4b1 | centosa     |         3306 | RECOVERING   |     | 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 | RECOVERING   |     | 8.0.15         |
+ --------------------------- + --------------------- ----------------- + ------------- ------------- + + ---- ---------- + ------------- + ---------------- +

3組(0.00秒)


現在,如果您使用Keepalived,MySQL路由器,ProxySQL等來處理您的流量,以便在發生故障轉移時自動翻轉。 當我停止主要時,我們可以從下面看到它立即失敗了。

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%銷售,因為我仍然傾向於Galera複製。

感興趣的URL


  • 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/
  • 2019年6月4日星期二

    Max_connections 214 4.15.0-46-generic#49-Ubuntu

    因此,max_connections從my.cnf文件中設置的值下降到214的問題在Ubuntu上已經存在了一段時間。

    作為一個例子,它在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文件中的給定參數處穩定。

    2019年4月15日星期一

    簡單的KeepaliveD設置

    因此,keepalived已經存在了很長一段時間......但是對許多人來說這仍然是一個謎。
    所以這是一個非常簡單的例子,說明keepalived如何與MySQL一起工作。 希望這可以幫助那些有疑問的人。

    我們將有一個簡單的主設備到奴隸設置。 意思是..我們寫一個,除非我們故障轉移到第二個事件。

    1 - 安裝keepalived


    #yum搜索keepalived
    keepalived .x86_64:負載均衡器和高可用性服務

      僅限名稱和摘要匹配,對所有內容使用“全部搜索”。
    #yum -y install keepalived

    你現在應該有一個配置文件

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

    保留原件,因為你總是備份..右....
    #cp /etc/keepalived/keepalived.conf /etc/keepalived/keepalived.conf.orig

    因此,您需要找出可用於虛擬IP的ipaddress。 我為這個例子選擇了192.168.0.123。

    接下來,我們將設置一個腳本用於我們的新配置文件。

    我在這裡做的一些事情......
    我在/ etc / keepalived中留下了一個.cnf文件,用於keepalived和一個日誌。
    這使得示例變得簡單,因此您可以執行此操作或使用您自己的cnf文件。

    一個腳本:

    cat /etc/keepalived/keepalived_check.sh  
    #!/斌/慶典

    #monitor mysql status

    #如果這個節點mysql死了

    #並且它的奴隸還活著,然後停止它的keepalived。 另一個節點將綁定IP。



    export MYSQL_HOME = / etc / keepalived /

    export PATH = $ MYSQL_HOME / bin:$ PATH



    的MySQL =“/ USR / bin中/ MySQL的”

    中mysqladmin =“的/ usr /斌/中mysqladmin”

    delay_file =“$ MYSQL_HOME / slave_delay_second.log”

    slave_host = $ 1





    ALIVE = $($ mysqladmin --defaults-file = $ MYSQL_HOME / .my.localhost.cnf   ping | grep alive | wc -l);

    REMOTEALIVE = $($ mysqladmin --defaults-file = $ MYSQL_HOME / .my.remotehost.cnf   ping | grep alive | wc -l);



    如果[[$ ALIVE -ne 1]]

    然後

    #echo“MySQL已關閉”

            如果[[$ REMOTEALIVE -eq 1]]

            然後

            迴聲“關機保持活力”

                systemctl停止keepalived  

          echo“keepalived stop”

            科幻

    #其他

    #echo“MySQL正在上升”

    #日期

    科幻



    退出0 #all done

    新的配置文件

    cat /etc/keepalived/keepalived.conf
    global_defs {



          notification_email {

            anothermysqldba@gmail.com  

          }



          notification_email_from anothermysqldba@gmail.com  

          smtp_server localhost

          smtp_connect_timeout 30



          }







    vrrp_script check_mysql {

       腳本“/etc/keepalived/keepalived_check.sh”

       間隔2

       重量2

    }







    vrrp_instance VI_1 {



          國家MASTER

          接口enp0s8   #<---什麼界面名稱包含您的真實IP / sbin / ifconfig

            #在ip link show中找到

          virtual_router_id 51

          優先級101

          advert_int 1

          nopreempt不同   #僅在較高優先級節點上需要

          認證{

            auth_type PASS

            auth_pass 1111

          }





          track_script {

            check_mysql

          }



          virtual_ipaddress {

            192.168.0.123  

          }




    }



    這一切都很棒但是有效嗎......

    所以我們有2個主機

    [root @ centosa keepalived] #hostname

    centosa

    [root @ centosb keepalived] #hostname
    centosb

    啟動keepalived

    [root @ centosa keepalived] #systemctl status keepalived
    ●keepalived.service - LVS和VRRP高可用性監視器
       已加載:已加載(/usr/lib/systemd/system/keepalived.service;已禁用;供應商預設:已禁用)
       活動:不活動(死機)
    [root @ centosa keepalived] #systemctl restart keepalived
    [root @ centosa keepalived] #systemctl status keepalived
    keepalived.service - LVS和VRRP高可用性監視器
       已加載:已加載(/usr/lib/systemd/system/keepalived.service;已禁用;供應商預設:已禁用)
        活動: 活動(運行)

    [root @ centosa keepalived] #ssh 192.168.0.123'hostname'
    root@192.168.0.123的密碼:  

    centosa

    證明連接工作已經完成

    [root @ centosa keepalived] #mysql --defaults-file = .my.remotehost.cnf --host = 192.168.0.101   -e“select @@ hostname”
    + ------------ +
    | @@ hostname |
    + ------------ +
    | centosb     |
    + ------------ +
    [root @ centosa keepalived] #mysql --defaults-file = .my.remotehost.cnf --host = 192.168.0.102   -e“select @@ hostname”
    + ------------ +
    | @@ hostname |
    + ------------ +
    | centosa     |
    + ------------ +

    仔細檢查它是否正在運行......

    [root @ centosa keepalived] #systemctl status keepalived | grep活躍
        活動: 活躍  

    [root @ centosb keepalived] #systemctl status keepalived | grep活躍
        活動: 活躍  

    測試當前VIP ..停止mysql並觀看相同的VIP更改主機...

    [root @ centosa keepalived] #mysql --defaults-file = .my.remotehost.cnf --host = 192.168.0.123   -e“select @@ hostname”
    + ------------ +
    | @@ hostname |
    + ------------ +
    | centosa     |
    + ------------ +
    [root @ centosa keepalived] #systemctl stop mysqld  
    [root @ centosa keepalived] #mysql --defaults-file = .my.remotehost.cnf --host = 192.168.0.123   -e“select @@ hostname”
    + ------------ +
    | @@ hostname |
    + ------------ +
    | centosb     |
    + ------------ +

    2019年4月10日星期三

    有時慢速數據庫..不是數據庫......

    所以我最近被要求調查為什麼更新的MySQL 5 .6比舊的5.5慢

    所以我開始尋找標準變量和緩存等等。

    測試用例是一個簡單的例程,在5.6上運行的時間比在5.5上運行時長兩倍。

    添加到混合.. 5.6版本有兩倍Innodb_buffer_pool_size,當然更多ram整體。

    所以我用MySQLslap開始了一些測試......

    Mysqlslap測試顯示它在5.6上較慢

    5.6:
    mysqlslap --defaults-file =。/。my.cnf --concurrency = 150 --iterations = 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 --iterations = 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 GB),25.7401 s,83.4 MB / s

    #dd if = test of = / dev / null bs = 1048576
    2048 + 0條記錄
    2048 + 0記錄了
    複製2147483648字節(2.1 GB),29.1527 s,73.7 MB / s

    5.5:
    #dd if = / dev / zero of = test bs = 1048576 count = 2048
    2048 + 0條記錄
    2048 + 0記錄了
    複製2147483648字節(2.1 GB),19.9214秒,108 MB / s

    #dd if = test of = / dev / null bs = 1048576
    2048 + 0條記錄
    2048 + 0記錄了
    複製2147483648字節(2.1 GB),20.0243秒,107 MB / s



    無論MySQL如何,5.5的磁盤都比較慢。 所以在這種情況下....看看修復磁盤速度.. MySQL運行正常,並將。