主页 / ubuntu / 问题 / 1283364
Accepted
Déjà vu
Asked: 2020-10-13 23:35:00 +0800 CST

MySQL、my.cnf 和 /etc/alternatives

  • 772

历史（下面的问题是2020年）

2018 年。在两年前全新/etc/mysql/my.cnf安装 18.04 之后，我想使用16.04 中的设置让一切恢复原状。但是 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 升级（除非它是 v. 9）不会覆盖我的设置（或者它要求）

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

configuration mysql 20.04 update-alternatives

2 个回答

  1. Best Answer

    从 3. something的毛茸茸的日子开始使用 MySQL ，我发现设置环境变量的最佳位置是在单独的.cnf文件中。使用现代版本的数据库（从 5.3 开始），这些可以写入/etc/mysql/mysql.conf.d/目录。这允许我有一个目录结构，如：

    drwxr-xr-x 2 root root 4096 Aug  6 23:08 ./
drwxr-xr-x 4 root root 4096 Aug  6 23:08 ../
-rw-r--r-- 1 root root 1434 Jun 27  2019 mysqld.cnf
-rw-r--r-- 1 root root  155 Jun 27  2019 z-application.cnf
-rw-r--r-- 1 root root 2893 Jun 27  2019 z-innodb.cnf
-rw-r--r-- 1 root root 1464 Jun 27  2019 z-replication.cnf

    配置文件按字母顺序阅读，这解释了丑陋的z-前缀，文件的目的非常不言自明：

    文件 包含
    application.cnf 特定于应用程序的设置，例如最大连接数、日志过期时间等。
    innodb.cnf 特定于 InnoDB 的设置，通常会随着时间针对服务器运行的硬件进行调整
    replication.cnf 特定于复制的设置。

    这使我可以拥有一堆.cnf模板文件，其中包含预先填充的基础知识，并准备好为新的 MySQL 安装使用/定制。

    关于这种做法背后的推理的一点背景......

    MySQL 根据安装的平台以非常特殊的顺序读取配置文件。您可以通过以下方式向 MySQL 询问配置文件的名称和顺序：

    mysqld --help --verbose

    这将吐出（对我而言）3,000 多行，但在顶部附近，您会看到：

    Default options are read from the following files in the given order:
/etc/my.cnf /etc/mysql/my.cnf ~/.my.cnf 
The following groups are read: mysqld server mysqld-8.0

    对我来说，没有/etc/my.cnf文件。但是，有一个/etc/mysql/my.cnf文件。在该文件中只有两行重要：

    !includedir /etc/mysql/conf.d/
!includedir /etc/mysql/mysql.conf.d/

    这样，MySQL 将搜索 中的所有.cnf文件/etc/mysql/conf.d/，然后搜索 中的所有文件/etc/mysql/mysql.conf.d/，按字母顺序将它们读入引擎。我更喜欢在读取所有默认 MySQL 文件后加载我的变量，因为它减少了我的值被默认值覆盖的机会。所以，因为/etc/mysql/mysql.conf.d/在 之后/etc/mysql/conf.d/，我的文件进入了那里。

    它们从未在更新期间被覆盖或修改。

    希望这能给你一些探索的东西。

    • 1

  2. （老实说，我不太喜欢我发现的替代实现，既麻烦又违反直觉）

    替代系统不是特定于 MySQL 的。它是一个通用系统，用于 Debian 和 Ubuntu 中的各种软件包。我建议您了解它的工作原理以及如何与之集成。它旨在为用户提供完全控制权——因此，如果他们愿意，他们可以完全覆盖包装，或者如果他们想要包装提供的好处，则可以与之集成。

    有关详细信息，请参见update-alternatives(1) 联机帮助页。

    如果您有一个无论如何都想使用的特定my.cnf对象，那么您可以将其添加到某处并使用update-alternatives它以比包装提供的任何内容更高的优先级选择它。然后它将集成并且永远不会被覆盖。

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

    相反，如果您希望打包来提供帮助，那么您可以按照@Matigo 在他们的回答中建议的操作，并仅使用.d目录添加覆盖。在可行的情况下，我们安排打包以自动调整配置，以避免在版本升级期间破坏 MySQL。但是，我们通常只对发送的文件打包执行此操作，而不是您自己添加的文件。

    最终，虽然与打包配置默认值不同是完全合理的，但当您在 ​​Ubuntu 版本之间升级时，必须预期必须调整配置，因为 MySQL 对主要 MySQL 版本之间的配置更改的期望。

    • 1

相关问题