MySQL主從複製之GTID複製
MySQL主從複製之GTID複製
原文： https://www.cnblogs.com/hmwh/p/9198705.html
GTID複製又叫全域性事物ID（global transaction ID），是一個已提交事物的編號，並且是一個全域性唯一的編號，MYSQL5.6版本之後在主從複製型別上新增了GTID複製。
GTID是由server_uuid和事物id組成的，即GTID=servier_uuid:transacton_id。Server_uuid是在資料庫啟動過程中自動生成的，每臺機器的server-uuid不一樣。UUID存放在資料目錄的auto.cnf檔案下。而trasaciton_id就是事物提交時由系統順序分配的一個不會重複的序列號。
3.1GTID存在的價值
1、GTID使用master_auto_position=1 代替了基於binlog和position號的主從複製搭建的方式，更便於主從複製的搭建。
2、GTID可以知道事務在最開始是在哪個例項上提交的。
3、GTID方便實現主從之間的failover，再也不用不斷的去找position和binlog。
3.2GTID搭建模式
GTID不需要傳統的binlog和position號了，而是在從庫”change master to”時使用”master_auto_position=1”的方式搭建，這就讓操作變得更加方便和可靠了。
3.3配置前期準備
在安裝好主從資料庫之後：
主庫需要以下配置：
gtid_mode=on
enforce_gtid_consistency=on
log_bin=on
從庫需要以下配置：
servier-id 主從庫不能一樣。
gtid_mode=on
enforce_gtid_consistency=on
log_slave_updates=1
主庫操作：
建立主從複製賬號
create user 'rep'@'192.16.20.%' identified by 'mysql';
grant replication slave on *.* to 'rep'@'172.16.20.%';
show grants for 'rep'@'172.16.20.%';
如果不同網段建議主從各建各的。
初始化：
/usr/local/mysql5.7/bin/mysqldump -S /tmp/mysql3307.sock --single-transaction -uroot -pmysql --master-data=2 -A > slave.sql（我全庫匯入的有問題,換成絕對路徑就行，只用的test庫）
注意：必須加引數 –master-data=2,讓備份出來的檔案中記錄備份這一刻binlog檔案與position號，為搭建主從環境做準備。檢視備份檔案中記錄的當前binlog檔案和position號。
scp salve.sql 172.16.20.21:/binlogbak
test庫操作：
mysqldump -S /tmp/mysql3307.sock --single-transaction -uroot -pmysql --master-data=2 --database test > slave_test.sql
注意，如果主從GTI不一樣，資料一致可以：
set global gtid_purged='*******';
如果資料不一樣，GTID也不一樣，建議按照下面先reset從庫:reset master;
mysql -S /tmp/mysql3307.sock -uroot -pmysql < slave_test.sql
注意：多次恢復會報錯，因為裡面已經有gtid的資訊了。
如果你還想繼續強制恢復，可以在從庫上 reset master ;reset後，gtid_executed，gtid_purged為空。
show global variables like '%gtid%';
3.4主從配置
1、如果是在已經跑的伺服器，你需要重啟一下mysql server。
2、啟動之前，一定要先關閉master的寫入，保證所有slave端都已經和master端資料保持同步。
3、所有slave需要加上skip_slave_start=1的配置引數，避免啟動後還是使用老的複製協議。
在資料庫命令列執行配置主從命令。
change master to master_host='172.16.20.32',master_port=3307,master_user='rep',master_password='mysql',master_auto_position=1;
提示：master_log_file='mysql-binlog.000010',MASTER_LOG_POS=797 這兩個引數替換成了 master_auto_position=1
show slave status\G;
start slave;
stop slave;
reset slave all; 清空從庫的所有配置資訊。
start slave;
一般複製建議半同步+GTID 複製：
附帶主從引數：
主：
[root@mysql5 ~]# cat /etc/my3307.cnf
[client]
port = 3307
socket = /tmp/mysql5.7.sock
[mysql]
prompt="\u@db \R:\m:\s [\d]> "
no-auto-rehash
[mysqld]
user = mysql
port = 3307
basedir = /usr/local/mysql5.7
datadir = /mydata/mysql/mysql3307/data
socket = /tmp/mysql3307.sock
rpl_semi_sync_master_enabled=1
rpl_semi_sync_master_timeout=1000
event_scheduler=1
sql_mode=STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION
lower_case_table_names=1
secure_file_priv=/tmp
character-set-server = utf8mb4
skip_name_resolve = 1
open_files_limit = 65535
back_log = 1024
max_connections = 500
max_connect_errors = 1000000
table_open_cache = 1024
table_definition_cache = 1024
table_open_cache_instances = 64
thread_stack = 512K
external-locking = FALSE
max_allowed_packet = 32M
sort_buffer_size = 4M
join_buffer_size = 4M
thread_cache_size = 768
query_cache_size = 0
query_cache_type = 0
interactive_timeout = 600
wait_timeout = 600
tmp_table_size = 32M
max_heap_table_size = 32M
slow_query_log = 1
slow_query_log_file = /mydata/mysql/mysql3307/logs/slow.log
log-error = /mydata/mysql/mysql3307/logs/error.log
long_query_time = 0.5
server-id = 3307101
log-bin = /mydata/mysql/mysql3307/logs/mysql-binlog
sync_binlog = 1
binlog_cache_size = 4M
max_binlog_cache_size = 1G
max_binlog_size = 500M
expire_logs_days = 7
master_info_repository = TABLE
relay_log_info_repository = TABLE
gtid_mode = on
enforce_gtid_consistency = 1
log_slave_updates
binlog_format = row
relay_log_recovery = 1
relay-log-purge = 1
key_buffer_size = 32M
read_buffer_size = 8M
read_rnd_buffer_size = 4M
bulk_insert_buffer_size = 64M
lock_wait_timeout = 3600
explicit_defaults_for_timestamp = 1
innodb_thread_concurrency = 0
innodb_sync_spin_loops = 100
innodb_spin_wait_delay = 30
transaction_isolation = REPEATABLE-READ
innodb_buffer_pool_size = 1024M
innodb_buffer_pool_instances = 8
innodb_buffer_pool_load_at_startup = 1
innodb_buffer_pool_dump_at_shutdown = 1
innodb_data_file_path = ibdata1:1G:autoextend
innodb_flush_log_at_trx_commit = 1
innodb_log_buffer_size = 32M
innodb_log_file_size = 2G
innodb_log_files_in_group = 2
innodb_max_undo_log_size = 4G
innodb_io_capacity = 2000
innodb_io_capacity_max = 4000
innodb_flush_neighbors = 0
innodb_write_io_threads = 8
innodb_read_io_threads = 8
innodb_purge_threads = 4
innodb_page_cleaners = 4
innodb_open_files = 65535
innodb_max_dirty_pages_pct = 50
innodb_flush_method = O_DIRECT
innodb_lru_scan_depth = 4000
innodb_checksum_algorithm = crc32
innodb_lock_wait_timeout = 10
innodb_rollback_on_timeout = 1
innodb_print_all_deadlocks = 1
innodb_file_per_table = 1
innodb_online_alter_log_max_size = 500M
internal_tmp_disk_storage_engine = InnoDB
innodb_stats_on_metadata = 0
innodb_status_file = 1
innodb_status_output = 0
innodb_status_output_locks = 0
#performance_schema
performance_schema = 1
performance_schema_instrument = '%=on'
#innodb monitor
innodb_monitor_enable="module_innodb"
innodb_monitor_enable="module_server"
innodb_monitor_enable="module_dml"
innodb_monitor_enable="module_ddl"
innodb_monitor_enable="module_trx"
innodb_monitor_enable="module_os"
innodb_monitor_enable="module_purge"
innodb_monitor_enable="module_log"
innodb_monitor_enable="module_lock"
innodb_monitor_enable="module_buffer"
innodb_monitor_enable="module_index"
innodb_monitor_enable="module_ibuf_system"
innodb_monitor_enable="module_buffer_page"
innodb_monitor_enable="module_adaptive_hash"
[mysqldump]
quick
max_allowed_packet = 32M
從：
[root@rac1 ~]# cat /etc/my3307.cnf
[client]
port = 3307
socket = /tmp/mysql5.7.sock
[mysql]
prompt="\u@db \R:\m:\s [\d]> "
no-auto-rehash
[mysqld]
user = mysql
port = 3307
basedir = /usr/local/mysql5.7
datadir = /mydata/mysql/mysql3307/data
socket = /tmp/mysql3307.sock
character-set-server = utf8mb4
lower_case_table_names=1
sql_mode=STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION
rpl_semi_sync_slave_enabled=1
skip_name_resolve = 1
open_files_limit = 65535
back_log = 1024
max_connections = 500
max_connect_errors = 1000000
table_open_cache = 1024
table_definition_cache = 1024
table_open_cache_instances = 64
thread_stack = 512K
external-locking = FALSE
max_allowed_packet = 32M
sort_buffer_size = 4M
join_buffer_size = 4M
thread_cache_size = 768
query_cache_size = 0
query_cache_type = 0
interactive_timeout = 600
wait_timeout = 600
tmp_table_size = 32M
max_heap_table_size = 32M
slow_query_log = 1
slow_query_log_file = /mydata/mysql/mysql3307/logs/slow.log
log-error = /mydata/mysql/mysql3307/logs/error.log
long_query_time = 0.1
server-id = 3307102
log-bin = /mydata/mysql/mysql3307/logs/mysql-binlog
sync_binlog = 1
binlog_cache_size = 4M
max_binlog_cache_size = 500m
max_binlog_size = 200m
expire_logs_days = 7
master_info_repository = TABLE
relay_log_info_repository = TABLE
gtid_mode = on
enforce_gtid_consistency = 1
log_slave_updates
binlog_format = row
relay_log_recovery = 1
relay-log-purge = 1
key_buffer_size = 32M
read_buffer_size = 8M
read_rnd_buffer_size = 4M
bulk_insert_buffer_size = 64M
lock_wait_timeout = 3600
explicit_defaults_for_timestamp = 1
innodb_thread_concurrency = 0
innodb_sync_spin_loops = 100
innodb_spin_wait_delay = 30
transaction_isolation = REPEATABLE-READ
innodb_buffer_pool_size = 1024M
innodb_buffer_pool_instances = 8
innodb_buffer_pool_load_at_startup = 1
innodb_buffer_pool_dump_at_shutdown = 1
innodb_data_file_path = ibdata1:1G:autoextend
innodb_flush_log_at_trx_commit = 1
innodb_log_buffer_size = 32M
innodb_log_file_size = 1g
innodb_log_files_in_group = 2
innodb_max_undo_log_size = 1G
innodb_io_capacity = 2000
innodb_io_capacity_max = 4000
innodb_flush_neighbors = 0
innodb_write_io_threads = 8
innodb_read_io_threads = 8
innodb_purge_threads = 4
innodb_page_cleaners = 4
innodb_open_files = 65535
innodb_max_dirty_pages_pct = 50
innodb_flush_method = O_DIRECT
innodb_lru_scan_depth = 4000
innodb_checksum_algorithm = crc32
innodb_lock_wait_timeout = 10
innodb_rollback_on_timeout = 1
innodb_print_all_deadlocks = 1
innodb_file_per_table = 1
innodb_online_alter_log_max_size = 4G
internal_tmp_disk_storage_engine = InnoDB
innodb_stats_on_metadata = 0
innodb_status_file = 1
innodb_status_output = 0
innodb_status_output_locks = 0
performance_schema = 1
performance_schema_instrument = '%=on'
#innodb monitor
innodb_monitor_enable="module_innodb"
innodb_monitor_enable="module_server"
innodb_monitor_enable="module_dml"
innodb_monitor_enable="module_ddl"
innodb_monitor_enable="module_trx"
innodb_monitor_enable="module_os"
innodb_monitor_enable="module_purge"
innodb_monitor_enable="module_log"
innodb_monitor_enable="module_lock"
innodb_monitor_enable="module_buffer"
innodb_monitor_enable="module_index"
innodb_monitor_enable="module_ibuf_system"
innodb_monitor_enable="module_buffer_page"
innodb_monitor_enable="module_adaptive_hash"
[mysqldump]
quick
max_allowed_packet = 32M
4、GTID複製與傳統複製的切換
主：172.16.20.32
從：172.16.10.21
a) GTID切換成傳統複製
從庫資訊：
show slave status\G;
主庫：
從庫切換操作：
stop slave;
change master to master_auto_position=0,master_host='172.16.20.32', master_port=3307,master_user='rep',master_password='mysql',Master_Log_File='mysql-binlog.000007',Master_Log_Pos=194;
start slave;
主從資料庫伺服器上 同時，依次執行以下操作：
set global gtid_mode='on_permissive';
set global gtid_mode='off_permissive';
主從關閉GTID功能：
set global enforce_gtid_consistency=off;
set global gtid_mode=off;
把gtid_mode=off和enforce_gtid_consistency=off寫入配置檔案my3307.cnf中。重啟後可以繼續生效，並進行測試。
b) 傳統複製切換成GTID過程
主從資料庫伺服器同時修改以下引數：
set global enforce_gtid_consistency=warn; error log 不會出現警告資訊，如果有，需要先修復，才能繼續後面操作。
set global enforce_gtid_consistency=on;
set global gtid_mode=off_permissive;
set global gtid_mode=on_permissive;
確認從庫沒等待的事務：
show global status like '%ongoing%';
0代表沒有等待的事務。
主從庫上同時設定gtid_mode=on;
set global gtid_mode=on;
show variables like '%gtid%';
把傳統複製模式改為（GTID）複製。
stop slave;
change master to master_auto_position=1;
檢視並進行測試：
主：
從：
例如主庫：
從庫：
5、GTID使用限制條件
GTID複製是針對事物，一個gtid對於一個事務。
1、 不能使用create table table_name select * from table_name。
2、 在一個事務中即包含事務表的操作，又包含非事物表。
3、 不支援create temporary table or drop temporary table語句操作。
4、 使用GTID複製從庫調過錯誤，不支援執行slave_skip_errors。
MySQL5.6 GTID新特性實踐
搭建
本次搭建使用了mysql_sandbox指令碼為基礎，先建立了一個一主三從的基於位置複製的環境。然後透過配置修改，將整個架構專為基於GTID的複製。如果你還不熟悉mysql_sandbox，可以閱讀部落格之前的文章
。需要一次對主從節點做配置修改，並重啟服務。這樣的操作，顯然在production環境進行升級時是不可接受的。Facebook,Booking.com,Percona都對此透過patch做了最佳化，做到了更優雅的升級。具體的操作方式會在以後的博文當中介紹到。這裡我們就按照官方文件，進行一次實驗性的升級。 主要的升級步驟會有以下幾步：
- 確保主從同步
- 在master上配置read_only，保證沒有新資料寫入
- 修改master上的my.cnf，並重啟服務
- 修改slave上的my.cnf，並重啟服務
- 在slave上執行change master to並帶上master_auto_position=1啟用基於GTID的複製
由於是實驗環境，read_only和服務重啟並無大礙。只要按照官方的
做就能順利完成升級，這裡就不贅述詳細過程了。下面列舉了一些在升級過程中容易遇到的錯誤。
[ERROR] --gtid-mode[ERROR] --gtid-modechange master to 後的warnings
在按照文件的操作change master to後，會發現有兩個warnings。其實是兩個安全性警告，不影響正常的同步（有興趣的讀者可以看下關於該warning的
那麼實際生產應用當中，偶爾會遇到這樣的情況：某個slave從備份恢復後（或者load data infile）後，DBA可以人為保證該slave資料和master一致；或者即使不一致，這些差異也不會導致今後的主從異常（例如：所有master上只有insert沒有update）。這樣的前提下，我們又想使slave透過replication從master進行資料複製。此時我們就需要跳過master已經被purge的部分，那麼實際該如何操作呢？ 我們還是以實驗一的情況為例：
先確認master上已經purge的部分。從下面的命令結果可以知道master上已經缺失24024e52-bd95-11e4-9c6d-926853670d0b:1這一條事務的相關日誌
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)
在slave上透過set global gtid_purged='xxxx'的方式，跳過已經purge的部分
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)
可以看到此時slave已經可以正常同步，並補齊了24024e52-bd95-11e4-9c6d-926853670d0b:2-3範圍的binlog日誌。
MySQL5.7殺手級新特性：GTID原理與實戰
一、理論篇
1.1 GTID是什麼(what)
1.1.1 GTID組成和架構
- GTID 架構
a) GTID = server_uuid:transaction_id
b) server_uuid 來源於 auto.cnf
c) GTID: 在一組複製中，全域性唯一
gtid_set: uuid_set [, uuid_set] ... | uuid_set: uuid: hhhhhhhh-hhhh-hhhh-hhhh-hhhhhhhhhhhh 0-interval: n[-n] (n >= GTID在binlog中的結構 GTID event 結構 * 假設有binlog: bin.001 : Previous-GTIDs=emptybin.002 : Previous-GTIDs=; binlog_event有：41-80 * 1-80bin.004 : Previous-GTIDs=; binlog_event有：121-160 binlog開始掃描（即：bin.004） bin.004的Previous-GTIDs=1-120，如果$A=140 > Previous-GTIDs,那麼肯定在3. binlog檔案 gtid_purged 丟棄掉的GTID gtid_next session級別的變數，下一個gtid enforce_gtid_consistency 保證GTID安全的引數 重要引數如何持久化 1) 如何持久化gtid_executed [ log-bin=on,log_slave_update=on ] 1. gtid_executed = mysqlnormal】 or .gtid_executed + last_binlog中最後沒寫到mysql.gtid_executed中的gtid_event 【recover】 2) 如何持久化重置的gtid_purged值? $A$A2. 由於有可能手動設定過gtid_purged=:a-b, binlog.index中，first_binlog的Previous-GTIDs肯定不會出現:a-b @@global.gtid_executed(mysql.@@global.gtid_executed代替) - last_binlog的Previous-GTIDs - last_binlog所有的gtid_event $reset_gtid_purged 來表示重置的gtid
3）如何持久化gtid_purged [ log-bin=on,log_slave_update=on ]
gtid_purged=binlog.index:first_binlog的Previous-GTIDs + gtid_mode=ON(必選) -slaveON(必選) enforce-consistency(必選)
- MySQL 5.7gtid_mode=
- -gtidON
- （可選）--高可用切換，最好設定
- log-updates
- =
- ON
- Slave sends to master range of identifiers of executed transactions to master
- 同樣的GTID不能被執行兩次，如果有同樣的GTID，會自動被skip掉。
-
GTID_SUBTRACT(set,subset) returns only those GTIDs from set that are not in subset WAIT_UNTIL_SQL_THREAD_AFTER_GTIDS(gtid_set[, timeout][,channel]) Wait until the given GTIDs have executed on slave - 新語法
1.1.5 新的複製協議 COM_BINLOG_DUMP_GTID
-71CA-9E33-C80AA9429562:11-71CA-9E33-C80AA9429562:10 的時候停止，下一個事務是11 2. START SLAVE SQL_THREAD UNTIL SQL_AFTER_GTIDS = 3E11FA47-11E1-56 表示，當SQL_thread 執行到3E11FA47-11E1 1.2.2 GTID replication [so easy] > 設定enforce-gtid-consistency=ON CREATE SELECT statements CREATE TABLE DROP TABLE statements inside transactions > Non-GTID 推薦配置： relay_log_recovery=1，relay_log_info_repository=TABLE，master_info_repository=TABLE > GTID 推薦配置：MASTER_AUTO_POSITION=on，relay_log_recovery=0 > Non-GTID 推薦配置： relay_log_recovery=1, sync_relay_log=1,relay_log_info_repository=TABLE，master_info_repository=TABLE > GTID 推薦配置： MASTER_AUTO_POSITION=on, relay_log_recovery=0 SET @@read_only = ON;
- step 2: 關閉所有MySQL
shell> mysqladmin -uusername -p mysqld ---logbin ---&
當然，在my.cnf中配置好最佳
- step 4: change master
MASTER_HOST = host, > MASTER_USER = user, > MASTER_AUTO_POSITION = mysql> SLAVE;
- step 5: 讓master 可讀可寫
mysql> global.mysqldump xx 獲取並且記錄gtid_purged值 --獲取並且記錄gtid_executed值，這個就相當於mysqldump中得到的gtid_purged
- step 2: 在新伺服器上reset master，匯入備份
reset --清空gtid資訊 匯入備份； set mysql> CHANGE MASTER TO > MASTER_PORT = port, > MASTER_PASSWORD = password, > 1;
START
- step 9: change master
STOP MASTER_AUTO_POSITION = maseter_auto_position同步好 在新 開啟新;
- binlog 已經傳遞到slave
change to maseter_auto_position同步好 master的surper_read_only=1. 選取最新的slave，master 2. 開啟新off;
以上操作，在傳統模式複製下，只能透過MHA來實現，MHA比較複雜。
現在，在GTID模式下，實現起來非常簡單，且非常方便。
2.4 GTID 運維和錯誤處理
- 使用GTID後，對原來傳統的運維有不同之處了，需要調整過來。
- 使用Row模式且複製配置正確的情況下，基本上很少發現有複製出錯的情況。
- slave 設定 super_read_only=on
2.4.1 錯誤場景: Errant transaction
- SET GLOBAL
- SQL> 'b9b4712a-df64-11e3-b391-60672090eb04:7'; --設定需要跳過的gtid event SQL> BEGIN;COMMIT; SQL> 'AUTOMATIC'; SQL> START SLAVE;
對於第二種不小心多執行了事務
這裡說下inject empty transction的隱患
d66-864f-ecf4bbf1f42c:1如果被刪掉，重啟後，不會
- 目前只能夠reset
- 設定gtid_purged
-23.4 GTID和複製過濾規則之間如何協同工作？MySQL，test還能愉快的過濾掉嗎？
<1pre style="font-family:courier new;color:#000000;font-size:16px;" box-sizing:border-box;margin-top:0px;margin-bottom:10px;padding:0px;overflow:auto;font-size:13px;border-radius:2px;line-height:1.42857;word-break:break-all;border:none;"="">可以，改過濾的會自己過濾，不用擔心
MySQL 5.7基於GTID的主從複製實踐
About Me
.............................................................................................................................................
● 本文整理自網路
● 本文在itpub（ http://blog.itpub.net/26736162/abstract/1/）、部落格園（ http://www.cnblogs.com/lhrbest）和個人微信公眾號（ xiaomaimiaolhr）上有同步更新
● 本文itpub地址： http://blog.itpub.net/26736162/abstract/1/
● 本文部落格園地址： http://www.cnblogs.com/lhrbest
● 本文pdf版、個人簡介及小麥苗雲盤地址： http://blog.itpub.net/26736162/viewspace-1624453/
● 資料庫筆試面試題庫及解答： http://blog.itpub.net/26736162/viewspace-2134706/
● DBA寶典今日頭條號地址：
.............................................................................................................................................
● QQ群： 230161599 微信群：私聊
● 聯絡我請加QQ好友(646634621)，註明新增緣由
● 於 2017-07-01 09:00 ~ 2017-07-31 22:00 在魔都完成
● 文章內容來源於小麥苗的學習筆記，部分整理自網路，若有侵權或不當之處還請諒解
● 版權所有，歡迎分享本文，轉載請保留出處
.............................................................................................................................................
● 小麥苗的微店：
● 小麥苗出版的資料庫類叢書： http://blog.itpub.net/26736162/viewspace-2142121/
.............................................................................................................................................
使用 微信客戶端掃描下面的二維碼來關注小麥苗的微信公眾號（ xiaomaimiaolhr）及QQ群（DBA寶典），學習最實用的資料庫技術。
小麥苗的微信公眾號 小麥苗的QQ群 小麥苗的微店
.............................................................................................................................................
About Me
|
........................................................................................................................ ● 本文作者：小麥苗，部分內容整理自網路，若有侵權請聯絡小麥苗刪除 ● 本文在itpub、部落格園、CSDN和個人微 信公眾號（ xiaomaimiaolhr）上有同步更新 ● 本文itpub地址： http://blog.itpub.net/26736162 ● 本文部落格園地址： http://www.cnblogs.com/lhrbest ● 本文CSDN地址： https://blog.csdn.net/lihuarongaini ● 本文pdf版、個人簡介及小麥苗雲盤地址： http://blog.itpub.net/26736162/viewspace-1624453/ ● 資料庫筆試面試題庫及解答： http://blog.itpub.net/26736162/viewspace-2134706/ ● DBA寶典今日頭條號地址： ........................................................................................................................ ● QQ群號： 230161599（滿） 、618766405 ● 微 信群：可加我微 信，我拉大家進群，非誠勿擾 ● 聯絡我請加QQ好友 （ 646634621 ），註明新增緣由 ● 於 2019-07-01 06:00 ~ 2019-07-31 24:00 在西安完成 ● 最新修改時間：2019-07-01 06:00 ~ 2019-07-31 24:00 ● 文章內容來源於小麥苗的學習筆記，部分整理自網路，若有侵權或不當之處還請諒解 ● 版權所有，歡迎分享本文，轉載請保留出處 ........................................................................................................................ ● 小麥苗的微店： ● 小麥苗出版的資料庫類叢書： http://blog.itpub.net/26736162/viewspace-2142121/ ● 小麥苗OCP、OCM、高可用網路班： http://blog.itpub.net/26736162/viewspace-2148098/ ● 小麥苗騰訊課堂主頁： https://lhr.ke.qq.com/ ........................................................................................................................ 使用 微 信客戶端掃描下面的二維碼來關注小麥苗的微 信公眾號（ xiaomaimiaolhr）及QQ群（DBA寶典）、新增小麥苗微 信， 學習最實用的資料庫技術。
........................................................................................................................ |
 |
