我正在嘗試備份在 k8s 集群（k3s）中運行的 MySQL 資料庫。該集群在 Raspberry Pi 上本地運行。我已經構建了一個基于 Alpine Linux 的自定義映像，其中包含一個使用 mysqldump 創建備份的腳本：
kubectl exec <pod_name> -n <namespace_name> -- /usr/bin/mysqldump -u <db_user> --password=<db_password> --verbose <db_name> > <file_name>
當我從資料庫 pod 內部運行 mysqldump 命令時，它會在 10-15 秒后成功完成。但是，當從 Alpine pod 內部執行此命令時，不知何故需要更長的時間（2 分 40 秒）。此時它停止/中止 kubectl exec 命令（由于超時？）并且腳本上傳損壞的 sql 檔案，因為 mysqldump 命令未完成備份。
預期的詳細輸出：
-- Connecting to localhost...
-- Retrieving table structure for table _prisma_migrations...
-- Sending SELECT query...
-- Retrieving rows...
-- Retrieving table structure for table database...
-- Sending SELECT query...
-- Retrieving rows...
-- Retrieving table structure for table recycleBin...
-- Sending SELECT query...
-- Retrieving rows...
-- Retrieving table structure for table user...
-- Sending SELECT query...
-- Retrieving rows...
-- Disconnecting from localhost...
收到詳細輸出：
-- Connecting to localhost...
-- Retrieving table structure for table _prisma_migrations...
-- Sending SELECT query...
-- Retrieving rows...
-- Retrieving table structure for table database...
-- Sending SELECT query...
-- Retrieving rows...
-- Retrieving table structure for table recycleBin...
-- Sending SELECT query...
-- Retrieving rows...
我有兩個問題：
- 與資料庫 pod 相比，為什么 mysqldump 命令在 Alpine pod 中花費的時間要長得多？
- 為什么 kubectl exec 命令不等到 mysqldump 命令完成備份？為什么它突然決定是時候斷開連接并繼續前進了？
uj5u.com熱心網友回復：
您可能會斷開連接，因為kubectl認為由于另一端沒有資料而導致連接已失效。
代替：
kubectl exec <pod_name> -n <namespace_name> -- /usr/bin/mysqldump -u <db_user> --password=<db_password> --verbose <db_name> > <file_name>
嘗試：
kubectl exec <pod_name> -n <namespace_name> -- /usr/bin/mysqldump -u <db_user> --password=<db_password> --verbose <db_name> | tee <file_name>
這將改為輸出到標準輸出以及發送到檔案。這將保證 kubectl 會看到資料回傳，并且如果這是一個無資料問題，它不會斷開您的連接。這樣做的缺點是您將在標準輸出上將整個 SQL 資料泵回給您
另一種選擇（也是我個人推薦的一種）是安裝類似screen或tmux或另一個終端多路復用器并在其中進行轉儲，這樣您就可以斷開與 pod 的連接，而不必擔心 kubectl 會斷開您的連接。
編輯：澄清一下，我的意思是在 pod 內安裝多路復用器（例如，在用于創建 pod 的 docker 映像內）
轉載請註明出處，本文鏈接：https://www.uj5u.com/net/472492.html
標籤：Kubernetes k3s