Когда я изначально настраивал репликацию master-to-master, я использовал:
binlog-ignore-db=mysql
и синхронизируют учетные записи пользователей и гранты вручную. Просто так это было сделано в как я использовал в это время. Но есть ли причина, по которой мне не следует удалять эту строку и разрешать mysql саму базу данных тоже реплицировать?
Если да: прежде чем я внесу изменение, помимо проверки того, что все гранты одинаковы на обоих (или, точнее, вся база данных mysql идентична), есть ли что-нибудь еще, что я должен перепроверить или знать?
Вполне возможно дать себе разрешения mysql, не зная Команды SQL GRANT.
Пример: Вот создать своего собственного пользователя с полными привилегиями, используя SQL GRANT из любого места, называемого superdba, с паролем ClarkKent:
GRANT ALL PRIVILEGES ON *.* TO superdba@'%' IDENTIFIED BY 'ClarkKent' WITH GRANT OPTION;
Вот как это можно сделать без команды GRANT:
Прежде всего, вот mysql.user для MySQL 5.1.51
mysql> desc mysql.user;
+-----------------------+-----------------------------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-----------------------+-----------------------------------+------+-----+---------+-------+
| Host | char(60) | NO | PRI | | |
| User | char(16) | NO | PRI | | |
| Password | char(41) | NO | | | |
| Select_priv | enum('N','Y') | NO | | N | |
| Insert_priv | enum('N','Y') | NO | | N | |
| Update_priv | enum('N','Y') | NO | | N | |
| Delete_priv | enum('N','Y') | NO | | N | |
| Create_priv | enum('N','Y') | NO | | N | |
| Drop_priv | enum('N','Y') | NO | | N | |
| Reload_priv | enum('N','Y') | NO | | N | |
| Shutdown_priv | enum('N','Y') | NO | | N | |
| Process_priv | enum('N','Y') | NO | | N | |
| File_priv | enum('N','Y') | NO | | N | |
| Grant_priv | enum('N','Y') | NO | | N | |
| References_priv | enum('N','Y') | NO | | N | |
| Index_priv | enum('N','Y') | NO | | N | |
| Alter_priv | enum('N','Y') | NO | | N | |
| Show_db_priv | enum('N','Y') | NO | | N | |
| Super_priv | enum('N','Y') | NO | | N | |
| Create_tmp_table_priv | enum('N','Y') | NO | | N | |
| Lock_tables_priv | enum('N','Y') | NO | | N | |
| Execute_priv | enum('N','Y') | NO | | N | |
| Repl_slave_priv | enum('N','Y') | NO | | N | |
| Repl_client_priv | enum('N','Y') | NO | | N | |
| Create_view_priv | enum('N','Y') | NO | | N | |
| Show_view_priv | enum('N','Y') | NO | | N | |
| Create_routine_priv | enum('N','Y') | NO | | N | |
| Alter_routine_priv | enum('N','Y') | NO | | N | |
| Create_user_priv | enum('N','Y') | NO | | N | |
| Event_priv | enum('N','Y') | NO | | N | |
| Trigger_priv | enum('N','Y') | NO | | N | |
| ssl_type | enum('','ANY','X509','SPECIFIED') | NO | | | |
| ssl_cipher | blob | NO | | NULL | |
| x509_issuer | blob | NO | | NULL | |
| x509_subject | blob | NO | | NULL | |
| max_questions | int(11) unsigned | NO | | 0 | |
| max_updates | int(11) unsigned | NO | | 0 | |
| max_connections | int(11) unsigned | NO | | 0 | |
| max_user_connections | int(11) unsigned | NO | | 0 | |
+-----------------------+-----------------------------------+------+-----+---------+-------+
39 rows in set (0.00 sec)
Просто выполните эти команды SQL:
INSERT INTO mysql.user SET
Host='%',User='superdba',Password=PASSWORD('ClarkKent'),
Select_priv='Y',Insert_priv='Y',Update_priv='Y',Delete_priv='Y',
Create_priv='Y',Drop_priv='Y',Reload_priv='Y',Shutdown_priv='Y',
Process_priv='Y',File_priv='Y',Grant_priv='Y',References_priv='Y',
Index_priv='Y',Alter_priv='Y',Show_db_priv='Y',Super_priv='Y',
Create_tmp_table_priv='Y',Lock_tables_priv='Y',Execute_priv='Y',
Repl_slave_priv='Y',Repl_client_priv='Y',Create_view_priv='Y',
Show_view_priv='Y',Create_routine_priv='Y',Alter_routine_priv='Y',
Create_user_priv='Y',Event_priv='Y',Trigger_priv='Y';
FLUSH PRIVILEGES;
Этот INSERT - это законный оператор SQL, который может быть записан в двоичный журнал. Вы хотите, чтобы кто-то запустил это и чтобы видимый пароль путешествовал по сети? сидеть в бинарном логе на мастере? сидеть в релейном журнале на рабе?
Имея эту директиву
binlog-ignore-db=mysql
предотвращает передачу разрешений mysql с помощью такого SQL. Однако ГРАНТ не может быть остановлен таким образом. Поэтому убедитесь, что вы выполняете гранты следующим образом:
SET SQL_LOG_BIN=0;
GRANT ...
для предотвращения перехода GRANT от ведущего к ведомому.
У меня не было проблем с репликацией базы данных mysql, но опять же, моя инфраструктура обеспечивает дополнительный уровень безопасности с брандмауэрами и прокси-устройствами, где никто, кроме сотрудников инфраструктуры, не может даже подключиться к любому из портов, используемых MySQL. . Это добавляет дополнительный уровень удобства, зная, что вам нужно предоставить разрешения только один раз, и они будут реплицированы. Когда дело доходит до этого, до тех пор, пока вы правильно настроили хост, чтобы не открывать его никому, кроме предполагаемого (например, вам, подчиненному и т. Д.), Все должно быть в порядке.
Если вас слишком беспокоит человек в середине перехвата, всегда есть возможность отправить репликация через SSL.