MySQL、my.cnf和/etc/替代品

Question

历史(以下问题是2020年)

2018年。两年前，在新安装了18.04之后，我想使用16.04中的/etc/mysql/my.cnf安装程序，让事情回到原来的样子。但是MySQL安装设置了两个符号链接

• /etc/mysql/my.cnf -> /etc/alternatives/my.cnf
• /etc/alternatives/my.cnf -> /etc/mysql/mysql.cnf

因此，我将新的/etc/mysql/mysql.cnf替换为原来的16.04 /etc/mysql/my.cnf。

直到另一次MySQL更新，由于某些原因，我的mysql.cnf被新的更新所取代，一切都很顺利。窃听器？我接受替换了吗？别这么想，但是，那总是有可能的。

因此，当时我所做的就是绕过替代系统，即用我的/etc/mysql/my.cnf文件替换my.cnf链接，并将mysql.cnf归零。由于my.cnf优先于工作的mysql.cnf (我想我试图将mysql.cnf链接到我的my.cnf文件，还有其他麻烦，不记得了)。

(老实说，我不太喜欢我发现的替代实现，既繁琐又有违直觉)

2020年。从18.04升级到20.04。自然地，MySQL重新创建了一个干净的环境，并提供了替代链接。好的。

然而，为了完成升级，这一次我希望保持清洁，并尽可能多地

• 继续使用替代系统或不使用(取决于您的建议)
• 确保进一步的MySQL升级(除非是第9节)不会覆盖我的设置(或者它会要求)

保持MySQL安装干净的推荐方法是什么？

Answer 1

(老实说，我不太喜欢我发现的替代实现，既繁琐又有违直觉)

替代系统并不是MySQL特有的；它是一个通用系统，在Debian和Ubuntu中广泛使用。我建议你学习它是如何工作的，以及如何与它集成。它的目的是让用户完全控制-这样，他们可以完全覆盖包装，如果他们愿意，或与它集成，如果他们想要的好处，包装提供。

有关细节，请参阅更新-备选方案(1)手册。

如果您有一个希望无论如何使用的特定my.cnf，那么您可以将它添加到某个地方，并使用update-alternatives来选择它的优先级，而不是打包提供的任何东西。然后，它将集成，永远不会被覆盖。

但是，如果您这样做，请理解将来升级Ubuntu时您的my.cnf可能会失败，因为可用的配置指令随着主要MySQL版本的变化而改变。随着my.cnf的变化，您需要保持自己的MySQL更新。

如果您想要打包以帮助您，那么您可以按照@Matigo在其答案中的建议进行操作，并且只使用.d目录添加重写。在可行的情况下，我们安排打包以自动调整配置，以避免在发布升级期间破坏MySQL。但是，我们通常只在附带的文件打包时这样做，而不是针对您自己添加的文件。

最终，虽然与打包配置默认值不同是完全合理的，但在Ubuntu版本之间升级时，有必要对配置进行调整，因为MySQL对主要MySQL版本之间的配置变化的期望。