상세 정보 MySQL의 Seconds_Behind_Master
7888 단어 mysqlseconds behind master
Seconds_Behind_Master
mysql 메인 예비 실례에 대해seconds_behind_마스터는 마스터와 슬레이브 사이의 시간을 측정하는 중요한 매개 변수이다.slave에서 "Show slave status"를 실행합니다.seconds_behind_마스터의 값입니다.
원시적 실현
Definition:The number of seconds that the slave SQL thread is behind processing the master binary log.
Type:time_t(long)
계산 방식은 다음과 같습니다.
rpl_slave.cc::show_slave_status_send_data()
if ((mi->get_master_log_pos() == mi->rli->get_group_master_log_pos()) &&
(!strcmp(mi->get_master_log_name(),
mi->rli->get_group_master_log_name()))) {
if (mi->slave_running == MYSQL_SLAVE_RUN_CONNECT)
protocol->store(0LL);
else
protocol->store_null();
} else {
long time_diff = ((long)(time(0) - mi->rli->last_master_timestamp) -
mi->clock_diff_with_master);
protocol->store(
(longlong)(mi->rli->last_master_timestamp ? max(0L, time_diff) : 0));
}
주로 다음과 같은 두 가지 상황으로 나뉜다.last_master_timestamp
정의:
주 라이브러리 binlog에서 이벤트의 시간입니다.
type: time_t (long)
계산 방식:
last_master_timestamp는 예비 기기의 병렬 복제 여부에 따라 계산 방식이 다르다.
비병렬 복제:
rpl_slave.cc:exec_relay_log_event()
if ((!rli->is_parallel_exec() || rli->last_master_timestamp == 0) &&
!(ev->is_artificial_event() || ev->is_relay_log_event() ||
(ev->common_header->when.tv_sec == 0) ||
ev->get_type_code() == binary_log::FORMAT_DESCRIPTION_EVENT ||
ev->server_id == 0))
{
rli->last_master_timestamp= ev->common_header->when.tv_sec +
(time_t) ev->exec_time;
DBUG_ASSERT(rli->last_master_timestamp >= 0);
}
이 모드에서 last_master_timestamp는 모든 이벤트의 종료 시간을 나타냅니다. 그 중에서 when.tv_sec는 이벤트의 시작 시간을 나타냅니다.exec_time는 업무의 집행 시간을 표시합니다.이 값의 계산은 apply_이벤트 이전, 그래서 이벤트가 실행되지 않았을 때,last_master_timestamp가 업데이트되었습니다.때문에 exec_time는 Query_에만 있음log_이벤트에 존재하기 때문에last_master_timestamp는 하나의 업무의 다른 이벤트 단계 변화를 응용합니다.두 개의 insert 문장을 포함하는 업무를 예로 들면, 이 코드 세그먼트를 호출할 때, 이벤트의 형식, 시간 스탬프와 실행 시간을 출력합니다.
create table t1(a int PRIMARY KEY AUTO_INCREMENT ,b longblob) engine=innodb;
begin;
insert into t1(b) select repeat('a',104857600);
insert into t1(b) select repeat('a',104857600);
commit;
10T06:41:32.628554Z 11 [Note] [MY-000000] [Repl] event_type: 33 GTID_LOG_EVENT2020-02-10T06:41:32.628601Z 11 [Note] [MY-000000] [Repl] event_time: 1581316890
2020-02-10T06:41:32.628614Z 11 [Note] [MY-000000] [Repl] event_exec_time: 0
2020-02-10T06:41:32.628692Z 11 [Note] [MY-000000] [Repl] event_type: 2 QUERY_EVENT
2020-02-10T06:41:32.628704Z 11 [Note] [MY-000000] [Repl] event_time: 1581316823
2020-02-10T06:41:32.628713Z 11 [Note] [MY-000000] [Repl] event_exec_time: 35
2020-02-10T06:41:32.629037Z 11 [Note] [MY-000000] [Repl] event_type: 19 TABLE_MAP_EVENT
2020-02-10T06:41:32.629057Z 11 [Note] [MY-000000] [Repl] event_time: 1581316823
2020-02-10T06:41:32.629063Z 11 [Note] [MY-000000] [Repl] event_exec_time: 0
2020-02-10T06:41:33.644111Z 11 [Note] [MY-000000] [Repl] event_type: 30 WRITE_ROWS_EVENT
2020-02-10T06:41:33.644149Z 11 [Note] [MY-000000] [Repl] event_time: 1581316823
2020-02-10T06:41:33.644156Z 11 [Note] [MY-000000] [Repl] event_exec_time: 0
2020-02-10T06:41:43.520272Z 0 [Note] [MY-011953] [InnoDB] Page cleaner took 9185ms to flush 3 and evict 0 pages
2020-02-10T06:42:05.982458Z 11 [Note] [MY-000000] [Repl] event_type: 19 TABLE_MAP_EVENT
2020-02-10T06:42:05.982488Z 11 [Note] [MY-000000] [Repl] event_time: 1581316858
2020-02-10T06:42:05.982495Z 11 [Note] [MY-000000] [Repl] event_exec_time: 0
2020-02-10T06:42:06.569345Z 11 [Note] [MY-000000] [Repl] event_type: 30 WRITE_ROWS_EVENT
2020-02-10T06:42:06.569376Z 11 [Note] [MY-000000] [Repl] event_time: 1581316858
2020-02-10T06:42:06.569384Z 11 [Note] [MY-000000] [Repl] event_exec_time: 0
2020-02-10T06:42:16.506176Z 0 [Note] [MY-011953] [InnoDB] Page cleaner took 9352ms to flush 8 and evict 0 pages
2020-02-10T06:42:37.202507Z 11 [Note] [MY-000000] [Repl] event_type: 16 XID_EVENT
2020-02-10T06:42:37.202539Z 11 [Note] [MY-000000] [Repl] event_time: 1581316890
2020-02-10T06:42:37.202546Z 11 [Note] [MY-000000] [Repl] event_exec_time: 0
병렬 복제:
rpl_slave.cc mts_checkpoint_routine
ts = rli->gaq->empty()
? 0
: reinterpret_cast<Slave_job_group *>(rli->gaq->head_queue())->ts;
rli->reset_notified_checkpoint(cnt, ts, true);
/* end-of "Coordinator::"commit_positions" */
이 모드에서 예비기기에 분배 대기열 가q가 존재하며, 가q가 비어 있으면 last_commit_timestamp는 0입니다.만약gaq가 비어 있지 않으면 체크포인트 lwm를 유지합니다. lwm 이전의 업무는 모두 예비기에서 실행됩니다. 이때last_commit_timestamp는 lwm의 업무 수행이 끝난 시간으로 업데이트됩니다.이 시간 유형은 time_t 유형.
ptr_group->ts = common_header->when.tv_sec +
(time_t)exec_time; // Seconds_behind_master related
rli->rli_checkpoint_seqno++;
if (update_timestamp) {
mysql_mutex_lock(&data_lock);
last_master_timestamp = new_ts;
mysql_mutex_unlock(&data_lock);
}
병렬 복사 시, 이벤트 실행이 완료된 후에last_master_timestamp, 그래서 비병렬 복제와 병렬 복제 하의seconds_behind_마스터는 차이가 있을 수 있습니다.clock_diff_with_master
정의:
rpl_slave.cc::get_master_version_and_clock()
if (!mysql_real_query(mysql, STRING_WITH_LEN("SELECT UNIX_TIMESTAMP()")) &&
(master_res= mysql_store_result(mysql)) &&
(master_row= mysql_fetch_row(master_res)))
{
mysql_mutex_lock(&mi->data_lock);
mi->clock_diff_with_master=
(long) (time((time_t*) 0) - strtoul(master_row[0], 0, 10));
DBUG_EXECUTE_IF("dbug.mts.force_clock_diff_eq_0",
mi->clock_diff_with_master= 0;);
mysql_mutex_unlock(&mi->data_lock);
}
이 차치는 마스터와 슬레이브가 연결될 때 한 번만 계산됩니다.기타
exec_time
정의:
struct timeval end_time;
ulonglong micro_end_time = my_micro_time();
my_micro_time_to_timeval(micro_end_time, &end_time);
exec_time = end_time.tv_sec - thd_arg->query_start_in_secs();
시간 함수
(1)time_t time(time_t timer) time_t는long 유형으로 되돌아오는 수치가 초까지만 정확합니다.
(2) int gettime ofday(struct timeval*tv,struct timezone*tz)는 마이크로초급의 현재 시간을 얻을 수 있다.
(3)timeval 구조
#include <time.h>
stuct timeval {
time_t tv_sec; /*seconds*/
suseconds_t tv_usec; /*microseconds*/
}
총결산
seconds_ 사용하기behind_master 평가 메인 대기 시간은 초 수준까지만 정확하고 일부 장면에서seconds_behind_마스터는 주비 간의 지연 시간을 정확하게 반영하지 못한다.주 준비 이상 시 seconds_ 결합 가능behind_마스터 원본을 구체적으로 분석합니다.
이상은 MySQL의 Seconds_Behind_마스터 상세 정보 MySQL Seconds_Behind_마스터의 자료는 우리의 다른 관련 문장을 주목하세요!
이 내용에 흥미가 있습니까?
현재 기사가 여러분의 문제를 해결하지 못하는 경우 AI 엔진은 머신러닝 분석(스마트 모델이 방금 만들어져 부정확한 경우가 있을 수 있음)을 통해 가장 유사한 기사를 추천합니다:
MySQL에서 JSON 인덱싱 - aarondfrancis사람들은 종종 MySQL로 JSON을 인덱싱할 수 없다고 말하지만 완전히 정확하지는 않습니다. MySQL로 JSON 열을 인덱싱하는 것은 완전히 가능합니다! 사람들은 종종 MySQL로 JSON을 인덱싱할 수 없다고 ...
텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
CC BY-SA 2.5, CC BY-SA 3.0 및 CC BY-SA 4.0에 따라 라이센스가 부여됩니다.