Я создаю простой сценарий Ansible для своего проекта, в котором я устанавливаю MySQL на виртуальную машину Ubuntu.
В рамках этой настройки я создаю собственный файл my.cnf в /etc/my.cnf, и он выглядит так после jinja2 шаблон завершен, разобрав его.
[client]
port = 3306
socket = /var/run/mysqld/mysqld.sock
[mysqld_safe]
socket = /var/run/mysqld/mysqld.sock
log_error = /var/log/mysql/mysql_error.log
pid-file = /var/run/mysqld/mysqld.pid
general_log = on
general_log_file = /var/log/mysql/mysql.log
[mysqld]
bind-address = 127.0.0.1
datadir = /var/lib/mysql
pid-file = /var/run/mysqld/mysqld.pid
log_error = /var/log/mysql/mysql_error.log
general_log = on
general_log_file = /var/log/mysql/mysql.log
socket = /var/run/mysqld/mysqld.sock
user = root
port = 3306
# Disabling Symlinks is recommended for security purposes #
symbolic-links=0
Затем, поскольку я запускаю Ubuntu, я звоню
service: name=mysql state=started enabled=yes
И все кажется правильным, но когда я проверяю свои переменные, используя
mysqld --verbose --help я обнаружил, что переменные неверны, например, он говорит general-log ложно и symbolic-links ИСТИНА, даже если я установил его в 0 в этом файле cnf, то же самое, если я запускаю mysql show variables
Итак, я проверил, что файл существует и находится в etc/my.cnf и что он загружен как mysql --verbose --help отчеты
Default options are read from the following files in the given order:
/etc/my.cnf /etc/mysql/my.cnf /usr/etc/my.cnf ~/.my.cnf
Может быть, это проблема с правами пользователя? Я считаю, что этот файл my.cnf принадлежит корень пользователь, это может быть причиной проблемы.
Что мне действительно нужно, так это помощь в отладке того, что может пойти не так, поскольку я относительно новичок в такой низкоуровневой конфигурации MySQL.
заранее спасибо
Мне удалось заставить его работать, очевидно, это может быть связано с порядком, в котором эти файлы выполняются.
Я предполагал, что
Default options are read from the following files in the given order:
/etc/my.cnf /etc/mysql/my.cnf /usr/etc/my.cnf ~/.my.cnf
Это означало, что /etc/my.cnf имеет приоритет над другими, хотя на самом деле кажется наоборот, в этом случае кажется, что ~/.my.cnf имел бы наивысший приоритет, если бы он существовал.
Имеет смысл, учитывая, что etc/my.cnf - это самый общий и наименее конкретный файл.
Вместо этого я переопределил запас my.cnf файл в /etc/mysql/my.cnf с моей версией. Я бы не советовал другим делать то же самое, поскольку я считаю, что вы должны оставить значение по умолчанию и просто добавить свой my.cnf к /usr/etc/my.cnf вместо этого, в моем случае это только для Vagrant VM, и поэтому я не так сильно беспокоюсь
Я действительно считаю, что это может быть проблемой, если вы считаете, что я ошибаюсь, пожалуйста, поправьте меня.
Большое спасибо @Michael Hampton за его помощь
РЕДАКТИРОВАТЬ
Возможно, я ошибаюсь, я пытался /usr/etc/my.cnf метод, и он не сработал, что немного странно, я не совсем понимаю логику, стоящую за my.cnf приоритеты или как вы должны отменить его, не касаясь стандартного, который поставляется с вашей установкой.
В крайнем случае, я могу просто переписать стоковую, я думаю, и вы можете заставить mysqld использовать конкретный my.cnf файл через --defaults-file аргумент, но все же я хотел бы полностью понять, что происходит, поэтому, если кто-то знает, пожалуйста, добавьте свои мысли.
Спасибо
Вы используете Ubuntu, которая автоматически запускает службы после установки. Таким образом, в то время, когда вы просите, чтобы он был включен и запущен, он уже был включен и запущен. И, конечно, если вы снова запустите playbook, пока он работает, он уже запущен ...
Что вам нужно сделать, так это настроить обработчик что будет начать сначала сервис. Например:
$ cat roles/mysql/handlers/main.yml
---
- name: restart mysql
service: name=mysql state=restarted
Тогда обязательно notify: restart mysql в любой задаче, изменяющей конфигурацию.