Vor ein paar Tagen habe ich einen MySQL-Slaveserver (Mysql Community Server 8.0.21) eingerichtet. Bisher verwenden wir ihn nur für Backups mit mysqldump. Mir ist aufgefallen, dass er zu viel Speicher verwendet, aber das hat mich nicht gestört, weil ich ein paar Konfigurationsparameter verwendet habe, die die Speichermenge automatisch regulieren, und der VPS war dem MySQL-Server gewidmet (wenn ich für den gesamten Speicher bezahle, warum sollte ich ihn dann nicht nutzen, oder?).
Heute habe ich als erstes am Morgen nach meinem Zabbix gesucht und festgestellt, dass der Slave nicht funktioniert. Ich habe mich also per SSH angemeldet, MySQL neu gestartet und versucht, den Slave mitSLAVE STARTEN. Und das habe ich bekommen:
ERROR 1872 (HY000): Slave failed to initialize relay log info structure from the repository
Ich bin nicht sicher, was das Problem ursprünglich verursacht hat (das ist meine 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
Ich habe keine Ahnung, wie ich das Problem beheben kann. Soll ich den gesamten Dump noch einmal durchführen? Wie kann ich verhindern, dass dies erneut passiert?
AKTUALISIEREN:
Dies ist das Ergebnis derSLAVE-STATUS ANZEIGEN:
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)
AKTUALISIEREN
Wie gewünscht, hier sind die Variablen von beiden Servern.
MEISTER
GLOBAL STATUS:
https://gist.github.com/IamRichter/ef4993bbf65883baa366ff30d73b9644
GLOBAL VARIABLES:
https://gist.github.com/IamRichter/dbf08facd364548529b07bc0cbd6b2e6
SKLAVE
GLOBAL STATUS:
https://gist.github.com/IamRichter/fcdff1111ed52fc859ebac46a2dbfc27
GLOBAL VARIABLES:
https://gist.github.com/IamRichter/53c5638fb3c6064fd51eab332660f07f
Antwort1
Leider werden in den VARIABLEN/STATUS-Informationen keine offensichtlichen Gründe für Ihr Problem angezeigt. Vielleichtdie hohe buffer_pool_size beansprucht den RAM zu sehr, aber ich bezweifle das. Hier sind meine Analysen (Primär, dann Replikat):
Beobachtungen:
- Version: 8.0.20
- 16 GB RAM
- Betriebszeit = 2d 02:30:41
- Sie verwenden kein Windows.
- 64-Bit-Version wird ausgeführt
- Sie scheinen vollständig (oder größtenteils) InnoDB auszuführen.
Die wichtigeren Themen:
Erhöhen Sie die Anzahl table_open_cache, wenn das Betriebssystem es zulässt. Warum so viele Tabellen?
Ich denke (ohne jeden Beweis), dass es unklug ist, etwas anderes als „2“ zu verwenden, da innodb_log_files_in_group MariaDB dies bereits ignoriert. Von Oracle habe ich noch nichts gehört.
Es gibt einige Hinweise auf schlecht formulierte Abfragen. Siehehttp://mysql.rjweb.org/doc.php/mysql_analysis#slow_queries_and_slowlogzur Analyse des Slowlogs.
Hatten Sie einen Grund dafür binlog_format=MIXED?
Details und weitere Beobachtungen:
( Opened_tables ) = 452,365 / 181841 = 2.5 /sec-- Häufigkeit des Öffnens von Tabellen -- Erhöhung von table_open_cache (jetzt 3995)
( Table_open_cache_overflows ) = 448,306 / 181841 = 2.5 /sec
-- Möglicherweise muss table_open_cache erhöht werden (derzeit 3995)
( Table_open_cache_misses ) = 452,365 / 181841 = 2.5 /sec
-- Möglicherweise muss table_open_cache erhöht werden (derzeit 3995)
( innodb_lru_scan_depth * innodb_page_cleaners ) = 1,024 * 4 = 4,096-- Arbeitsaufwand für Seitenreiniger pro Sekunde. -- „InnoDB: page_cleaner: 1000 ms beabsichtigte Schleife dauerte …“ kann möglicherweise durch Verringerung von lru_scan_depth behoben werden: Erwägen Sie 1000 / innodb_page_cleaners (jetzt 4). Überprüfen Sie auch das Swapping.
( innodb_page_cleaners / innodb_buffer_pool_instances ) = 4 / 8 = 0.5-- innodb_page_cleaners – Es wird empfohlen, innodb_page_cleaners (jetzt 4) auf innodb_buffer_pool_instances (jetzt 8) einzustellen.
( innodb_lru_scan_depth ) = 1,024
- „InnoDB: page_cleaner: Die beabsichtigte Schleife dauerte 1000 ms …“ kann durch Verringern von lru_scan_depth behoben werden.
( Innodb_pages_written / Innodb_buffer_pool_write_requests ) = 2,102,149 / 7377368 = 28.5%-- Schreibanforderungen, die auf die Festplatte gelangen mussten -- Überprüfen Sie innodb_buffer_pool_size (jetzt 12884901888)
( innodb_log_files_in_group ) = 9-- Anzahl der InnoDB-Logdateien -- 2 ist wahrscheinlich der einzig sinnvolle Wert. Eine große Zahl kann zu Leistungsproblemen führen.
( 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-- Verhältnis -- (siehe Protokoll)
( Uptime / 60 * innodb_log_file_size / Innodb_os_log_written ) = 181,841 / 60 * 1024M / 1773668352 = 1,834-- Minuten zwischen InnoDB-Logrotationen. Ab 5.6.8 kann dies dynamisch geändert werden; denken Sie daran, auch my.cnf zu ändern. -- (Die Empfehlung von 60 Minuten zwischen den Rotationen ist etwas willkürlich.) Passen Sie innodb_log_file_size an (jetzt 1073741824). (Kann in AWS nicht geändert werden.)
( innodb_flush_method ) = innodb_flush_method = O_DIRECT_NO_FSYNC-- Wie InnoDB das Betriebssystem auffordern soll, Blöcke zu schreiben. Schlagen Sie O_DIRECT oder O_ALL_DIRECT (Percona) vor, um doppeltes Puffern zu vermeiden. (Zumindest für Unix.) Siehe chrischandler für den Vorbehalt zu O_ALL_DIRECT
( Innodb_row_lock_time_avg ) = 1,886-- Durchschnittliche Zeit zum Sperren einer Zeile (Millisekunden) -- Möglicherweise widersprüchliche Abfragen, möglicherweise Tabellenscans.
( innodb_print_all_deadlocks ) = innodb_print_all_deadlocks = OFF-- Ob alle Deadlocks protokolliert werden sollen. -- Wenn Sie häufig von Deadlocks geplagt werden, schalten Sie diese Option ein. Achtung: Wenn Sie viele Deadlocks haben, kann dies zu einer großen Datenmenge auf der Festplatte führen.
( max_connections ) = 2,000-- Maximale Anzahl von Verbindungen (Threads). Wirkt sich auf verschiedene Zuordnungen aus. -- Wenn max_connections (derzeit 2000) zu hoch ist und verschiedene Speichereinstellungen hoch sind, kann Ihnen der RAM ausgehen.
( Handler_read_rnd_next / Com_select ) = 46,219,107,293 / 7120289 = 6,491-- Durchschnittlich pro SELECT gescannte Zeilen. (ungefähr) -- Erhöhen Sie ggf. die read_buffer_size (derzeit 131072).
( (Com_insert + Com_update + Com_delete + Com_replace) / Com_commit ) = (358564 + 419704 + 462 + 0) / 2006877 = 0.388-- Anweisungen pro Commit (alles InnoDB vorausgesetzt) -- Niedrig: Könnte hilfreich sein, Abfragen in Transaktionen zusammenzufassen; Hoch: Lange Transaktionen belasten verschiedene Dinge.
( Select_scan ) = 4,386,291 / 181841 = 24 /sec-- vollständige Tabellenscans -- Indizes hinzufügen / Abfragen optimieren (es sei denn, es handelt sich um kleine Tabellen)
( Select_scan / Com_select ) = 4,386,291 / 7120289 = 61.6%-- % der Auswahlen führen einen vollständigen Tabellenscan durch. (Kann durch gespeicherte Routinen getäuscht werden.) -- Indizes hinzufügen/Abfragen optimieren
( binlog_format ) = binlog_format = MIXED-- STATEMENT/ROW/MIXED. -- ROW wird von 5.7 (10.3) bevorzugt
( Aborted_clients ) = 175,398 / 181841 = 0.96 /sec- Threads wurden aufgrund von „wait_timeout“ hochgestuft. - Erhöhen Sie „wait_timeout“ (jetzt 28800). Seien Sie nett und verwenden Sie die Verbindung zum Server.
( Connections ) = 3,544,963 / 181841 = 19 /sec-- Verbindungen -- Wait_timeout erhöhen (jetzt 28800); Pooling verwenden?
Ungewöhnlich klein: Geöffnete_Dateien = 3
Ungewöhnlich groß: Com_do = 0,02 /HR Com_release_savepoint = 2,3 /HR Com_rollback_to_savepoint = 0,11 /Sek. 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 /Sek. Com_show_triggers = 0,11 /Sek. Created_tmp_files = 20 /Sek. Handler_read_key = 139335 /Sek. Handler_read_next = 316713 /Sek. Handler_read_rnd = 46465 / Sek. Handler_savepoint = 2,3 / HR Handler_savepoint_rollback = 0,11 / Sek. Innodb_buffer_pool_read_requests = 1095747 / Sek. 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 / Sek. Open_table_definitions = 2.000 Select_full_range_join = 2,1 / Sek. 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
Abnormale Zeichenfolgen: default_authentication_plugin = caching_sha2_password event_scheduler = EIN innodb_dedicated_server = EIN innodb_fast_shutdown = 1 optimizer_trace = aktiviert=aus,one_line=aus optimizer_trace_features = greedy_search=ein, range_optimizer=ein, dynamic_range=ein, repeated_subselect=ein slave_rows_search_algorithms = INDEX_SCAN,HASH_SCAN
sf1030756-M
Beobachtungen:
- Version: 8.0.21
- 6 GB RAM
- Betriebszeit = 5d 23:59:45
- Sind Sie sicher, dass dies ein SHOW GLOBAL STATUS war? – Oder ist diese Replik einfach nicht beschäftigt??
- Sie verwenden kein Windows.
- 64-Bit-Version wird ausgeführt
- Sie scheinen vollständig (oder größtenteils) InnoDB auszuführen.
Die wichtigeren Themen:
Wie bei der Primär -- table_open_cache, innodb_log_files_in_group,binlog_format
Überprüfen Sie das Swapping. innodb_buffer_pool_sizeIst für 6 GB RAM ziemlich groß.
Auf 100 senken max_connections– Mehr als 5 haben Sie bisher nicht verbraucht, die aktuellen 2000 belasten den Arbeitsspeicher.
Details und weitere Beobachtungen:
( table_open_cache ) = 3,995-- Anzahl der zwischenzuspeichernden Tabellendeskriptoren – Mehrere Hundert sind normalerweise gut.
( Table_open_cache_misses / (Table_open_cache_hits + Table_open_cache_misses) ) = 56,436 / (1107115 + 56436) = 4.9%-- Wirksamkeit von table_open_cache. -- Erhöhen Sie table_open_cache (jetzt 3995) und überprüfen Sie table_open_cache_instances (jetzt 16).
( innodb_lru_scan_depth * innodb_page_cleaners ) = 1,024 * 4 = 4,096-- Arbeitsaufwand für Seitenreiniger pro Sekunde. -- „InnoDB: page_cleaner: 1000 ms beabsichtigte Schleife dauerte …“ kann möglicherweise durch Verringerung von lru_scan_depth behoben werden: Erwägen Sie 1000 / innodb_page_cleaners (jetzt 4). Überprüfen Sie auch das Swapping.
( innodb_page_cleaners / innodb_buffer_pool_instances ) = 4 / 8 = 0.5-- innodb_page_cleaners – Es wird empfohlen, innodb_page_cleaners (jetzt 4) auf innodb_buffer_pool_instances (jetzt 8) einzustellen.
( innodb_lru_scan_depth ) = 1,024
- „InnoDB: page_cleaner: Die beabsichtigte Schleife dauerte 1000 ms …“ kann durch Verringern von lru_scan_depth behoben werden.
( Innodb_pages_written / Innodb_buffer_pool_write_requests ) = 25,132 / 57003 = 44.1%-- Schreibanforderungen, die auf die Festplatte gelangen mussten -- Überprüfen Sie innodb_buffer_pool_size (jetzt 5368709120)
( innodb_log_files_in_group ) = 5-- Anzahl der InnoDB-Logdateien -- 2 ist wahrscheinlich der einzig sinnvolle Wert. Eine große Zahl kann zu Leistungsproblemen führen.
( 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-- Verhältnis -- (siehe Protokoll)
( Uptime / 60 * innodb_log_file_size / Innodb_os_log_written ) = 518,385 / 60 * 512M / 22224896 = 208,704-- Minuten zwischen InnoDB-Logrotationen. Ab 5.6.8 kann dies dynamisch geändert werden; denken Sie daran, auch my.cnf zu ändern. -- (Die Empfehlung von 60 Minuten zwischen den Rotationen ist etwas willkürlich.) Passen Sie innodb_log_file_size an (jetzt 536870912). (Kann in AWS nicht geändert werden.)
( innodb_flush_method ) = innodb_flush_method = O_DIRECT_NO_FSYNC-- Wie InnoDB das Betriebssystem auffordern soll, Blöcke zu schreiben. Schlagen Sie O_DIRECT oder O_ALL_DIRECT (Percona) vor, um doppeltes Puffern zu vermeiden. (Zumindest für Unix.) Siehe chrischandler für den Vorbehalt zu O_ALL_DIRECT
( innodb_print_all_deadlocks ) = innodb_print_all_deadlocks = OFF-- Ob alle Deadlocks protokolliert werden sollen. -- Wenn Sie häufig von Deadlocks geplagt werden, schalten Sie diese Option ein. Achtung: Wenn Sie viele Deadlocks haben, kann dies zu einer großen Datenmenge auf der Festplatte führen.
( max_connections ) = 2,000-- Maximale Anzahl von Verbindungen (Threads). Wirkt sich auf verschiedene Zuordnungen aus. -- Wenn max_connections (derzeit 2000) zu hoch ist und verschiedene Speichereinstellungen hoch sind, kann Ihnen der RAM ausgehen.
( (Com_show_create_table + Com_show_fields) / Questions ) = (8605 + 17405) / 313218 = 8.3%-- Unartiges Framework – es erfordert großen Aufwand, das Schema erneut herauszufinden. -- Beschweren Sie sich beim Drittanbieter.
( tmp_table_size ) = 64M-- Begrenzung der Größe vonERINNERUNGtemporäre Tabellen zur Unterstützung einer SELECT-Anweisung – Verringern Sie die tmp_table_size (jetzt 67108864), um einen RAM-Überschuss zu vermeiden. Möglicherweise nicht mehr als 64 MB.
( Select_full_join / Com_select ) = 8,884 / 123363 = 7.2%-- % der Auswahlen, bei denen es sich um indexlose Joins handelt -- Fügen Sie den in JOINs verwendeten Tabellen geeignete Indexe hinzu.
( Select_scan / Com_select ) = 107,352 / 123363 = 87.0%-- % der Auswahlen führen einen vollständigen Tabellenscan durch. (Kann durch gespeicherte Routinen getäuscht werden.) -- Indizes hinzufügen/Abfragen optimieren
( Com_admin_commands / Queries ) = 6,755 / 320422 = 2.1%– Prozentsatz der Abfragen, die „Admin“-Befehle sind. – Was ist los?
( binlog_format ) = binlog_format = MIXED-- STATEMENT/ROW/MIXED. -- ROW wird von 5.7 (10.3) bevorzugt
( log_slow_slave_statements ) = log_slow_slave_statements = OFF-- (5.6.11, 5.7.1) Standardmäßig werden replizierte Anweisungen nicht im Slowlog angezeigt. Dies führt dazu, dass sie angezeigt werden. -- Es kann hilfreich sein, im Slowlog Schreibvorgänge anzuzeigen, die Replikat-Lesevorgänge beeinträchtigen könnten.
( thread_cache_size / Max_used_connections ) = 28 / 5 = 560.0%
- Es hat keinen Vorteil, den Thread-Cache größer zu machen als die wahrscheinliche Anzahl Ihrer Verbindungen. Der Nachteil ist die Platzverschwendung.
( thread_stack * max_connections ) = (286720 * 2000) / 6144M = 8.9%-- Absolut minimale Speicherzuweisung für max_connections. -- Niedrigere max_connections (jetzt 2000)
Ungewöhnlich klein: Bytes_received = 58 / Sek. Com_insert = 0 Com_update = 0 Created_tmp_files = 0,035 / HR Handler_update = 2,2 / HR Innodb_buffer_pool_write_requests = 0,11 / Sek. Innodb_buffer_pool_write_requests / Innodb_buffer_pool_pages_flushed = 2,27 Innodb_dblwr_pages_written / Innodb_dblwr_writes = 1 Innodb_pages_created = 1 / HR Innodb_rows_deleted + Innodb_rows_inserted = 0 Innodb_rows_inserted = 0 Innodb_rows_updated = 0 Select_range = 0 Select_range / Com_select = 0
Ungewöhnlich groß: 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 Backlog / 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_Länge_für_Sortieren_Daten = 4.096 optimizer_trace_offset = --1 Performance_Schema_Error_Size = 4.772 performance_schema_max_cond_classes = 100 performance_schema_max_mutex_classes = 300 performance_schema_max_rwlock_classes = 60 performance_schema_max_stage_classes = 175 performance_schema_max_statement_classes = 218 performance_schema_max_thread_classes = 100
Abnormale Zeichenfolgen: default_authentication_plugin = caching_sha2_password event_scheduler = EIN innodb_dedicated_server = EIN innodb_fast_shutdown = 1 optimizer_trace = aktiviert=aus,one_line=aus optimizer_trace_features = greedy_search=ein, range_optimizer=ein, dynamic_range=ein, repeated_subselect=ein read_only = EIN slave_rows_search_algorithms = INDEX_SCAN,HASH_SCAN
sf1030756-S