Синхронизация файлов и содержимого БД MySQL на резервный сервер |
[исправить] |
Есть два сервера под Linux/FreeBSD: СУБД MySQL + некое приложение,
задача - синхронизировать БД и данные.
За синхронизацию данных MySQL отвечает mysql replication, данные
синхронизируются с мастера на слейв.
Делаем на мастере:
в my.cnf добавляем строки
log-bin = /var/log/mysql/mysql-bin.log
binlog-do-db=databasename
server-id=1
перезагружаем MySQL, добавляем пользователя для репликации:
GRANT ALL PRIVILEGES ON databasename.* TO 'slave_user'@'%' IDENTIFIED BY 'slave_password';
FLUSH PRIVILEGES;
далее выполняем команду:
USE databasename;
FLUSH TABLES WITH READ LOCK;
SHOW MASTER STATUS;
и вывод этой команды для нас важен, надо его куда-нибудь записать:
| File | Position | Binlog_do_db | Binlog_ignore_db |
| mysql-bin.001 | 10 | databasename | |
теперь делаем дамп базы:
mysqldump -u slave_user -pslave_password --opt databasename > databasename.dump
и наконец убираем лок с базы в MySQL:
UNLOCK TABLES;
Теперь на слейве:
Создаём базу:
mysqladmin create databasename -p
Востанавливаем базу из дампа:
mysql -u slave_user -pslave_password databasename < databasename.dump
в my.cnf добавляем строки:
server-id=2
master-host=XX.XX.XX.XX # IP адрес мастер-сервера
master-user=slave_user
master-password=slave_password
master-connect-retry=60
replicate-do-db=databasename
перегружаем MySQL и добавляем чудесные данные из волшебной комманды:
SLAVE STOP;
CHANGE MASTER TO MASTER_HOST='XX.XX.XX.XX',
MASTER_USER='slave_user', MASTER_PASSWORD='slave_password',
MASTER_LOG_FILE='mysql-bin.001', MASTER_LOG_POS=10;
START SLAVE;
готово, теперь проверяем, добавляем запись в мастер, на слейве она должны отреплицироваться.
Понятно, что изменять данные можно только на мастере, слейв работает только на чтение.
Для синхронизации данных имеет смысл использовать rsync, очень интересный протокол/приложение.
Может синхронизировать инкрементально и с сжатием.
На мастер сервере в rsyncd.conf добавляем:
read only = yes # во избежание ;-)
hosts allow = YY.YY.YY.YY # IP адрес слэйв-сервера
[somelabel]
path = /path/to/apllication/folder # где лежит приложение
auth users = replica_user # юзер только для репликации в rsync, не системный пользователь
secrets file = /path/to/rsync/rsync.secret # где лежит файл с паролем для replica_user,
# только пароль и ничего больше
на слейве - команда для синхронизации, можно добавить в cron с нужной периодичностью:
/path/to/rsync -avz --exclude-from=/path/to/rsync.exclude \
--password-file /path/to/rsync.secret \
rsync://[email protected]:873/somelabel /path/to/application
где:
rsync.exclude - файл в котором перечислены, какие файлы (конкретно или по
маске) не синхронизировать
rsync.secret - файл с секретным паролем для replica_user
ХХ.ХХ.ХХ.ХХ - IP мастер-сервера, 873 - дефолтный порт для демона
somelabel - метка из rsyncd.conf с мастера
/path/to/application - путь куда класть данные.
|
|
|
|
Раздел: Корень / Программисту и web-разработчику / SQL и базы данных / MySQL специфика / Оптимизация и администрирование MySQL |
1, PavelR (??), 16:20, 18/06/2008 [ответить]
| +/– |
А еще есть LVM со своими снапшотами, и есть специальная тулза которая делает копирование файлов БД с использованием этого механизма.
(сдеали LOCK, сделали FLUSH, создали снэпшот, разлочили БД, копируем файло, отключаем снэпшот)
| |
|
2, neiro (ok), 20:12, 18/06/2008 [^] [^^] [^^^] [ответить]
| +/– |
синхронизация БД для вэб-приложения нужна near real-time
| |
|
3, Аноним (3), 22:57, 20/06/2008 [^] [^^] [^^^] [ответить]
| +/– |
Ты не понял, когда тебе нужно будет делать пересинхронизацию БД весом 100 Gb ты поймешь зачем тебе нужен LVM.
| |
4, Аноним (-), 22:48, 22/06/2008 [^] [^^] [^^^] [ответить]
| +/– |
>синхронизация БД для вэб-приложения нужна near real-time
>Ты не понял, когда тебе нужно будет делать пересинхронизацию БД весом 100
>Gb ты поймешь зачем тебе нужен LVM.
Угу, поддерживаю предыдущего оратора :), LVM рулит, когда реплика отвалится и ты будешь ее чинить.
А вообще несколько уточнений:
>GRANT ALL PRIVILEGES ON databasename.* TO 'slave_user'@'%' IDENTIFIED BY 'slave_password';
GRANT ALL PRIVILEGES ON ... - это перебор, достаточно GRANT REPLICATION SLAVE ON ...
> FLUSH PRIVILEGES;
FLUSH тут необязателен, он нужен только когда напрямую (INSERT, DELETE, UPDATE) меняются таблицы из базы mysql
>[оверквотинг удален]
> master-user=slave_user
> master-password=slave_password
> master-connect-retry=60
> replicate-do-db=databasename
>перегружаем MySQL и добавляем чудесные данные из волшебной комманды:
> SLAVE STOP;
> CHANGE MASTER TO MASTER_HOST='XX.XX.XX.XX',
> MASTER_USER='slave_user', MASTER_PASSWORD='slave_password',
> MASTER_LOG_FILE='mysql-bin.001', MASTER_LOG_POS=10;
> START SLAVE;
Это стремный вариант. После старта мускуля он УЖЕ будет слэйвом, только с неправильными MASTER_LOG_FILE, MASTER_LOG_POS, лучше стратовать его БЕЗ строк в инишнике master-user=..., master-password=...., а добавить их туда потом, после старта (на случай последующих рестартов).
| |
5, peering (ok), 09:45, 05/09/2012 [^] [^^] [^^^] [ответить]
| +/– |
А данная схема получается не подходит для web-серверов ? Если вы этим занимались можно подробнее, где грабли искать ??? И чем лучше данные синхронить пока только rsync нарыл ???
| |
|
|
|