關於在 Docker 中使用 MySQL、日誌記錄選項的一般問題
在將 MySQL 與 Docker 一起使用時，我有很多關於日誌記錄/備份策略的問題，也只是一般問題。
特定場景是小型醫療診所的 MySQL DB，目前的安排顯然是使用多種方法來備份數據。主機系統是 UBUNTU，應用程序文件和數據幾乎完全通過位於系統 RAID 上的 Docker 包執行，因此 MySQL 引擎是 docker image: mysql:8.0.26。
- 一種雲備份服務，對整個 docker-compose 項目文件夾進行增量雲備份，包括映射到主機上的捲的 DB 文件。這是災難恢復的最後手段。從未在模擬場景（如颶風或火災）中實際進行過試執行測試。
- CRON 作業腳本通過從主機執行的 CRON 腳本執行輪流精簡的每日 DB 轉儲。這些儲存在主機系統 SSD 以及本地的 NAS 設備上。
- Docker mysql:8.0.26 顯然預設啟用了 bin 日誌記錄，因此它一直處於活動狀態，儘管我認為它們每 30 天輪換一次，因為預設設置有效，而且我認為沒有人真正看過那些或使用它們。
- 正常日誌記錄已關閉（顯然預設情況下）。
看起來可以使用以下命令在 docker-compose 中打開一般日誌記錄：
command: --general-log=TRUE --general-log-file=/var/lib/mysql/mysql-log.log顯然可以使用以下命令獲取 docker 的可用選項列表：
docker run -it --rm mysql:tag --verbose --help這個站點上有一個參考： MySQL Logging Options
這涵蓋了 MySQL 的一些日誌記錄選項（如下）。
只是想知道什麼是最好的方法，因為應用程序的 DB 已經保留了一些專用表來記錄一些更敏感的 DB 事務（即，誰更改了什麼以及何時更改，使用 user_id，ip in case 等）好像一般日誌和二進制日誌不會有這些資訊？更好的方法可能是禁用 bin 日誌記錄（目前沒有複製伺服器），只要數據庫中有表以更詳細的方式記錄類似資訊，就可以關閉正常日誌記錄？
我正在查看現有的 binlog 文件，其中一些非常大，因為有些表有 blob，如果啟用了正常日誌記錄，情況可能也是如此。
迄今為止，數據庫錯誤、數據失去等問題很少，在大多數情況下，雲備份和本地數據庫轉儲似乎就足夠了。轉儲已在數據完整性和從轉儲快速恢復的能力（目前大約 500 MB 未壓縮）方面進行了多次測試。
所以主要問題：
1. 在撰寫文件中有沒有辦法讓它為 mysql-log.log 文件名添加一個日期？，使用 –general-log-file=/var/lib/mysql/mysql-log.log 可能還有一個ENV變數還是什麼？
2. 二進制日誌和通用日誌真的有必要使用嗎？
我有一個開發系統，我可以在其中玩所有這些。我有點猶豫是否要關閉二進制日誌，然後自己刪除二進制日誌文件，但我想我可以在開發系統上嘗試一下，看看會發生什麼。這將釋放相當多的空間並消除一些混亂。
（這個問題問的太多了。我會給出答案的概述。如果下面的資訊不能提供足夠的資訊，請開始一個新的、更具體的問題。但首先，用我給出的提示做一些研究。）
binlog - 開啟
一般日誌 - 關閉慢日誌
- 見下文
如果在備份期間不停止，我不會信任文件
mysqld備份。RAM 中發生的事情太多，以至於無法相信您可以在磁碟上找到的內容。至少在轉儲期間伺服器需要停頓。（最好通過簡單地停止 mysqld 來完成。）備份在同一棟樓中並不能避免嚴重的“災難”。
有多種方法可以使用
binlog“增量”轉儲。但是您將需要定期進行“完整”轉儲。“一般日誌”很快就填滿了磁碟；僅用於某些調試任務。“慢日誌”可以（通常）一直打開，帶有
long_query_time = 1. 但它對災難恢復沒有用。我更喜歡將大多數設置放在“my.cnf”配置文件中，而不是放在
mysqld命令行中。通用日誌記錄所有查詢。binlog 記錄所有寫入。每個人都沒有註意到查詢的意圖。
在 Linux 中，您可以在腳本中編造文件名。查看命令中可用的選項
date。是的，Linux 在 shell 腳本中有“變數”。而且，是的，--general-log-file在命令行上設置而不是my.cnf. 但是，請記住，通用日誌不是備份或災難保護的好工具。另請參閱
SET GLOBAL VARIABLE PERSIST...作為一種無需重新啟動 mysqld 即可進行更改的方法。另請參閱
FLUSH LOGS;作為停止一個日誌文件並啟動另一個日誌文件的方法。要自動清除“舊”二進制日誌，請設置
...expire...為幾週後刷新。