欧美97色伦欧美一区二区日韩,国产福利片在线观看,freexxx性欧美vide0高清,西西亚洲,日本欧美国产精品第一页久久,成人18免费软件

當(dāng)前位置： 維易PHP培訓(xùn)學(xué)院 > MYSQL教程 > 內(nèi)容正文

Mysql必讀MySQL 5.6 GTID新特性實(shí)踐

作者：VEPHP   時(shí)間 2017-09-17

《Mysql必讀MySQL 5.6 GTID新特性實(shí)踐》要點(diǎn)：
本文介紹了Mysql必讀MySQL 5.6 GTID新特性實(shí)踐，希望對(duì)您有用。如果有疑問(wèn)，可以聯(lián)系我們。

MYSQL實(shí)例GTID簡(jiǎn)介

MYSQL實(shí)例什么是GTID

MYSQL實(shí)例GTID(Global Transaction ID)是對(duì)于一個(gè)已提交事務(wù)的編號(hào),并且是一個(gè)全局唯一的編號(hào).

MYSQL實(shí)例GTID實(shí)際上是由UUID+TID組成的.其中UUID是一個(gè)MySQL實(shí)例的唯一標(biāo)識(shí).TID代表了該實(shí)例上已經(jīng)提交的事務(wù)數(shù)量,并且隨著事務(wù)提交單調(diào)遞增.下面是一個(gè)GTID的具體形式

MYSQL實(shí)例3E11FA47-71CA-11E1-9E33-C80AA9429562:23

MYSQL實(shí)例更詳細(xì)的介紹可以參見(jiàn)：官方文檔

MYSQL實(shí)例GTID的作用

MYSQL實(shí)例那么GTID功能的目的是什么呢?具體歸納主要有以下兩點(diǎn)：

MYSQL實(shí)例根據(jù)GTID可以知道事務(wù)最初是在哪個(gè)實(shí)例上提交的GTID的存在方便了Replication的Failover 這里詳細(xì)解釋下第二點(diǎn).我們可以看下在MySQL 5.6的GTID出現(xiàn)以前replication failover的操作過(guò)程.假設(shè)我們有一個(gè)如下圖的環(huán)境

MYSQL實(shí)例Mysql必讀MySQL 5.6 GTID新特性實(shí)踐

MYSQL實(shí)例此時(shí),Server A的服務(wù)器宕機(jī),需要將業(yè)務(wù)切換到Server B上.同時(shí),我們又需要將Server C的復(fù)制源改成Server B.復(fù)制源修改的命令語(yǔ)法很簡(jiǎn)單即CHANGE MASTER TO MASTER_HOST='xxx', MASTER_LOG_FILE='xxx', MASTER_LOG_POS=nnnn.而難點(diǎn)在于,由于同一個(gè)事務(wù)在每臺(tái)機(jī)器上所在的binlog名字和位置都不一樣,那么怎么找到Server C當(dāng)前同步停止點(diǎn),對(duì)應(yīng)Server B的master_log_file和master_log_pos是什么的時(shí)候就成為了難題.這也就是為什么M-S復(fù)制集群需要使用MMM,MHA這樣的額外管理工具的一個(gè)重要原因.

MYSQL實(shí)例這個(gè)問(wèn)題在5.6的GTID出現(xiàn)后,就顯得非常的簡(jiǎn)單.由于同一事務(wù)的GTID在所有節(jié)點(diǎn)上的值一致,那么根據(jù)Server C當(dāng)前停止點(diǎn)的GTID就能唯一定位到Server B上的GTID.甚至由于MASTER_AUTO_POSITION功能的出現(xiàn),我們都不需要知道GTID的具體值,直接使用CHANGE MASTER TO MASTER_HOST='xxx', MASTER_AUTO_POSITION命令就可以直接完成failover的工作. So easy不是么?

MYSQL實(shí)例基于GTID的主從復(fù)制簡(jiǎn)介

MYSQL實(shí)例搭建

