며칠 전 저는 슬레이브 MySQL 서버(Mysql Community Server 8.0.21)를 설정했습니다. 지금까지는 mysqldump를 사용한 백업에만 사용했습니다. 나는 그가 너무 많은 메모리를 사용하고 있다는 것을 알아차렸지만 그가 사용할 메모리 양을 자동 조절하는 몇 가지 conf 매개변수를 사용했고 VPS가 MySQL 서버 전용이었기 때문에 신경 쓰지 않았습니다. 전체 메모리를 사용하지 않으시겠습니까?)
오늘은 아침에 가장 먼저 Zabbix를 검색하고 슬레이브가 작동하지 않는 것을 확인하여 SSH로 접속하고 MySQL을 다시 시작한 다음 다음을 사용하여 슬레이브를 시작하려고 합니다.슬레이브 시작. 그리고 이것이 내가 얻은 것입니다:
ERROR 1872 (HY000): Slave failed to initialize relay log info structure from the repository
처음에 문제의 원인이 무엇인지 잘 모르겠습니다(이것은 내 my.cnf입니다).
[client]
# Usado apenas para casos especificos
port = 3306 # Porta parada
socket = /var/run/mysqld/mysqld.sock
[mysql]
# Configurações do cliente
auto-rehash # Auto completar
[mysqld]
# Configuração do servidor
pid_file = /var/run/mysqld/mysqld.pid
socket = /var/run/mysqld/mysqld.sock
datadir = /var/lib/mysql
log_error = /var/log/mysql/error.log
user = mysql
bind_address = 0.0.0.0 # Ouve todos os endereços
# Configurações genericas do servidor
max_allowed_packet = 32M # Tamanho maximo do pacote.
max_connections = 2000 # Maximo de coneções
open_files_limit = 10000 # Maximo de arquivos abertos
tmp_table_size = 64M # Limite tamanho tabela em mem
max_heap_table_size = 64M # Limite tamanho tabela em mem
tmpdir = /tmp # Diretorio /tmp/
default_storage_engine = InnoDB # Engine default
skip_name_resolve # Desabilita resolução DNS
# Configurações de log binario
log_bin = mysql-bin # Arquivo de log binario
relay-log = mysql-relay-bin
log-slave-updates = 1 # Log de update no slave
read-only = 1 # Apenas leitura
binlog-format = mixed # Formato
server_id = 2 # Identifica servidor para log
max_binlog_size = 256M # Tamanho maximo log binario
binlog_expire_logs_seconds = 604800 # Max tempo log binario
innodb_flush_log_at_trx_commit = 1 # Proteção de dados
sync_binlog = 1 # Somente pra replicação
# Configurações especificas do InnoDB
innodb_dedicated_server = ON # Autoconf InnoDB
innodb_io_capacity = 2000 # Quantas escritas por segundo
innodb_read_io_threads = 64 # Threads de leitura
innodb_write_io_threads = 64 # Threads de escrita
innodb_thread_concurrency = 0 # Auto dectecta threads
# Slow query log
slow_query_log = 1 # Guarda queries lentas
long_query_time = 1.0 # Tempo query
# Funções dentro do Mysql
log_bin_trust_function_creators = 1; # Permite funções criadas
나는 그것을 고치는 방법을 모른다. 전체 덤프를 다시 수행해야 합니까? 이런 일이 다시 발생하지 않도록 하려면 어떻게 해야 합니까?
업데이트:
이는 다음의 결과입니다.슬레이브 상태 표시:
mysql> SHOW SLAVE STATUS \G
*************************** 1. row ***************************
Slave_IO_State:
Master_Host: IP_ADDR
Master_User: USER
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000011
Read_Master_Log_Pos: 178887867
Relay_Log_File: pergamum-relay-bin.000029
Relay_Log_Pos: 178888082
Relay_Master_Log_File: mysql-bin.000011
Slave_IO_Running: No
Slave_SQL_Running: No
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 13124
Last_Error: Slave failed to initialize relay log info structure from the repository
Skip_Counter: 0
Exec_Master_Log_Pos: 178887867
Relay_Log_Space: 0
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: NULL
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 13124
Last_SQL_Error: Slave failed to initialize relay log info structure from the repository
Replicate_Ignore_Server_Ids:
Master_Server_Id: 0
Master_UUID: bef45e1b-99d6-11ea-a355-3e2547e4f083
Master_Info_File: mysql.slave_master_info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State:
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp: 200819 09:58:32
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set:
Executed_Gtid_Set:
Auto_Position: 0
Replicate_Rewrite_DB:
Channel_Name:
Master_TLS_Version:
Master_public_key_path:
Get_master_public_key: 0
Network_Namespace:
1 row in set (0.00 sec)
업데이트
요청한 대로 두 서버의 변수는 다음과 같습니다.
주인
GLOBAL STATUS:
https://gist.github.com/IamRichter/ef4993bbf65883baa366ff30d73b9644
GLOBAL VARIABLES:
https://gist.github.com/IamRichter/dbf08facd364548529b07bc0cbd6b2e6
노예
GLOBAL STATUS:
https://gist.github.com/IamRichter/fcdff1111ed52fc859ebac46a2dbfc27
GLOBAL VARIABLES:
https://gist.github.com/IamRichter/53c5638fb3c6064fd51eab332660f07f
답변1
아쉽게도 VARIABLES/STATUS에는 현재 발생한 문제에 대한 명확한 이유가 표시되지 않습니다. 아마도높은 buffer_pool_size가 RAM을 너무 많이 압박하고 있지만 의심스럽습니다. 내 분석은 다음과 같습니다(기본, 그 다음 복제본).
관찰:
- 버전: 8.0.20
- 16GB RAM
- 가동 시간 = 2일 02:30:41
- Windows에서 실행되고 있지 않습니다.
- 64비트 버전 실행
- InnoDB를 완전히 (또는 대부분) 실행하고 있는 것 같습니다.
더 중요한 문제:
table_open_cacheOS에서 허용하는 경우 늘리십시오 . 테이블이 왜 이렇게 많아??
(증거 없이) innodb_log_files_in_group MariaDB에 "2" 이외의 것을 사용하는 것은 현명하지 못한 일이라고 생각합니다. 이미 이를 무시하고 있습니다. 오라클에 대해서는 들어본 적이 없습니다.
쿼리가 잘못 구성되었다는 징후가 몇 가지 있습니다. 보다http://mysql.rjweb.org/doc.php/mysql_analytic#slow_queries_and_slowlog느린 로그를 분석하기 위한 것입니다.
가지고 있는 이유가 있었나요 binlog_format=MIXED?
세부 사항 및 기타 관찰 사항:
( Opened_tables ) = 452,365 / 181841 = 2.5 /sec-- 테이블 열기 빈도 -- table_open_cache 증가(현재 3995)
( Table_open_cache_overflows ) = 448,306 / 181841 = 2.5 /sec
-- table_open_cache를 늘려야 할 수도 있습니다(현재 3995).
( Table_open_cache_misses ) = 452,365 / 181841 = 2.5 /sec
-- table_open_cache를 늘려야 할 수도 있습니다(현재 3995).
( innodb_lru_scan_depth * innodb_page_cleaners ) = 1,024 * 4 = 4,096-- 매초 페이지 클리너 작업량. -- "InnoDB: page_cleaner: 1000ms 의도된 루프 소요 ..."는 lru_scan_깊이를 낮추면 해결될 수 있습니다. 1000 / innodb_page_cleaners(현재 4)를 고려하십시오. 교환 여부도 확인해보세요.
( innodb_page_cleaners / innodb_buffer_pool_instances ) = 4 / 8 = 0.5-- innodb_page_cleaners -- innodb_page_cleaners(현재 4)를 innodb_buffer_pool_instances(현재 8)로 설정하는 것이 좋습니다.
( innodb_lru_scan_depth ) = 1,024
-- "InnoDB: page_cleaner: 1000ms 의도한 루프가 걸렸습니다..."는 lru_scan_length를 낮추면 수정될 수 있습니다.
( Innodb_pages_written / Innodb_buffer_pool_write_requests ) = 2,102,149 / 7377368 = 28.5%-- 디스크에 도달해야 하는 쓰기 요청 -- innodb_buffer_pool_size 확인(현재 12884901888)
( innodb_log_files_in_group ) = 9-- InnoDB 로그 파일 수 -- 2가 아마도 유일한 합리적인 값일 것입니다. 수가 많으면 성능 문제가 발생할 수 있습니다.
( Innodb_os_log_written / (Uptime / 3600) / innodb_log_files_in_group / innodb_log_file_size ) = 1,773,668,352 / (181841 / 3600) / 9 / 1024M = 0.00363-- 비율 -- (분 참조)
( Uptime / 60 * innodb_log_file_size / Innodb_os_log_written ) = 181,841 / 60 * 1024M / 1773668352 = 1,834-- InnoDB 로그 회전 간격(분) 5.6.8부터 동적으로 변경될 수 있습니다. my.cnf도 변경하십시오. -- (회전 간격 60분 권장은 다소 임의적입니다.) innodb_log_file_size(현재 1073741824)를 조정합니다. (AWS에서는 변경할 수 없습니다.)
( innodb_flush_method ) = innodb_flush_method = O_DIRECT_NO_FSYNC-- InnoDB가 OS에 블록 쓰기를 요청하는 방법. 이중 버퍼링을 방지하려면 O_DIRECT 또는 O_ALL_DIRECT(Percona)를 제안하세요. (적어도 Unix의 경우) O_ALL_DIRECT에 대한 주의 사항은 chrischandler를 참조하세요.
( Innodb_row_lock_time_avg ) = 1,886-- 행을 잠그는 평균 시간(밀리초) -- 쿼리 충돌 가능성이 있습니다. 아마도 테이블 스캔 일 것입니다.
( innodb_print_all_deadlocks ) = innodb_print_all_deadlocks = OFF-- 모든 교착 상태를 기록할지 여부입니다. -- Deadlocks로 인해 어려움을 겪고 있다면 이 기능을 켜십시오. 주의: 교착 상태가 많으면 디스크에 많은 양이 기록될 수 있습니다.
( max_connections ) = 2,000-- 최대 연결 수(스레드). 다양한 할당에 영향을 미칩니다. -- max_connections(현재 2000)가 너무 높고 다양한 메모리 설정이 높으면 RAM이 부족해질 수 있습니다.
( Handler_read_rnd_next / Com_select ) = 46,219,107,293 / 7120289 = 6,491-- SELECT별로 검색된 평균 행 수입니다. (대략) -- read_buffer_size 증가를 고려합니다(현재 131072).
( (Com_insert + Com_update + Com_delete + Com_replace) / Com_commit ) = (358564 + 419704 + 462 + 0) / 2006877 = 0.388-- 커밋당 명령문 수(모든 InnoDB를 가정) -- 낮음: 트랜잭션에서 쿼리를 그룹화하는 데 도움이 될 수 있습니다. 높음: 긴 거래로 인해 다양한 문제가 발생합니다.
( Select_scan ) = 4,386,291 / 181841 = 24 /sec-- 전체 테이블 스캔 -- 인덱스 추가/쿼리 최적화(작은 테이블이 아닌 경우)
( Select_scan / Com_select ) = 4,386,291 / 7120289 = 61.6%-- 전체 테이블 스캔을 수행하는 선택의 %입니다. (저장된 루틴에 속을 수 있음) -- 인덱스 추가/쿼리 최적화
( binlog_format ) = binlog_format = MIXED-- 명령문/행/혼합. -- ROW는 5.7(10.3)에서 선호됩니다.
( Aborted_clients ) = 175,398 / 181841 = 0.96 /sec-- wait_timeout으로 인해 스레드가 범프되었습니다. -- wait_timeout을 늘립니다(현재 28800). 친절하게 대해주세요. 연결 해제를 사용하세요
( Connections ) = 3,544,963 / 181841 = 19 /sec-- 연결 -- wait_timeout을 늘립니다(현재 28800). 풀링을 사용 하시겠습니까?
비정상적으로 작음: Open_files = 3
비정상적으로 크다: Com_do = 0.02 /HR Com_release_savepoint = 2.3 /HR Com_rollback_to_savepoint = 0.11 /sec Com_savepoint = 2.3 /HR Com_show_charsets = 0.44 /HR Com_show_create_db = 2.3 /HR Com_show_create_func = 2.5 /HR Com_show_create_proc = 1.5 /HR Com_show_create_trigger = 0.12 /HR Com_show_function_status = 2.5 /HR Com_show_procedure_status = 2.5 /HR Com_show_table_status = 0.11 /sec Com_show_triggers = 0.11 /sec Created_tmp_files = 20 /sec Handler_read_key = 139335 /sec Handler_read_next = 316713 /sec Handler_read_rnd = 46465 /sec Handler_savepoint = 2.3 / HR Handler_savepoint_rollback = 0.11 /초 Innodb_buffer_pool_read_requests = 1095747 /초 Innodb_num_open_files = 3,996 Innodb_system_rows_inserted = 0.97 /HR Innodb_system_rows_read = 1.99e+7 Innodb_system_rows_updated = 0.095 /sec Open_table_definitions = 2,000 Select_full_range_join = 2.1 /sec Select_full_range_join / Com_select = 5. 5% back_log / max_connections = 100.0% innodb_max_dirty_pages_pct_lwm = 10 innodb_read_io_threads = 64 innodb_undo_tablespaces = 2 innodb_write_io_threads = 64 max_error_count = 1,024 max_length_for_sort_data = 4,096
비정상적인 문자열: default_authentication_plugin = caching_sha2_password event_scheduler = ON innodb_dedicated_server = ON innodb_fast_shutdown = 1 Optimizer_trace = 활성화=오프, one_line=오프 Optimizer_trace_features = 탐욕스러운_검색=온, range_optimizer=온, 동적 범위=온, 반복_하위 선택=on 슬레이브_rows_search_algorithms = INDEX_SCAN,HASH_SC 안
SF1030756-M
관찰:
- 버전: 8.0.21
- 6GB RAM
- 가동 시간 = 5일 23:59:45
- 이것이 SHOW GLOBAL STATUS 였습니까? -- 아니면 이 복제본이 단순히 바쁘지 않은 걸까요?
- Windows에서 실행되고 있지 않습니다.
- 64비트 버전 실행
- InnoDB를 완전히 (또는 대부분) 실행하고 있는 것 같습니다.
더 중요한 문제:
기본 -- table_open_cache, innodb_log_files_in_group,binlog_format
교환 여부를 확인하세요. innodb_buffer_pool_size6GB RAM에 비해 용량이 꽤 큽니다.
100으로 낮추기 max_connections- 지금까지 5개 이상을 사용하지 않았습니다. 현재 2000은 RAM에 부담이 됩니다.
세부 사항 및 기타 관찰 사항:
( table_open_cache ) = 3,995-- 캐시할 테이블 설명자 수 -- 일반적으로 수백 개가 좋습니다.
( Table_open_cache_misses / (Table_open_cache_hits + Table_open_cache_misses) ) = 56,436 / (1107115 + 56436) = 4.9%-- table_open_cache의 효율성. -- table_open_cache(현재 3995)를 늘리고 table_open_cache_instances(현재 16)를 확인하세요.
( innodb_lru_scan_depth * innodb_page_cleaners ) = 1,024 * 4 = 4,096-- 매초 페이지 클리너 작업량. -- "InnoDB: page_cleaner: 1000ms 의도된 루프 소요 ..."는 lru_scan_깊이를 낮추면 해결될 수 있습니다. 1000 / innodb_page_cleaners(현재 4)를 고려하십시오. 교환 여부도 확인해보세요.
( innodb_page_cleaners / innodb_buffer_pool_instances ) = 4 / 8 = 0.5-- innodb_page_cleaners -- innodb_page_cleaners(현재 4)를 innodb_buffer_pool_instances(현재 8)로 설정하는 것이 좋습니다.
( innodb_lru_scan_depth ) = 1,024
-- "InnoDB: page_cleaner: 1000ms 의도한 루프가 걸렸습니다..."는 lru_scan_length를 낮추면 수정될 수 있습니다.
( Innodb_pages_written / Innodb_buffer_pool_write_requests ) = 25,132 / 57003 = 44.1%-- 디스크에 도달해야 하는 쓰기 요청 -- innodb_buffer_pool_size 확인(현재 5368709120)
( innodb_log_files_in_group ) = 5-- InnoDB 로그 파일 수 -- 2가 아마도 유일한 합리적인 값일 것입니다. 수가 많으면 성능 문제가 발생할 수 있습니다.
( Innodb_os_log_written / (Uptime / 3600) / innodb_log_files_in_group / innodb_log_file_size ) = 22,224,896 / (518385 / 3600) / 5 / 512M = 5.7e-5-- 비율 -- (분 참조)
( Uptime / 60 * innodb_log_file_size / Innodb_os_log_written ) = 518,385 / 60 * 512M / 22224896 = 208,704-- InnoDB 로그 회전 간격(분) 5.6.8부터 동적으로 변경될 수 있습니다. my.cnf도 변경하십시오. -- (회전 간격 60분 권장은 다소 임의적입니다.) innodb_log_file_size(현재 536870912)를 조정합니다. (AWS에서는 변경할 수 없습니다.)
( innodb_flush_method ) = innodb_flush_method = O_DIRECT_NO_FSYNC-- InnoDB가 OS에 블록 쓰기를 요청하는 방법. 이중 버퍼링을 방지하려면 O_DIRECT 또는 O_ALL_DIRECT(Percona)를 제안하세요. (적어도 Unix의 경우) O_ALL_DIRECT에 대한 주의 사항은 chrischandler를 참조하세요.
( innodb_print_all_deadlocks ) = innodb_print_all_deadlocks = OFF-- 모든 교착 상태를 기록할지 여부입니다. -- Deadlocks로 인해 어려움을 겪고 있다면 이 기능을 켜십시오. 주의: 교착 상태가 많으면 디스크에 많은 양이 기록될 수 있습니다.
( max_connections ) = 2,000-- 최대 연결 수(스레드). 다양한 할당에 영향을 미칩니다. -- max_connections(현재 2000)가 너무 높고 다양한 메모리 설정이 높으면 RAM이 부족해질 수 있습니다.
( (Com_show_create_table + Com_show_fields) / Questions ) = (8605 + 17405) / 313218 = 8.3%-- 나쁜 프레임워크 -- 스키마를 재발견하는 데 많은 노력을 기울입니다. -- 제3자 공급업체에 불만을 제기하세요.
( tmp_table_size ) = 64M-- 크기 제한메모리SELECT를 지원하는 데 사용되는 임시 테이블 - RAM 부족을 방지하려면 tmp_table_size(현재 67108864)를 줄입니다. 아마도 64M을 넘지 않을 것입니다.
( Select_full_join / Com_select ) = 8,884 / 123363 = 7.2%-- 인덱스 없는 조인인 선택 비율 -- JOIN에 사용되는 테이블에 적합한 인덱스를 추가합니다.
( Select_scan / Com_select ) = 107,352 / 123363 = 87.0%-- 전체 테이블 스캔을 수행하는 선택의 %입니다. (저장된 루틴에 속을 수 있음) -- 인덱스 추가/쿼리 최적화
( Com_admin_commands / Queries ) = 6,755 / 320422 = 2.1%-- "admin" 명령인 쿼리의 비율입니다. -- 무슨 일이야?
( binlog_format ) = binlog_format = MIXED-- 명령문/행/혼합. -- ROW는 5.7(10.3)에서 선호됩니다.
( log_slow_slave_statements ) = log_slow_slave_statements = OFF-- (5.6.11, 5.7.1) 기본적으로 복제된 명령문은 느린 로그에 표시되지 않습니다. 이로 인해 표시됩니다. -- 복제본 읽기를 방해할 수 있는 쓰기를 느린 로그에서 확인하는 것이 도움이 될 수 있습니다.
( thread_cache_size / Max_used_connections ) = 28 / 5 = 560.0%
-- 예상되는 연결 수보다 스레드 캐시가 더 크다고 해서 이점이 없습니다. 공간 낭비가 단점이다.
( thread_stack * max_connections ) = (286720 * 2000) / 6144M = 8.9%-- max_connections에 대한 최소 메모리 할당입니다. -- max_connections 낮추기(현재 2000)
비정상적으로 작음: Bytes_received = 58 /sec Com_insert = 0 Com_update = 0 Created_tmp_files = 0.035 /HR Handler_update = 2.2 /HR Innodb_buffer_pool_write_requests = 0.11 /sec Innodb_buffer_pool_write_requests / Innodb_buffer_pool_pages_flushed = 2.27 Innodb_dblwr_pages_ 작성 / Innodb_dblwr_writes = 1 Innodb_pages_created = 1 /HR Innodb_rows_deleted + Innodb_rows_inserted = 0 Innodb_rows_inserted = 0 Innodb_rows_updated = 0 선택_범위 = 0 선택_범위 / Com_select = 0
비정상적으로 크다: Com_do = 0.014 /HR Com_show_create_func = 0.15 /HR Com_slave_start = 0.028 /HR Innodb_num_open_files = 3,996 Innodb_system_rows_read = 1.91e+7 Innodb_system_rows_updated = 2.2 /HR Open_table_definitions = 2,000 back_log / max_connections = 100.0% innodb_max_dirty_pages_pct_lwm = 10 innodb_read_io_threads = 64 innodb_undo_tablespaces = 2 innodb_write_io_threads = 64 max_error_count = 1,024 max_length_for_sort_data = 4,096 Optimizer_trace_offset = --1performance_schema_error_size = 4,772performance_schema_max_cond_classes = 100performance_schema_max_mutex_classes = 300performance_schema_max_rwlock_classes = 60performance_schema_max_stage_classes = 175performance_ Schema_max_statement_classes = 218performance_schema_max_thread_classes = 100
비정상적인 문자열: default_authentication_plugin = caching_sha2_password event_scheduler = ON innodb_dedicated_server = ON innodb_fast_shutdown = 1 Optimizer_trace = 활성화=오프, one_line=오프 Optimizer_trace_features = 탐욕스러운_검색=온, range_optimizer=on, 동적_범위=온, 반복_하위 선택=온 읽기 전용 = ON 슬레이브_rows_search_algorithms = INDEX_SCAN ,HASH_SCAN
SF1030756-S