☰

Mysql從站停止並無法初始化中繼日誌

tag-icon • tag-icon mysql mysql-replication
Mysql從站停止並無法初始化中繼日誌

幾天前，我設定了一個從屬 MySQL 伺服器（Mysql Community Server 8.0.21）。到目前為止，我們僅將其用於使用 mysqldump 進行備份。我確實注意到他使用了太多內存，但我並不介意，因為我使用了一些配置參數來自動調節他將使用的內存量，並且 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

唉，變數/狀態沒有顯示您遇到的問題的任何明顯原因。 或許高 buffer_pool_size 過度擠壓 RAM，但我對此表示懷疑。以下是我的分析（主要，然後是副本）：

觀察結果：

  • 版本：8.0.20
  • 16 GB 內存
  • 正常運轉時間 = 2d 02:30:41
  • 您沒有在 Windows 上執行。
  • 運行64位元版本
  • 您似乎完全（或大部分）運行InnoDB。

更重要的問題：

table_open_cache如果作業系統允許的話可以增加。怎麼這麼多桌子？

我認為（沒有任何證據）使用除“2”以外的任何東西都是不明智的，因為innodb_log_files_in_group MariaDB 已經忽略了它；我沒聽過甲骨文。

有一些跡象顯示查詢的表述不當。看http://mysql.rjweb.org/doc.php/mysql_analysis#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_深度來修復

( 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 應該如何要求作業系統寫入區塊。建議使用 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-- 是否記錄所有死鎖。 -- 如果您受到死鎖的困擾，請開啟此功能。注意：如果存在大量死鎖，這可能會向磁碟寫入大量資料。

( 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);使用池化？

異常小： 開啟文件數 = 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_trigger = 0.12 /HR Com_show_function_status = 2.5 /HR com_show_procedure_status = 2.5 /HR Com_show_table_status = 0.11 /秒Com_show_triggers = 0.11 /秒Created_tmp_files = 20 /秒Handler_read_key = 139335 /dlerHandler_20 /dler1670 _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 /secig_table_definitions = rows_updated = 0.095 /secig_table_definitions = 1,095_6n_p. / 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 innoth_write_io_iothread_write 64 最大錯誤計數= 1,024 排序資料的最大長度= 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 =greedy_search on， _rows_search_algorithms =掃描

sf1030756-M

觀察結果：

  • 版本：8.0.21
  • 6 GB 內存
  • 正常運轉時間 = 5 天 23:59:45
  • 您確定這是「顯示全球狀態」嗎？ -- 還是這個副本根本不忙？
  • 您沒有在 Windows 上執行。
  • 運行64位元版本
  • 您似乎完全（或大部分）運行InnoDB。

更重要的問題：

與初級 - table_open_cache, innodb_log_files_in_group,binlog_format

檢查是否有交換。 innodb_buffer_pool_size對於 6GB RAM 來說相當大了。

低於max_connections100 -- 到目前為止您使用的次數不超過 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_深度來修復

( 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 應該如何要求作業系統寫入區塊。建議使用 O_DIRECT 或 O_ALL_DIRECT (Percona) 以避免雙緩衝。 （至少對於 Unix 而言。）有關 O_ALL_DIRECT 的警告，請參閱 chrischandler

( innodb_print_all_deadlocks ) = innodb_print_all_deadlocks = OFF-- 是否記錄所有死鎖。 -- 如果您受到死鎖的困擾，請開啟此功能。注意：如果存在大量死鎖，這可能會向磁碟寫入大量資料。

( max_connections ) = 2,000-- 最大連線數（執行緒）。影響各種分配。 -- 如果 max_connections（現在為 2000）太高且各種記憶體設定都很高，則可能會耗盡 RAM。

( (Com_show_create_table + Com_show_fields) / Questions ) = (8605 + 17405) / 313218 = 8.3%-- 頑皮的框架 -- 花費大量精力重新發現模式。 -- 向第三方供應商投訴。

( tmp_table_size ) = 64M-- 大小限制記憶用於支援 SELECT 的臨時表 - 減少 tmp_table_size（現在為 67108864）以避免耗盡 RAM。也許不超過64M。

( Select_full_join / Com_select ) = 8,884 / 123363 = 7.2%-- 無索引連線的選擇百分比 -- 將適當的索引新增至連線中使用的資料表。

( Select_scan / Com_select ) = 107,352 / 123363 = 87.0%-- 執行全表掃描的選擇百分比。 （可能會被儲存例程愚弄。） -- 新增索引/最佳化查詢

( Com_admin_commands / Queries ) = 6,755 / 320422 = 2.1%-- 作為「管理」指令的查詢的百分比。 - 這是怎麼回事？

( 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 /秒Com_insert = 0 Com_update = 0 Created_tmp_files = 0.035 /HR Handler_update = 2.2 /HR Innodb_buffer_pool_write_requests = 0.11 /secdVolstal_buffer_dad_c​​ooo​​; odb_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+707,005,0705s def / max_connections = 1 00.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 = --1 Performance_schema_error_size = 4,772 Performance_schema_max_cond_類60 Performance_schema_max_stage_classes = 175 schema_max_statement_classes = 218 Performance_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 =greedy_search on， _only = ON Slave_rows_search_algorithms = CAN,HASH_SCAN

sf1030756-S

相關內容