更改 mysql 中的默认 my.cnf 路径
我在同一台机器上有两个 mysql 实例。安装位于 /usr/loca/mysql1 和 /usr/local/mysql2 上。
我有单独的 my.cnf 文件位于 /etc/mysql1 和 /etc/mysql2 中。我使用源代码分发和 --prefix=/usr/local/mysql1 选项安装了 sql 的第一个实例。第二个是我通过将同一目录复制并粘贴到 /usr/local/mysql2 获得的。
当我在 /usr.local/mysql/libexec 上启动 mysql 守护进程时，它会读取 /etc/mysql1 中的 my.cnf 文件。如果我在 /usr/local/mysql2 中启动 mysql 守护进程，它会读取相同的 my.cnf 文件。我在这两个位置的 .cnf 文件中定义了单独的端口号和 .sock 文件。
我可以在 mysqld 启动时使用 --defaults-file=/etc/mysql2/my.cnf 选项读取第二个位置的 my.cnf 文件。我不需要每次启动守护进程时都输入此内容。
如果我要拥有更多实例，我如何才能指向正确的 my.cnf 文件来读取每个 mysql 守护进程。 mysqld 与 my.cnf 文件的链接背后的原理是什么。
我如何为每个实例预定义 my.cnf 文件的位置。
I am having two mysql instances on same machine. The installations are on /usr/loca/mysql1 and /usr/local/mysql2.
I m having separate my.cnf files located in /etc/mysql1 and /etc/mysql2. I installed the first instance of my sql using source distribution and with the --prefix=/usr/local/mysql1 option. The second one i got from copying and pastinf the same directory to /usr/local/mysql2.
When i start the mysql daemon on /usr.local/mysql/libexec it reads the my.cnf file in /etc/mysql1. And if i start the mysql daemon in /usr/local/mysql2 it reads the same my.cnf file. I have separate port numbers and .sock files defined in the .cnf file in those 2 locations.
I can read the my.cnf file in the second location by using --defaults-file=/etc/mysql2/my.cnf option on mysqld startup. I do not need to enter this each and every time i start the daemon.
If i am going to have more instances how can i point the correct my.cnf file to read to each and every mysql daemon. What is the retionale behind mysqld links with the my.cnf file.
how can i predefine the location of my.cnf file for each instance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
正如您已经发现的，MySQL 有一个为其配置文件编译的搜索位置。尽管您可以自己重新编译并更改此设置，但您还发现了 mysqld 的 --defaults-file 选项，该选项指示它使用完全不同的配置路径。与--data-dir结合使用，这意味着您可以启动绑定到不同端口（和地址，如果喜欢）的多个MySQL实例，并使用完全独立的数据集，同时处理相同的二进制文件和图书馆。
传统上，大多数操作系统发行版都会捆绑一个 init 脚本来启动 MySQL 的“默认”实例；也就是说，安装在“通常”位置并具有标准配置路径的那个。尽管这是为了满足最常见的情况，但您所追求的有点不同，因此您需要创建单独的脚本来启动单独的实例。
如果您计划在同一台机器上部署大量 MySQL 实例（我不得不问为什么），那么您可能需要编写一个自定义初始化脚本，它有某种方式“发现”每个实例（也许通过检查某个包含“通用”布局的目录），然后循环它们，启动每个目录。当然，相同的初始化脚本需要能够定位并正确关闭每个脚本。
As you've already discovered, MySQL has a compiled-in search location for its configuration file. Although you could recompile yourself, changing this, you've also discovered the --defaults-file option to mysqld, which instructs it to use an entirely different configuration path. Coupled with --data-dir, this means you can start multiple instances of MySQL bound to different ports (and addresses, if liked) and working with entirely separate sets of data, while working off the same binaries and libraries.
Traditionally, most operating system distributions will bundle a single init script for starting the "default" instance of MySQL; that is, the one installed in the "usual" location, and with the standard configuration path. Although this is to cater for the commonest case, what you're after is a bit different, so you'll need to create separate scripts to launch the separate instances.
If you're planning on deploying a lot of MySQL instances on the same machine (and I'd have to ask why), then you may want to write a custom init script which has some way of "discovering" each of these (perhaps by inspecting some directory containing a "common" layout), and then loops over them, starting each one up. Of course, the same init script then needs to be capable of locating and properly shutting down each one.
我认为唯一可靠的方法是使用前缀选项从源代码进行编译。或者创建一个 bash 脚本，使用 --defaults-file 选项启动 mysql2，然后使用它来启动它。
但是，按照您的方式“创建”另一个安装并不好。当您编译包时，前缀被硬编码到可执行文件中。因此，每当它查找资源时，它都会从该前缀开始，除非使用命令行选项告知不要这样做。
所以，如果我是你，我只会使用新的前缀从源代码重新编译。
I think the only sure way is to compile from source with the prefix option. Either that, or create a bash script that starts mysql2 with the --defaults-file option and then use that to start it instead.
However, "creating" another installation the way you did isn't good. When you compile a package, the PREFIX is hard-coded into the executable. So whenever it looks for a resource, it starts from that prefix, unless told not to with command line options.
So, if I were you, I'd just recompile from source with a new prefix.