воскресенье, 27 октября 2013 г.

MySQL+SSL репликация

Репликация у MySQL изначально без шифрования, что снижает нагрузку на систему, но при разнесении базы на несколько площадок возникает вопрос безопасной репликации. Это можно делать как через сторонние тоннели, так и штатными методами через SSL. Будем делать штатными методами.



Проверка, есть ли вообще поддержка SSL и включение
mysql -u root -e "show variables like '%ssl%'" | grep "have_"
+---------------+----------+ | Variable_name | Value | +---------------+----------+ | have_openssl | DISABLED | | have_ssl | DISABLED | +---------------+----------+ 2 rows in set (0.00 sec)

Поддержка есть, но выключена. Включается просто: в my.cnf в секцию [mysqld] вписываем
ssl

Перезапускаем и проверяем снова, должно быть
 +---------------+-------+
| Variable_name | Value | +---------------+-------+ | have_openssl | YES | | have_ssl | YES | +---------------+-------+ 2 rows in set (0.00 sec)
Теперь в том же файле правим или комментируем строку с bind-address и заполняем строки
ssl-ca=/etc/mysql/newcerts/ca-cert.pem
ssl-cert=/etc/mysql/newcerts/server-cert.pem
ssl-key=/etc/mysql/newcerts/server-key.pem

При необходимости создаём корневой сертификат и комплект сертификатов для работы, для самоподписанного рекомендую срок 50 лет (практика показывает, что 10 лет в стабильной компании, для внутренних нужд - не так и много)
про генерацию можно взять например тут, процедура стандартна.

Не забываем про стандартную настройку репликации без SSL, в частности
server-id, log_bin, expire_logs_days, max_binlog_size

Настройка прав доступа
К базам должны быть пользователи с правом доступа по сети (не localhost), это может быть конкретный IP, имя хоста или % (отовсюду). При этом пользователь читаеся по полному имени, то есть user@localhost и user@% - разные пользователи, возможно даже с разными паролями.
При необходимости делаем, чтобы пользователи по сети могли подключаться только с SSL
GRANT USAGE ON *.* TO 'user'@'%' REQUIRE SSL;
Но это имеет смысл прежде всего для служебного пользователя, через которого будет выполняться репликация, его тоже надо будет завести
mysql -u root -e "GRANT REPLICATION SLAVE ON *.* TO 'slave_user'@'%' IDENTIFIED BY 'slave_password' REQUIRE SSL;"

Настройка реплики
На мастере делаем дамп базы данных (если есть опция binlog_do_db) или всех баз,  с опцией master-data. Этот метод хорош тем, что не надо переводить систему в read only и он хорошо автоматизируется. Позиция в master binlog при этом уже есть в дампе.
mysqldump -u root --all-databases --master-data |gzip > dump.sql.gz
и переносим дамп на новый сервер

На слейве
mysql -u root < zcat dump.sql.gz
Теперь надо сделать change master, например как было выше
CHANGE MASTER TO MASTER_HOST='192.168.0.100', MASTER_USER='slave_user', MASTER_PASSWORD='slave_password', MASTER_SSL=1, MASTER_SSL_CA = '/etc/mysql/newcerts/ca-cert.pem', MASTER_SSL_CERT = '/etc/mysql/newcerts/client-cert.pem', MASTER_SSL_KEY = '/etc/mysql/newcerts/client-key.pem';

тут убраны MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=98, так как в нашем варианте они уже выставлены в нужные значения.

Помним, что пользователей надо переносить отдельно, если мы не переносили базу mysql. но перенос базы mysql для дебиана и между разными версиями/сборками чреват проблемами.

Проверка
на слейве show slave status;
Seconds_Behind_Master - должно быть больше нуля и равно нулю, как синхронизация закончится
Slave_IO_Running YES
Slave_SQL_Running YES
Master_SSL_Allowed YES

Проверка, что из SSL поддерживается
mysql > show status like ‘%ssl%’;
                Ssl_cipher           DHE-RSA-AES256-SHA
mysql > \s
Cipher in use is DHE-RSA-AES256-SHA

Дополнительно можно проверить tcpdump-ом, что трафик шифрован.

Линки
http://dev.mysql.com/doc/refman/5.5/en/configuring-for-ssl.html
http://dev.mysql.com/doc/refman/5.5/en/ssl-connections.html
How To настроки репликации в MySQL с использованием шифрования SSL на Debian Lenny

Комментариев нет:

Отправить комментарий