Update_rows_log_event::ha_update_row(-1) 뒤에 있는 Mysql 복제
mysql 5.6(센토스 6)을 실행하는 MASTER 서버에서 Mariadb 10.1.22(센토스 7)을 실행하는 슬레이브로 복제를 설정하기 위해 여기서 약간의 도움을 받았습니다.
지금 내 문제는 이것입니다. 정확한 mariadb 버전과 사양을 가진 다른 서버가 있지만 복제가 따라잡지 못하고 대신 증가하고 있다는 것입니다.
시작할 때 48000초 뒤에 있었고 몇 분 후에 46000으로 빠르게 떨어졌습니다.그 이후로 꾸준히 증가하고 있습니다.거의 48K초로 거슬러 올라가는 쓰기 ATM
Show full processlist;sql 스레드가 실행하는 데 최대 8초가 소요됨을 보여줍니다.Update_rows_log_event::ha_update_row(-1)모든 구글 검색에서 나는 그것이 무엇을 의미하는지 찾을 수 없는 백 투 백.
MariaDB [(none)]> show full processlist;
+-----+------------------+---------------------------------------+--------------+---------+------+------------------------------------------+-----------------------+----------+
| Id | User | Host | db | Command | Time | State | Info | Progress |
+-----+------------------+---------------------------------------+--------------+---------+------+------------------------------------------+-----------------------+----------+
| 3 | system user | | NULL | Connect | 3640 | Queueing master event to the relay log | NULL | 0.000 |
| 2 | system user | | NULL | Connect | 5 | Update_rows_log_event::ha_update_row(-1) | NULL | 0.000 |
그리고 간단한 것을 잡았습니다.UPDATE table SET timestamp = NOW() WHERE static_ip = 'a-valid-ip' AND process_id = '13217'테이블에 static_ip 열과 process_id 열이 PK로 표시되고 명령을 직접 실행하면 0.078초가 걸립니다.
/etc/my.cnf의 내용
[mysqld]
max_allowed_packet = 1G
max_connections = 600
thread_cache_size = 16
query_cache_size = 64M
tmp_table_size= 512M
max_heap_table_size= 512M
wait_timeout=60
#Innodb Settings
innodb_file_per_table=1
innodb_buffer_pool_size = 25G
innodb_log_file_size = 2048M
innodb_flush_log_at_trx_commit = 0
innodb_file_format = Barracuda
innodb_flush_neighbors = 0
#Log
log-error =/var/log/error.log
tmpdir = /dev/shm
#Replication SLAVE
server-id=6
slave-skip-errors=1062
my.cnf는 slave-id를 제외하고는 정상적으로 실행되는 서버와 동일합니다.
무슨 일이 일어나고 있는지에 대한 제안이나 도움이 있습니까?
감사해요.
mariadb에 있는 직원들의 도움으로 ha_update_rows는 관련이 없었고 느림의 원인은 기계의 이중 디스크 장애였습니다.
[root@ser3 ~]# dd if=/dev/zero of=/tmp/output conv=fdatasync bs=384k count=1k;
1024+0 records in
1024+0 records out
402653184 bytes (403 MB) copied, 43.1096 s, 9.3 MB/s
이것은 SSD 입니다.
언급URL : https://stackoverflow.com/questions/43256936/mysql-replication-falling-behind-update-rows-log-eventha-update-row-1
'sourcetip' 카테고리의 다른 글
| Node Sass는 현재 환경을 아직 지원하지 않습니다. 런타임이 지원되지 않는 Windows 64비트(88) (0) | 2023.10.10 |
|---|---|
| K&R 연습 1-9: 입력을 출력하여 여러 공백을 하나의 공백으로 대체 (0) | 2023.10.10 |
| 봄에 Bean Post Processor와 init/destroy 방법의 차이점은 무엇입니까? (0) | 2023.10.10 |
| Python의 C/C++ 프로그램용 가상 Env와 동등한 것이 있습니까? (0) | 2023.10.10 |
| MySQL 워크벤치 : .sql 파일로 mysql 데이터베이스를 내보내는 방법? (0) | 2023.10.10 |