MYSQL實(shí)例搭建使用了mysql_sandbox腳本為基礎(chǔ),先創(chuàng)建了一個(gè)一主三從的基于位置復(fù)制的環(huán)境.然后通過(guò)配置修改,將整個(gè)架構(gòu)專(zhuān)為基于GTID的復(fù)制.

MYSQL實(shí)例根據(jù)MySQL官方文檔給出的GTID搭建建議.需要一次對(duì)主從節(jié)點(diǎn)做配置修改,并重啟服務(wù).這樣的操作,顯然在production環(huán)境進(jìn)行升級(jí)時(shí)是不可接受的.Facebook,Booking.com,Percona都對(duì)此通過(guò)patch做了優(yōu)化,做到了更優(yōu)雅的升級(jí).具體的操作方式會(huì)在以后的博文當(dāng)中介紹到.這里我們就按照官方文檔,進(jìn)行一次實(shí)驗(yàn)性的升級(jí).

MYSQL實(shí)例主要的升級(jí)步驟會(huì)有以下幾步：

MYSQL實(shí)例確保主從同步在master上配置read_only,保證沒(méi)有新數(shù)據(jù)寫(xiě)入修改master上的my.cnf,并重啟服務(wù)修改slave上的my.cnf,并重啟服務(wù)在slave上執(zhí)行change master to并帶上master_auto_position=1啟用基于GTID的復(fù)制由于是實(shí)驗(yàn)環(huán)境,read_only和服務(wù)重啟并無(wú)大礙.只要按照官方的GTID搭建建議做就能順利完成升級(jí),這里就不贅述詳細(xì)過(guò)程了.下面列舉了一些在升級(jí)過(guò)程中容易遇到的錯(cuò)誤.

MYSQL實(shí)例常見(jiàn)錯(cuò)誤

MYSQL實(shí)例gtid_mode=ON,log_slave_updates,enforce_gtid_consistency這三個(gè)參數(shù)一定要同時(shí)在my.cnf中配置.否則在mysql.err中會(huì)出現(xiàn)如下的報(bào)錯(cuò)

MYSQL實(shí)例2016-10-08 20:11:08 32147 [ERROR] --gtid-mode=ON or UPGRADE_STEP_1 or UPGRADE_STEP_2 requires --log-bin and --log-slave-updates
2016-10-08 20:13:53 32570 [ERROR] --gtid-mode=ON or UPGRADE_STEP_1 requires --enforce-gtid-consistency

MYSQL實(shí)例change master to 后的warnings

