InnoDB:由於 1 個掛起的操作,無法關閉文件 ./tablefile.ibd
MariaDB 版本:‘10.5.13-9
我正面臨從舊的舊數據環境到 DBaaS 容器環境的多次不成功的數據遷移(複製)嘗試。使用帶有管道的 mysqldump 執行此數據遷移,以在我的容器中恢復,該容器在 pid 1 的無根 podman 中執行。MariaDB 指出,此問題按版本 10.5.13-9 排序。他們無法重現此錯誤。無法找到 InnoDB 繼續記錄的原因
$$ Note $$InnoDB:由於 1 個掛起的操作,無法關閉文件。 啟用 coredump 來分析錯誤,我的錯誤日誌寫道:Writing a core file… Working directory at /var/lib/mysql 但我找不到核心文件。無法找到背後的原因。
我什至嘗試使用以下參數使用 podman 創建容器。但沒有運氣。–ulimit core=-1 –privileged
–security-opt seccomp=unconfined \
瑪麗亞數據庫
$$ (none) $$> 顯示全域狀態,如“%pending%”;+—————————–+——–+ | 變數名 | 價值 | +—————————–+——–+ | Innodb_data_pending_fsyncs | 0 | | Innodb_data_pending_reads | 0 | | Innodb_data_pending_writes | 0 | | Innodb_os_log_pending_fsyncs | 0 | | Innodb_os_log_pending_writes | 0 | +—————————–+——–+ 5 行(0.001 秒)
MariaDB [(none)]>
錯誤日誌:
2022-01-25 11:19:05 0
$$ Note $$mysqld:準備連接。版本:‘10.5.13-9-MariaDB-enterprise-log’ 套接字:’/var/run/mysqld/mysqld.sock’ 埠:53805 MariaDB Enterprise Server 2022-01-25 11:27:26 14$$ Note $$啟動binlog_dump到slave_server(52396), pos(mysqld-bin.000001, 369), using_gtid(0), gtid(’’) 2022-01-25 11:38:06 15$$ Note $$InnoDB:無法關閉文件 ./pptdatabase/fallback_stf_stat_availability_sweeper_valuecritanytype#P#p736783.ibd 因為 1 個掛起的操作。. . . . 2022-01-25 14:11:30 15
$$ Note $$InnoDB:無法關閉文件 ./pptdatabase/stf_stat_availability_externalcall_avl_hist#P#p738548.ibd,因為有 1 個掛起的操作 220125 14:11:32$$ ERROR $$mysqld 得到信號 11 ;這可能是因為您遇到了錯誤。此二進製文件或與之鍊接的庫之一也可能已損壞、建構不正確或配置錯誤。此錯誤也可能是由硬體故障引起的。 要報告此錯誤,請參閱https://mariadb.com/kb/en/reporting-bugs
我們將盡最大努力收集一些資訊,希望能幫助診斷問題,但由於我們已經崩潰了,有些地方出了問題,這可能會失敗。
伺服器版本:10.5.13-9-MariaDB-enterprise-log key_buffer_size=134217728 read_buffer_size=2097152 max_used_connections=13 max_threads=1502 thread_count=13 mysqld可能最多可以使用key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 9397787 K記憶體字節希望沒關係;如果不是,減少方程中的一些變數。
執行緒指針:0x0 正在嘗試回溯。您可以使用以下資訊找出 mysqld 死在哪裡。如果您在此之後沒有看到任何消息,則說明出現了嚴重錯誤… stack_bottom = 0x0 thread_stack 0x49000 addr2line: ‘mysqld’: No such file mysqld(my_print_stacktrace+0x2e)
$$ 0x563b87eb047e $$ 列印到 addr2line 失敗 mysqld(handle_fatal_signal+0x485)$$ 0x563b8792b425 $$ sigaction.c:0(__restore_rt)$$ 0x7f943ec57b20 $$ addr2line: ‘mysqld’: 沒有這樣的文件 mysqld(+0xdfc944)$$ 0x563b87dc9944 $$ mysqld (+ 0xdfd881)$$ 0x563b87dca881 $$ mysqld(+0x652bdd)$$ 0x563b8761fbdd $$ mysqld (+ 0xe1086a)$$ 0x563b87ddd86a $$ pthread_create.c:0(start_thread)$$ 0x7f943ec4d14a $$ :0(__GI___複製)$$ 0x7f943e061dc3 $$https://mariadb.com/kb/en/how-to-produce-a-full-stack-trace-for-mysqld/ 的手冊頁包含可以幫助您找出導致崩潰的原因的資訊。編寫核心文件… /var/lib/mysql 資源限制處的工作目錄: 增加緩衝池後的另一次嘗試,日誌文件大小和日誌緩衝區也重新生成相同。Inndob 不斷記錄此註釋消息。default_storage_engine = InnoDB的innodb_buffer_pool_size = 15G innodb_log_file_size = 10G innodb_log_buffer_size = 10G innodb_file_per_table = 1 innodb_open_files = 800 innodb_io_capacity = 15000 innodb_read_io_threads = 10 innodb_write_io_threads = 20 innodb_flush_method = O_DIRECT#可以是FSYNC O_DSYNC O_DIRECT的innodb_flush_log_at_trx_commit = 1
錯誤日誌:
版本:‘10.5.13-9-MariaDB-enterprise-log’ 套接字:’/var/run/mysqld/mysqld.sock’ 埠:53805 MariaDB Enterprise Server 2022-01-26 0:06:27 14
$$ Note $$啟動binlog_dump到slave_server(52396), pos(mysqld-bin.000001, 369), using_gtid(0), gtid(’’) 2022-01-26 0:17:58 16$$ Note $$InnoDB:無法關閉文件。. ./pptdatabase/stf_stat_availability_office_bench_aws_mhist.ibd 因為有 1 個待處理的操作
信號 11 (SIGSEGV) 看起來像一個錯誤。您能否將它送出到 MariaDB 錯誤跟踪器中,針對 10.5.13 版本,並提供盡可能多的詳細資訊?如果可能,嘗試通過在伺服器崩潰之前將調試器附加到伺服器,或通過啟用核心轉儲並在核心轉儲上呼叫調試器來生成已解決的崩潰堆棧跟踪。
在我們的內部測試中,我們沒有看到任何類似的崩潰,但話又說回來,我們通常使用少量數據在 RAM 磁碟上執行壓力測試。
該場景類似於MDEV-25215的場景,並且修復了最初報告的錯誤(“無法關閉”的過度日誌記錄,每秒數次)。
場景是需要關閉一些文件,以免超過打開文件的最大數量。我們不允許關閉正在等待寫入或 fdatasync() 的文件句柄。我認為同時,日誌檢查點必須正在進行中。較大的 innodb_log_file_size 應該會降低日誌檢查點的頻率。
如果要測試最新的 MariaDB(非企業)伺服器 10.5,可以使用
quay.io/mariadb-foundation/mariadb-debug:10.5
包含調試符號和調試器的。初始化數據目錄後:
podman run -ti -v db105:/var/lib/mysql --user mysql \ --cap-add CAP_SYS_PTRACE --name mdb105 \ quay.io/mariadb-foundation/mariadb-debug:10.5 \ gdb --args mysqld
做你需要觸發你的錯誤:
當您獲得 SEGV 時:
(gdb) set logging file /var/lib/mysql/gdb_output.txt (gdb) set pagination off (gdb) set logging on Copying output to /var/lib/mysql/gdb_output.txt. Copying debug output to /var/lib/mysql/gdb_output.txt. (gdb) thread apply all bt -frame-arguments all full
在它全部停止之後:
podman cp mdb105:/var/lib/mysql/gdb_output.txt /tmp podman cp mdb105:/manifest.txt /tmp
並將這兩項放在錯誤報告/支持票中。
清單包含有關建構它的確切原始碼版本的資訊。