Mysql 5.7 Gtid內部學習(五) mysql.gtid_executed表及其他變數更改時機
本節將集中討論下面三種Gtid更新的時機,這部分相當重要,後面的故障案列會和這節有關。下面先來看一下他們的定義
- mysql.gtid_executed表:Gtid持久化的介質,Mysql啟動階段會讀取這個表來獲取gtid_executed變數的值。
- gtid_executed變數(show global variables):Mysql資料庫已經執行了哪些Gtid事物,處於記憶體中。show slave status中的Executed_Gtid_Set也取自這裡。
- gtid_purged變數(show global variables):由於binlog檔案的刪除(如purge binary logfiles或者超過expire_logs_days設定)已經丟失的Gtid事物,同時在搭建備庫的我們使用set global gtid_purged變數來提示Mysql哪些Gtid事物我已經執行過了。
這也是我們DBA通常能夠觀察到的幾種Gtid,有了前文的描述我們知道其中mysql.gtid_executed表是一種Gtid持久化的介質,而gtid_executed變數和gtid_purged變數則對應
了Gtid_state中的executed_gtids和lost_gtids記憶體資料。他們分別表示Mysql資料庫執行了哪些Gtid事物,有哪些Gtid事物由於binlog檔案的刪除已經丟失了。
其次我們先來達成一個共識gtid_executed變數一定是實時更新的不管主庫和從庫。我們的討論分為主庫,從庫和通用從原始碼的角度進行詳細討論。並且約定都是開啟Gtid的情況下。最後給出最終總結。
一、主庫修改時機
(1) binlog關閉
不生成Gtid,mysql.gtid_executed表/gtid_executed變數/gtid_purged變數均不更新。
(2) binlog開啟
- mysql.gtid_executed表修改時機
在binlog發生切換(rotate)的時候儲存直到上一個binlog檔案執行過的全部Gtid,它不是實時更新的。
棧幀如下:
#0 Gtid_table_persistor::save (this=0x2f9f9c0, gtid_set=0x7ffff03595a0) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/rpl_gtid_persist.cc:425 #1 0x0000000001803dbe in Gtid_state::save (this=0x2ff8bb0, gtid_set=0x7ffff03595a0) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/rpl_gtid_state.cc:796 #2 0x0000000001803f62 in Gtid_state::save_gtids_of_last_binlog_into_table (this=0x2ff8bb0, on_rotation=true) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/rpl_gtid_state.cc:835 #3 0x000000000185266d in MYSQL_BIN_LOG::new_file_impl (this=0x2dffc80, need_lock_log=false, extra_description_event=0x0) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/binlog.cc:6751 #4 0x00000000018520a7 in MYSQL_BIN_LOG::new_file_without_locking (this=0x2dffc80, extra_description_event=0x0) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/binlog.cc:6636 #5 0x0000000001853e67 in MYSQL_BIN_LOG::rotate (this=0x2dffc80, force_rotate=true, check_purge=0x7ffff0359c4b) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/binlog.cc:7292
其主要邏輯在Gtid_state::save_gtids_of_last_binlog_into_table 中我們在隨後的部分討論這個函式邏輯。
- gtid_executed變數修改時機
如前文所述ordered_commit flush階段生成Gtid,在commit階段才計入gtid_executed變數,它是實時更新的。
棧幀如下:
#0 Gtid_set::_add_gtid (this=0x2ff8d38, sidno=1, gno=16) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/rpl_gtid.h:1135 #1 0x0000000001804576 in Gtid_set::_add_gtid (this=0x2ff8d38, gtid=...) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/rpl_gtid.h:1166 #2 0x00000000018024ba in Gtid_state::update_gtids_impl (this=0x2ff8bb0, thd=0x7fff2c000b70, is_commit=true) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/rpl_gtid_state.cc:304 #3 0x00000000018020df in Gtid_state::update_on_commit (this=0x2ff8bb0, thd=0x7fff2c000b70) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/rpl_gtid_state.cc:148 #4 0x00000000018573d4 in MYSQL_BIN_LOG::process_commit_stage_queue (this=0x2dffc80, thd=0x7fff2c000b70, first=0x7fff2c000b70) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/binlog.cc:8646 #5 0x0000000001858b51 in MYSQL_BIN_LOG::ordered_commit (this=0x2dffc80, thd=0x7fff2c000b70, all=false, skip_commit=false) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/binlog.cc:9304
其主要邏輯在Gtid_state::update_gtids_impl中我們在隨後的部分討論這個函式邏輯。
- gtid_purged變數修改時機
在Mysql觸發的清理binlog的情況下,比如purge binary logs to或者超過引數expire_logs_days設定的天數後自動刪除,需要將丟失的Gtid計入這個變數中。
棧幀如下:
#0 MYSQL_BIN_LOG::init_gtid_sets (this=0x2e00280, all_gtids=0x0, lost_gtids=0x2fcaee8, verify_checksum=false, need_lock=false, trx_parser=0x0, gtid_partial_trx=0x0, is_server_starting=false) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/binlog.cc:4333 #1 0x0000000001850b8e in MYSQL_BIN_LOG::purge_logs (this=0x2e00280, to_log=0x7fff57a74ad0 "/root/mysql5.7.14/percona-server-5.7.14-7/mysql-test/var/mysqld.1/test.000202", included=false, need_lock_index=true, need_update_threads=true, decrease_log_space=0x0, auto_purge=false) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/binlog.cc:6036 #2 0x0000000001848ecf in purge_master_logs (thd=0x7fff49200dc0, to_log=0x7fff492051a8 "test.000202") at /root/mysql5.7.14/percona-server-5.7.14-7/sql/binlog.cc:2815
其主要邏輯在MYSQL_BIN_LOG::purge_logs中,我們隨後檢視其程式碼片段,同時MYSQL_BIN_LOG::init_gtid_sets函式是一個及其重要的函式,主要用在:
- Mysql啟動時候初始化整個Gtid_state中的各種Gtid_set。
- Mysql刪除binlog(如purge binary logfiles或者超過expire_logs_days設定)後需要確認gtid_purged變數(及Gtid_state.lost_gtids)的值的時候。
隨後我會單獨一節來講解Mysql Gtid模組的初始化還會講解這個函式。
二、主庫修改時機原始碼函式分析
這裡就對上面提到的主要邏輯函式進行分析
- Gtid_state::save_gtids_of_last_binlog_into_table函式邏輯
logged_gtids_last_binlog.add_interval_memory(PREALLOCATED_INTERVAL_COUNT, iv); //這裡構建一個logged_gtids_last_binlog集合來儲存切換後需要寫入表和previous_gtids_logged的Gtid /* logged_gtids_last_binlog= executed_gtids - previous_gtids_logged - gtids_only_in_table */ global_sid_lock->wrlock();// ret= (logged_gtids_last_binlog.add_gtid_set(&executed_gtids) != //將當前執行過的Gtid全部加入logged_gtids_last_binlog 列如:executed_gtids start=1, end=27 RETURN_STATUS_OK); if (!ret) { logged_gtids_last_binlog.remove_gtid_set(&previous_gtids_logged); //獲得上一個binlog檔案包含的全部Gtid,並且做一個差集 列如:previous_gtids_logged 為start=1, end=25 //做完差集後logged_gtids_last_binlog為start=26, end=27 logged_gtids_last_binlog.remove_gtid_set(>ids_only_in_table);//此處主庫一定為空,除非異常情況 if (!logged_gtids_last_binlog.is_empty()) { /* Prepare previous_gtids_logged for next binlog on binlog rotation */ if (on_rotation) ret= previous_gtids_logged.add_gtid_set(&logged_gtids_last_binlog);//將這個start=26, end=27的Gtid集合加入到previous_gtids_logged中,這樣previous_gtids_logged也完整了 global_sid_lock->unlock(); /* Save set of GTIDs of the last binlog into gtid_executed table */ if (!ret) ret= save(&logged_gtids_last_binlog);//將這個start=26, end=27的Gtid集合寫入到表mysql.gtid_executed表中 }
- Gtid_state::update_gtids_impl函式程式碼片段
while (g.sidno != 0) { if (g.sidno != prev_sidno) sid_locks.lock(g.sidno); owned_gtids.remove_gtid(g); //從owned_gtid中去掉 git.next(); g= git.get(); if (is_commit) executed_gtids._add_gtid(g);//將這個Gtid加入到executed_gtids }
- MYSQL_BIN_LOG::purge_logs函式程式碼片段
if (!is_relay_log) { global_sid_lock->wrlock(); error= init_gtid_sets(NULL, const_cast<Gtid_set *>(gtid_state->get_lost_gtids()), opt_master_verify_checksum, false/*false=don't need lock*/, NULL/*trx_parser*/, NULL/*gtid_partial_trx*/);//這裡我看到將gtid_state->lost_gtids直接傳入給了init_gtid_sets //init_gtid_sets會做正向查詢獲得gtid_state->lost_gtids這個函式稍後 //詳細討論 global_sid_lock->unlock(); if (error) goto err; }
三、從庫修改時機
(1) binlog關閉或者binlog開啟引數log_slave_updates關閉的情況
將他們放到一起因為他們的表現完全一樣。
- mysql.gtid_executed表修改時機
前面已經說過這種情況下從庫沒有辦法透過binlog來持久化sql_thread執行過的Gtid事物,只能透過實時更新mysql.gtid_executed表來儲存,所以必須要要實時將Gtid持久化到mysql.gtid_executed表中。實際上實時儲存mysql.gtid_executed發生在commit的preper階段之前,也就是最開始。但是對於主庫來講由於還沒有生成Gtid,那麼則不能寫入
棧幀如下:
#0 commit_owned_gtids (thd=0x7fffec000970, all=false, need_clear_owned_gtid_ptr=0x7ffff08bf2cb) at /mysql/mysql-5.7.17/sql/handler.cc:1571 #1 0x0000000000f465c3 in ha_commit_trans (thd=0x7fffec000970, all=false, ignore_global_read_lock=false) at /mysql/mysql-5.7.17/sql/handler.cc:1669 #2 0x0000000001686f0d in trans_commit_stmt (thd=0x7fffec000970) at /mysql/mysql-5.7.17/sql/transaction.cc:458 #3 0x000000000180fb16 in rows_event_stmt_cleanup (rli=0x3937d30, thd=0x7fffec000970) at /mysql/mysql-5.7.17/sql/log_event.cc:11124 #4 0x000000000180f801 in Rows_log_event::do_apply_event (this=0x7fffec018020, rli=0x3937d30) at /mysql/mysql-5.7.17/sql/log_event.cc:11026 #5 0x00000000017f7b7b in Log_event::apply_event (this=0x7fffec018020, rli=0x3937d30) at /mysql/mysql-5.7.17/sql/log_event.cc:3324 #6 0x00000000018690a6 in apply_event_and_update_pos (ptr_ev=0x7ffff08bf830, thd=0x7fffec000970, rli=0x3937d30) at /mysql/mysql-5.7.17/sql/rpl_slave.cc:4702 #7 0x000000000186a75e in exec_relay_log_event (thd=0x7fffec000970, rli=0x3937d30) at /mysql/mysql-5.7.17/sql/rpl_slave.cc:5212 #8 0x0000000001870d07 in handle_slave_sql (arg=0x38cc1c0) at /mysql/mysql-5.7.17/sql/rpl_slave.cc:7320
其主要邏輯包含在commit_owned_gtids中。
- gtid_executed變數修改時機
這個和主庫一樣實時更新,不做討論。
- gtid_purged變數修改時機
由於壓根沒有binlog來記錄已經執行過的Gtid事物,所以gtid_purged變數實時更新
其更改處於整個ha_commit_trans的結尾如下:
if (need_clear_owned_gtid) { thd->server_status&= ~SERVER_STATUS_IN_TRANS; /* Release the owned GTID when binlog is disabled, or binlog is enabled and log_slave_updates is disabled with slave SQL thread or slave worker thread. */ if (error) gtid_state->update_on_rollback(thd); else gtid_state->update_on_commit(thd); }
棧幀如下(這個棧幀取值5.7.17):
#0 Gtid_set::_add_gtid (this=0x2f9ef40, sidno=2, gno=33083) at /mysql/mysql-5.7.17/sql/rpl_gtid.h:1136 #1 0x00000000017e9990 in Gtid_set::_add_gtid (this=0x2f9ef40, gtid=...) at /mysql/mysql-5.7.17/sql/rpl_gtid.h:1167 #2 0x00000000017e906e in Gtid_state::update_gtids_impl_own_gtid (this=0x2f9eca0, thd=0x7fffec000970, is_commit=true) at /mysql/mysql-5.7.17/sql/rpl_gtid_state.cc:939 #3 0x00000000017e6f3f in Gtid_state::update_gtids_impl (this=0x2f9eca0, thd=0x7fffec000970, is_commit=true) at /mysql/mysql-5.7.17/sql/rpl_gtid_state.cc:240 #4 0x00000000017e6d25 in Gtid_state::update_on_commit (this=0x2f9eca0, thd=0x7fffec000970) at /mysql/mysql-5.7.17/sql/rpl_gtid_state.cc:201 #5 0x0000000000f46d46 in ha_commit_trans (thd=0x7fffec000970, all=true, ignore_global_read_lock=false) at /mysql/mysql-5.7.17/sql/handler.cc:1846 #6 0x000000000168676b in trans_commit (thd=0x7fffec000970) at /mysql/mysql-5.7.17/sql/transaction.cc:239 #7 0x0000000001802aaa in Xid_log_event::do_commit (this=0x7fffec013c60, thd_arg=0x7fffec000970) at /mysql/mysql-5.7.17/sql/log_event.cc:6824 #8 0x00000000018034d7 in Xid_apply_log_event::do_apply_event (this=0x7fffec013ca8, rli=0x3937d30) at /mysql/mysql-5.7.17/sql/log_event.cc:7049
當然其處理邏輯在Gtid_state::update_gtids_impl_own_gtid中。
(2)binlog開啟同時引數log_slave_updates開啟的情況
這種情況sql_thread執行過的Gtid事物可以透過binlog進行維護,所以mysql.gtid_executed表和gtid_purged變數不需要實時更新。
- mysql.gtid_executed表修改時機
和主庫一致。及在進行日誌切換的時候進行更新,不做討論
- gtid_executed變數修改時機
和主庫一樣實時更新,不做討論
- gtid_purged變數修改時機
和主庫一致,binlog刪除時更新,不做討論
四、從庫修改時機原始碼函式分析
- commit_owned_gtids函式邏輯:
//如果 binlog 沒有開啟包括(log_bin=0 和 sql_log_bin =0 )或者 開啟了binlog 但是slave執行緒並且slave update 沒有開啟,都會記錄gtid到表 //但是這裡要注意一點在主庫上如果binlog不開啟那麼thd->owned_gtid.sidno ==0 因為這個時候Gtid都沒有生成,生成階段為order_commit的commit階段 if ((!opt_bin_log || (thd->slave_thread && !opt_log_slave_updates)) && (all || !thd->in_multi_stmt_transaction_mode()) && //all 代表是否是顯示begin 事物 in_multi_stmt_transaction_mode則相反 !thd->is_operating_gtid_table_implicitly && //是否是GTID_NEXT方式 flase !thd->is_operating_substatement_implicitly)//是否是子語句 flase { /* If the binary log is disabled for this thread (either by log_bin=0 or sql_log_bin=0 or by log_slave_updates=0 for a slave thread), then the statement will not be written to the binary log. In this case, we should save its GTID into mysql.gtid_executed table and @@GLOBAL.GTID_EXECUTED as it did when binlog is enabled. */ if (thd->owned_gtid.sidno > 0) { error= gtid_state->save(thd);//就是這裡進行了mysql.gtid_executed表的實時更新 *need_clear_owned_gtid_ptr= true; } else if (thd->owned_gtid.sidno == THD::OWNED_SIDNO_ANONYMOUS) *need_clear_owned_gtid_ptr= true; }
-
Gtid_state::update_gtids_impl_own_gtid 函式邏輯片段
這個函式是5.7.17的,5.7.14沒有邏輯放到了Gtid_state::update_gtids_impl中
if (is_commit) { DBUG_EXECUTE_IF( "rpl_gtid_update_on_commit_simulate_out_of_memory", DBUG_SET("+d,rpl_gtid_get_free_interval_simulate_out_of_memory");); /* Any session adds transaction owned GTID into global executed_gtids. If binlog is disabled, we report @@GLOBAL.GTID_PURGED from executed_gtids, since @@GLOBAL.GTID_PURGED and @@GLOBAL.GTID_EXECUTED are always same, so we did not save gtid into lost_gtids for every transaction for improving performance. If binlog is enabled and log_slave_updates is disabled, slave SQL thread or slave worker thread adds transaction owned GTID into global executed_gtids, lost_gtids and gtids_only_in_table. */ executed_gtids._add_gtid(thd->owned_gtid); //加入executed_gtids集合 thd->rpl_thd_ctx.session_gtids_ctx(). notify_after_gtid_executed_update(thd); if (thd->slave_thread && opt_bin_log && !opt_log_slave_updates)//如果是slave執行緒同時binlog開啟了並且log_slave_updates關閉了 //如果binlog關閉則使用 executed_gtids這樣提高效能前面的註釋說了 { lost_gtids._add_gtid(thd->owned_gtid); //寫入lost_gtids也就是更新引數gtid_purged變數 gtids_only_in_table._add_gtid(thd->owned_gtid); } }
五、通用更改時機
mysql.gtid_executed表修改時機-
在reset master的時候清空本表
棧幀如下:
#0 Gtid_table_persistor::delete_all (this=0x2f9f9c0, table=0x7fff2c0116a0) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/rpl_gtid_persist.cc:795 #1 0x000000000180a4ef in Gtid_table_persistor::reset (this=0x2f9f9c0, thd=0x7fff2c000b70) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/rpl_gtid_persist.cc:689 #2 0x0000000001801f2e in Gtid_state::clear (this=0x2ff8bb0, thd=0x7fff2c000b70) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/rpl_gtid_state.cc:36 #3 0x000000000184fee6 in MYSQL_BIN_LOG::reset_logs (this=0x2dffe80, thd=0x7fff2c000b70, delete_only=false) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/binlog.cc:5586 #4 0x0000000001872308 in reset_master (thd=0x7fff2c000b70) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/rpl_master.cc:587
其主要邏輯在Gtid_state::clear中。
-
在set global gitd_purged的時候,設定本表
棧幀如下:
#0 Gtid_table_persistor::save (this=0x2f9f9c0, gtid_set=0x7ffff0359a70) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/rpl_gtid_persist.cc:425 #1 0x000000000180400a in Gtid_state::save (this=0x2ff8bb0, gtid_set=0x7ffff0359a70) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/rpl_gtid_state.cc:796 #2 0x0000000001803c25 in Gtid_state::add_lost_gtids (this=0x2ff8bb0, gtid_set=0x7ffff0359a70) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/rpl_gtid_state.cc:737 #3 0x00000000016778f3 in Sys_var_gtid_purged::global_update (this=0x2de9fe0, thd=0x7fff2c000b70, var=0x7fff2c006630) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/sys_vars.cc:5888 #4 0x00000000014d5cd1 in sys_var::update (this=0x2de9fe0, thd=0x7fff2c000b70, var=0x7fff2c006630) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/set_var.cc:184 #5 0x00000000014d74ee in set_var::update (this=0x7fff2c006630, thd=0x7fff2c000b70) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/set_var.cc:812 #6 0x00000000014d6d1a in sql_set_variables (thd=0x7fff2c000b70, var_list=0x7fff2c003528) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/set_var.cc:669
其主要邏輯在Gtid_state::add_lost_gtids中。
gtid_executed變數修改時機-
在reset master的時候清空本變數
棧幀同上 -
在set global gitd_purged的時候,設定本變數
棧幀同上 - 在mysql啟動的時候初始化設定gtid_executed變數,這個將在後面章節詳細描述描述步驟。
-
在reset master的時候清空本變數
棧幀同上 -
在set global gitd_purged的時候,設定本變數
棧幀同上 - 在mysql啟動的時候初始化設定gtid_executed變數,這個將在後面章節詳細描述描述步驟。
六、通用更改時機原始碼函式分析
- Gtid_state::clear函式邏輯
int Gtid_state::clear(THD *thd) { .... // the wrlock implies that no other thread can hold any of the mutexes sid_lock->assert_some_wrlock(); lost_gtids.clear();//此處清空gtid_purged變數 executed_gtids.clear();//此處清空gtid_executed變數 gtids_only_in_table.clear();//清空only in table Gtid set previous_gtids_logged.clear();//清空 previous gtids logged Gtid set /* Reset gtid_executed table. */ if ((ret= gtid_table_persistor->reset(thd)) == 1)//此處清空mysql.gtid_executed表 { /* Gtid table is not ready to be used, so failed to open it. Ignore the error. */ thd->clear_error(); ret= 0; } next_free_gno= 1; DBUG_RETURN(ret); }
- Gtid_state::add_lost_gtids函式邏輯
enum_return_status Gtid_state::add_lost_gtids(const Gtid_set *gtid_set) { ...... if (save(gtid_set)) //此處將set gtid_purge的值加入到mysql.gtid_executed表中 RETURN_REPORTED_ERROR; PROPAGATE_REPORTED_ERROR(gtids_only_in_table.add_gtid_set(gtid_set)); PROPAGATE_REPORTED_ERROR(lost_gtids.add_gtid_set(gtid_set));//此處將set gtid_purge的值加入到gtid_purge變數中 PROPAGATE_REPORTED_ERROR(executed_gtids.add_gtid_set(gtid_set));//此處將set gtid_purge的值加入到gtid_executed變數中 lock_sidnos(gtid_set); broadcast_sidnos(gtid_set); unlock_sidnos(gtid_set); DBUG_RETURN(RETURN_STATUS_OK); }
七、本節小結
為了方便這裡將上面的重點文字描述進行提取,去掉原始碼部分,方便大家閱讀
主庫修改時機
(1) binlog關閉不生成Gtid,mysql.gtid_executed表/gtid_executed變數/gtid_purged變數均不更新。
(2) binlog開啟-
mysql.gtid_executed表修改時機
在binlog發生切換(rotate)的時候儲存直到上一個binlog檔案執行過的全部Gtid,它不是實時更新的。 -
gtid_executed變數修改時機
如前文所述ordered_commit flush階段生成Gtid,在commit階段才計入gtid_executed變數,它是實時更新的。 -
gtid_purged變數修改時機
在Mysql觸發的清理binlog的情況下,比如purge binary logs to或者超過引數expire_logs_days設定的天數後自動刪除,需要將丟失的Gtid計入這個變數中。
從庫修改時機
(1) binlog關閉或者binlog開啟引數log_slave_updates關閉的情況-
mysql.gtid_executed表修改時機
實時將Gtid持久化到mysql.gtid_executed表中。 -
gtid_executed變數修改時機
它是實時更新的。 -
gtid_purged變數修改時機
由於壓根沒有binlog來記錄已經執行過的Gtid事物,所以gtid_purged變數實時更新
-
mysql.gtid_executed表修改時機
進行日誌切換的時候進行更新,同主庫。 -
gtid_executed變數修改時機
實時更新,同主庫。 -
gtid_purged變數修改時機
binlog刪除時更新,同主庫。
通用修改時機
-
mysql.gtid_executed表修改時機
1、在reset master的時候清空本表。
2、在set global gitd_purged的時候,設定本表。 -
gtid_executed變數修改時機
1、在reset master的時候清空本變數。
2、在set global gitd_purged的時候,設定本變數。
3、在mysql啟動的時候初始化設定gtid_executed變數。 -
gtid_purged變數修改時機
1、在reset master的時候清空本變數。
2、在set global gitd_purged的時候,設定本變數。
3、在mysql啟動的時候初始化設定gtid_executed變數。
此外reset master命令除了完整上述功能還會清理binlog,重新初始化binlog從序號1開始。而set global gitd_purged引數一般只有在reset master後使用,用於搭建Gtid從庫或者處理Gtid從庫故障。
學習完本節至少能學習到:
-
1、主庫和從庫對於mysql.gtid_executed表,gtid_executed變數,gitd_purged變數
在各種情況下的修改時機 - 2、reset master做了什麼關於Gtid相關的工作
- 3、set global gitd_purged做了什麼關於Gtid相關的工作
作者微信:
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/7728585/viewspace-2148838/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- Mysql 5.7 Gtid內部學習(四) mysql.gtid_executed表Previous gtid Event的改變MySql
- 第2節:mysql.gtid_executed表/gtid_executed變數/gtid_purged變數的更改時機MySql變數
- Mysql 5.7 Gtid內部學習(一) 導讀MySql
- Mysql 5.7 Gtid內部學習(八) Gtid帶來的運維改變MySql運維
- Mysql 5.7 Gtid內部學習(二) Gtid相關內部資料結構MySql資料結構
- Mysql 5.7 Gtid內部學習(三) Gtid和Last_commt/sequnce_number的生成時機MySqlAST
- Mysql 5.7 Gtid內部學習(十) 實際案例(二)MySql
- Mysql 5.7 Gtid內部學習(九) 實際案例(一)MySql
- Mysql 5.7 Gtid內部學習(六) Mysql啟動初始化Gtid模組MySql
- Mysql 5.7 Gtid內部學習(七) 總結binlog_gtid_simple_recovery引數帶來的影響MySql
- mysql的內部臨時表MySql
- mysql 5.7 GTID主從配置MySql
- MySQL5.7GTID淺析MySql
- MySQL 中的myisam內部臨時表MySql
- MYSQL5.7-GTID概要翻譯MySql
- MySQL 5.7 新特性 共享臨時表空間及臨時表改進MySql
- MySQL什麼時候會使用內部臨時表?MySql
- MySQL5.7GTID運維實戰MySql運維
- MySQL 5.7 用mysqldump搭建gtid主從MySql
- MySQL 5.7 用xtrabackup搭建gtid主從MySql
- [MySQL5.6]PerformanceSchema學習:命名規範、狀態變數及其他(2)MySqlORM變數
- mysql學習10:第五章:表MySql
- Activiti 學習筆記五:流程變數筆記變數
- Tensorflow學習筆記: 變數及共享變數筆記變數
- hive學習筆記之三:內部表和外部表Hive筆記
- MySQL 5.7 基於GTID搭建主從複製MySql
- MySQL 5.7基於GTID的主從複製MySql
- MySQL 5.7 使用GTID方式搭建複製環境MySql
- 深入理解MySQL5.7GTID系列(七)binlog_gtid_simple_recovery引數的影響總結MySql
- [Shell] shell中的內部變數變數
- 函式內部的變數提升函式變數
- 【MySQL】5.7新特性之五MySql
- MySQL常用內建變數MySql變數
- 你好奇過 MySQL 內部臨時表存了什麼嗎?MySql
- JAVA內部類學習Java
- MySQL 基礎知識梳理學習(四)—-GTIDMySql
- 每天一個 PHP 語法-變數使用及內部實現PHP變數
- Mysql 5.7儲存過程的學習MySql儲存過程