|
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/26736162/viewspace-2651411/，如需轉載，請註明出處，否則將追究法律責任。
相關文章
- MysqL主從複製_模式之GTID複製MySql模式
- mysql GTID 主從複製概述MySql
- Mysql 基於GTID主從複製MySql
- 【MySQL】主從GTID複製修復MySql
- MySQL主從複製之半同步複製MySql
- MySQL主從複製之非同步複製MySql非同步
- mysql之 MySQL 主從基於 GTID 複製原理概述MySql
- Mysql 8.4.0 結合 Docker 搭建GTID主從複製，以及傳統主從複製MySqlDocker
- MySQL主從複製與主主複製MySql
- MySQL主從複製、半同步複製和主主複製MySql
- mysql複製--主從複製配置MySql
- MySQL主從複製、半同步複製和主主複製概述MySql
- mysql5.7主從複製，主主複製MySql
- MySQL 5.7 基於GTID搭建主從複製MySql
- MySQL 5.7基於GTID的主從複製MySql
- MySQL主從複製_複製過濾MySql
- MySQL的主從複製與MySQL的主主複製MySql
- MySQL的主從複製、半同步複製、主主複製詳解MySql
- 配置mysql5.5主從複製、半同步複製、主主複製MySql
- MySQL 5.6 建立GTID主從複製 (GTID-based Replication)MySql
- MySQL 主從複製MySql
- 【MySql】主從複製MySql
- MySQL主從複製MySql
- MySQL GTID複製MySql
- MySQL8.0輕鬆搞定GTID主從複製MySql
- mysql之 mysql 5.6不停機主從搭建（一主一從基於GTID複製）MySql
- MySQL 8 複製（四）——GTID與複製MySql
- MySQL 8 複製（五）——配置GTID複製MySql
- MySQL主從複製之GTID模式詳細介紹鞴嬈MySql模式
- MySQL 主從複製之多執行緒複製MySql執行緒
- MySQL主從複製原理MySql
- MySQL的主從複製MySql
- mysql--主從複製MySql
- mysql主從複製搭建MySql
- MySql 主從複製配置MySql
- MySQL主從複製配置MySql
- mysql 8.4 主從複製MySql
- MySQL(二)：主從複製結構、半同步複製、雙主複製結構、利用SSL實現安全的MySQL主從複製MySql