关于与Docker一起使用MySQL的一般问题，日志记录选项

Question

当MySQL与Docker一起使用时，我有很多关于日志/备份策略的问题，而且也只是一般性的问题。

特别的场景是小型医疗诊所的MySQL DB，目前的安排显然是使用许多方法来备份数据。主机系统是UBUNTU，应用程序文件和数据几乎完全通过位于系统RAID上的Docker包运行，因此MySQL引擎是docker映像: mysql:8.0.26。

1. 云备份服务，用于对整个对接器-组合项目文件夹进行增量云备份，包括映射到主机上卷的DB文件。这是为了作为灾后恢复的最后手段。在模拟场景中，从来没有像飓风或火灾那样被测试为一次模拟运行。
2. CRON作业脚本，通过运行在主机上的CRON脚本，每天执行数据库转储，这些转储是轮流进行的。这些存储在主机系统SSD以及本地位置的NAS设备上。
3. Docker :8.0.26显然默认启用了bin日志记录，因此它一直处于活动状态，尽管我认为它们每30天轮转一次，因为默认设置是有效的，而且我认为没有人真正查看或使用过这些日志记录。
4. 一般日志记录被关闭(在默认情况下显然是这样)。

它看起来一般的日志可以打开在码头-撰写使用：

command:
  --general-log=TRUE
  --general-log-file=/var/lib/mysql/mysql-log.log

显然，您可以通过以下方法获得一个可供停靠者选择的列表：

docker run -it --rm mysql:tag --verbose --help

在这个站点上有一个参考：MySQL日志记录选项

它涵盖了MySQL的一些日志记录选项(如下所示)。

只是想知道最好的方法是什么，因为应用程序的DB已经保留了一些专用表来记录一些更敏感的DB事务(例如，谁改变了什么，什么时候，使用user_id，ip等)。似乎普通日志和二进制日志不会有这些信息吗？一种更好的方法可能只是禁用bin日志记录(目前没有复制服务器)，并且只要DB中有表以更详细的方式记录类似的信息，就不需要常规日志记录。

我查看了现有的binlog文件，其中一些文件相当大，因为其中一些表有blobs，如果启用常规日志记录，可能也是如此。

到目前为止，关于DB错误、丢失数据等的问题非常少，似乎云备份和本地DB转储在大多数情况下都是足够的。转储已经在数据完整性和从转储(目前约500 MB未压缩)中快速恢复的能力方面进行了多次测试。

因此，主要问题：

--general-log-file=/var/lib/mysql/mysql-log.log 1.在复合文件中是否有一种方法可以让它为mysql-log.log文件名添加日期?，使用

，或者使用ENV变量什么的?

2.是否真的有必要使用二进制日志和普通日志.

我有一个开发系统，在那里我可以玩所有这些。我有点犹豫要关掉二进制日志，然后删除binlog文件本身，但是我想我可以尝试一下dev系统，看看会发生什么。这样会腾出相当多的空间，并消除一些杂乱。

Answer 1

这个问题问的东西太多了。我将概述这些问题的答案。如果下面的信息没有提供足够的信息，请开始一个新的、更具体的问题。但是首先，用我给出的提示做一些调查。)

双点登录

一般注销

慢速日志-见下文

在备份期间，如果不停止mysqld，我就不会信任文件备份。内存中有太多内容无法信任您在磁盘上找到的内容。至少在转储过程中服务器需要保持安静。(这最好通过简单地阻止mysqld来完成。)

在同一栋大楼内的备份不安全，以免发生严重的“灾难”。

有一些方法可以将binlog用于“增量”转储。但是你将需要一个“完整的”定期转储。

“通用日志”非常快地填满了磁盘，只用于某些调试任务。“慢速日志”(通常)可以一直保持在long_query_time = 1上。但是，它对灾难恢复并没有用处。

我更喜欢将大多数设置放在"my.cnf“配置文件中，而不是放在mysqld命令行上。

一般日志记录所有查询。二进制日志记录全部写入。每个人都忽略了查询的意图。

在Linux中，您可以在脚本中编写文件名。请参阅date命令中可用的选项。是的，Linux在shell脚本中有“变量”。而且，是的，在命令行上设置--general-log-file而不是my.cnf是有意义的。但是，请记住，一般日志不是备份或灾难保护的好工具。

还请参阅SET GLOBAL VARIABLE PERSIST...作为一种不重新启动mysqld进行更改的方法。

还请参阅FLUSH LOGS;作为停止一个日志文件和启动另一个日志文件的方法。

若要自动清除“旧”绑定日志，请将...expire...设置为在几周后刷新。