MYSQL實(shí)例在按照文檔的操作change master to后,會(huì)發(fā)現(xiàn)有兩個(gè)warnings.其實(shí)是兩個(gè)安全性警告,不影響正常的同步(有興趣的讀者可以看下關(guān)于該warning的具體介紹.warning的具體內(nèi)容如下：

MYSQL實(shí)例
slave1 [localhost] {msandbox} ((none)) > stop slave;
Query OK, 0 rows affected (0.03 sec)
slave1 [localhost] {msandbox} ((none)) > change master to master_host='127.0.0.1',master_port =21288,master_user='rsandbox',master_password='rsandbox',master_auto_position=1;
Query OK, 0 rows affected, 2 warnings (0.04 sec)
slave1 [localhost] {msandbox} ((none)) > show warnings;
+-------+------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Level | Code | Message |
+-------+------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Note | 1759 | Sending passwords in plain text without SSL/TLS is extremely insecure. |
| Note | 1760 | Storing MySQL user name or password information in the master info repository is not secure and is therefore not recommended. Please consider using the USER and PASSWORD connection options for START SLAVE; see the 'START SLAVE Syntax' in the MySQL Manual for more information. |
+-------+------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
2 rows in set (0.00 sec)

MYSQL實(shí)例實(shí)驗(yàn)一：如果slave所需要事務(wù)對(duì)應(yīng)的GTID在master上已經(jīng)被purge了

MYSQL實(shí)例根據(jù)show global variables like '%gtid%'的命令結(jié)果我們可以看到,和GTID相關(guān)的變量中有一個(gè)gtid_purged.從字面意思以及官方文檔可以知道該變量中記錄的是本機(jī)上已經(jīng)執(zhí)行過(guò),但是已經(jīng)被purge binary logs to命令清理的gtid_set.
本節(jié)中我們就要試驗(yàn)下,如果master上把某些slave還沒(méi)有fetch到的gtid event purge后會(huì)有什么樣的結(jié)果.

MYSQL實(shí)例以下指令在master上執(zhí)行

MYSQL實(shí)例
master [localhost] {msandbox} (test) > show global variables like '%gtid%';
+---------------------------------+----------------------------------------+
| Variable_name | Value |
+---------------------------------+----------------------------------------+
| binlog_gtid_simple_recovery | OFF |
| enforce_gtid_consistency | ON |
| gtid_executed | 24024e52-bd95-11e4-9c6d-926853670d0b:1 |
| gtid_mode | ON |
| gtid_owned | |
| gtid_purged | |
| simplified_binlog_gtid_recovery | OFF |
+---------------------------------+----------------------------------------+
7 rows in set (0.01 sec)
master [localhost] {msandbox} (test) > flush logs;create table gtid_test2 (ID int) engine=innodb;
Query OK, 0 rows affected (0.04 sec)
Query OK, 0 rows affected (0.02 sec)
master [localhost] {msandbox} (test) > flush logs;create table gtid_test3 (ID int) engine=innodb;
Query OK, 0 rows affected (0.04 sec)
Query OK, 0 rows affected (0.04 sec)
master [localhost] {msandbox} (test) > show master status;
+------------------+----------+--------------+------------------+------------------------------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+------------------------------------------+
| mysql-bin.000005 | 359 | | | 24024e52-bd95-11e4-9c6d-926853670d0b:1-3 |
+------------------+----------+--------------+------------------+------------------------------------------+
1 row in set (0.00 sec)
master [localhost] {msandbox} (test) > purge binary logs to 'mysql-bin.000004';
Query OK, 0 rows affected (0.03 sec)
master [localhost] {msandbox} (test) > show global variables like '%gtid%';
+---------------------------------+------------------------------------------+
| Variable_name | Value |
+---------------------------------+------------------------------------------+
| binlog_gtid_simple_recovery | OFF |
| enforce_gtid_consistency | ON |
| gtid_executed | 24024e52-bd95-11e4-9c6d-926853670d0b:1-3 |
| gtid_mode | ON |
| gtid_owned | |
| gtid_purged | 24024e52-bd95-11e4-9c6d-926853670d0b:1 |
| simplified_binlog_gtid_recovery | OFF |
+---------------------------------+------------------------------------------+
7 rows in set (0.00 sec)

MYSQL實(shí)例在slave2上重新做一次主從,以下命令在slave2上執(zhí)行

MYSQL實(shí)例
slave2 [localhost] {msandbox} ((none)) > change master to master_host='127.0.0.1',master_port =21288,master_user='rsandbox',master_password='rsandbox',master_auto_position=1;
Query OK, 0 rows affected, 2 warnings (0.04 sec)
slave2 [localhost] {msandbox} ((none)) > start slave;
Query OK, 0 rows affected (0.01 sec)
slave2 [localhost] {msandbox} ((none)) > show slave status\G
*************************** 1. row ***************************
......
Slave_IO_Running: No
Slave_SQL_Running: Yes
......
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 0
Relay_Log_Space: 151
......
Last_IO_Errno: 1236
Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires.'
Last_SQL_Errno: 0
Last_SQL_Error:
......
Auto_Position: 1
1 row in set (0.00 sec)

MYSQL實(shí)例實(shí)驗(yàn)二：忽略purged的部分,強(qiáng)行同步

MYSQL實(shí)例那么實(shí)際生產(chǎn)應(yīng)用當(dāng)中,偶爾會(huì)遇到這樣的情況：某個(gè)slave從備份恢復(fù)后(或者load data infile)后,DBA可以人為保證該slave數(shù)據(jù)和master一致；或者即使不一致,這些差異也不會(huì)導(dǎo)致今后的主從異常(例如：所有master上只有insert沒(méi)有update).這樣的前提下,我們又想使slave通過(guò)replication從master進(jìn)行數(shù)據(jù)復(fù)制.此時(shí)我們就需要跳過(guò)master已經(jīng)被purge的部分,那么實(shí)際該如何操作呢?

MYSQL實(shí)例我們還是以實(shí)驗(yàn)一的情況為例：

MYSQL實(shí)例先確認(rèn)master上已經(jīng)purge的部分.從下面的命令結(jié)果可以知道m(xù)aster上已經(jīng)缺失24024e52-bd95-11e4-9c6d-926853670d0b:1這一條事務(wù)的相關(guān)日志

MYSQL實(shí)例
master [localhost] {msandbox} (test) > show global variables like '%gtid%';
+---------------------------------+------------------------------------------+
| Variable_name | Value |
+---------------------------------+------------------------------------------+
| binlog_gtid_simple_recovery | OFF |
| enforce_gtid_consistency | ON |
| gtid_executed | 24024e52-bd95-11e4-9c6d-926853670d0b:1-3 |
| gtid_mode | ON |
| gtid_owned | |
| gtid_purged | 24024e52-bd95-11e4-9c6d-926853670d0b:1 |
| simplified_binlog_gtid_recovery | OFF |
+---------------------------------+------------------------------------------+
7 rows in set (0.00 sec)

MYSQL實(shí)例在slave上通過(guò)set global gtid_purged='xxxx'的方式,跳過(guò)已經(jīng)purge的部分

MYSQL實(shí)例
slave2 [localhost] {msandbox} ((none)) > stop slave;
Query OK, 0 rows affected (0.04 sec)
slave2 [localhost] {msandbox} ((none)) > set global gtid_purged = '24024e52-bd95-11e4-9c6d-926853670d0b:1';
Query OK, 0 rows affected (0.05 sec)
slave2 [localhost] {msandbox} ((none)) > start slave;
Query OK, 0 rows affected (0.01 sec)
slave2 [localhost] {msandbox} ((none)) > show slave status\G 
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
......
Master_Log_File: mysql-bin.000005
Read_Master_Log_Pos: 359
Relay_Log_File: mysql_sandbox21290-relay-bin.000004
Relay_Log_Pos: 569
Relay_Master_Log_File: mysql-bin.000005
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
......
Exec_Master_Log_Pos: 359
Relay_Log_Space: 873
......
Master_Server_Id: 1
Master_UUID: 24024e52-bd95-11e4-9c6d-926853670d0b
Master_Info_File: /data/mysql/rsandbox_mysql-5_6_23/node2/data/master.info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update it
......
Retrieved_Gtid_Set: 24024e52-bd95-11e4-9c6d-926853670d0b:2-3
Executed_Gtid_Set: 24024e52-bd95-11e4-9c6d-926853670d0b:1-3
Auto_Position: 1
1 row in set (0.00 sec)

MYSQL實(shí)例可以看到此時(shí)slave已經(jīng)可以正常同步,并補(bǔ)齊了24024e52-bd95-11e4-9c6d-926853670d0b:2-3范圍的binlog日志.

MYSQL實(shí)例以上所述是小編給大家介紹的MySQL 5.6 GTID新特性實(shí)踐,希望對(duì)大家有所幫助,如果大家有任何疑問(wèn)請(qǐng)給我留言,小編會(huì)及時(shí)回復(fù)大家的.在此也非常感謝大家對(duì)維易PHP網(wǎng)站的支持!

轉(zhuǎn)載請(qǐng)注明本頁(yè)網(wǎng)址：
http://www.snjht.com/jiaocheng/1678.html


    標(biāo)簽：