Копирование базы данных MySQL Windows=>Linux без долгих блокировок
Приветствую! Столкнулся с небольшой проблемой, нужен совет, надеюсь на помощь сообщества.
Имеется удалённый MySQL-сервер работающий на Windows (и не спрашивайте почему) с двумя большими базами (500 Мбайт и постоянно увеличивается). В базе происходит очень частая запись, сложные модифицирующие запросы и копирование данных из одной в другую.
Необходимо запустить на отдельном сервере (Linux) веб-приложение, которое будет выдавать пользователям информацию из одной из этой баз, данные берутся исключительно для чтения. Приложением будут пользоваться несколько человек одновременно, поэтому встаёт задача периодически копировать базу на сервер веб-приложения. Актуальность данных не большая: 10-60 минут. Блокировать таблицы можно максимум ~30 сек.
1) Репликация не подходит, так как с головного сервера будет приходить куча модифицирующих запросов, поэтому всё встанет колом.
2) mysqldump слишком медлителен, слишком долго будет блокировать таблицы.
3) Percona/mysqlhotcopy — не подходят, т. к. головной сервер на windows.
4) Остаётся вариант только с SELECT INTO OUTFILE и LOAD DATA INFILE с выборкой только изменившихся записей (ввести поле с «ON UPDATE CURRENT_TIMESTAMP»).
В правильном ли направлении я иду, или может существует более элегантное решение?
Может я не понимаю принцип работы транзакций в MySQL, но мне всегда казалось, что бинарные логи — это именно список SQL-команд, которые должны выполняться на slave-серверах для обеспечения идентичности данных.
При запуске с ключом --log-bin[=file_name] mysqld создает файл журнала, в который вносятся данные обо всех обновляющих данные командах SQL.
ЗЫ. Но я тоже за репликацию. Мне кажется все остальные варианты гораздо сложнее в реализации и менее надежны.
Попробовать хотя бы стоит, MASTER-SLAVE настраивается быстро,
У нас используется statement-based репликация MASTER-MASTER, но есть и чистый слейв. Никогда не замечал тормозов. Даже при остановке репликации на несколько часов, при восстановлении соединения, данные на слейв попадают очень быстро и не вызывают ощутимых тормозов.
sevka_fedoroff, opium, спасибо, не попадалась мне пока инфа о statement-based репликации. Вопрос лишь в том, не будет ли большой нагрузки при частой записи в базу при одновременном чтении?
Интересен момент, если приостанавливать репликацию на 10 минут, а потом возобновить, то изменения как то объединяются, или нет? (то есть если за 10 минут 1000 раз был изменена лишь одна строчка, она также 1000 раз будет изменяться или изменения объединятся в одно?)
Спасибо за ответ, буду читать документацию по этой теме!
Мне кажется будет 1000 раз изменяться. Я даже думаю, что в случае row-based она тоже будет 1000 раз изменяться. Иначе может нарушиться целостность БД.
Row-based меня пугает тем, что один простой update может спровоцировать передачу огромного объема данных по сети, а в случае statement-based репликации передается только сам запрос.
да уж, сейчас протестировал. Во-первых binlog разросся, а во вторых пересылка таких объемов по интернету забьет канал. Так что решение не подходит.
statement-based тоже не вариант, мало того что производительности не будет, так еще придется тянуть вторую базу, которая в три раза больше первой. Так что пока ничего лучше load data infile, с собственным контролем изменений, не вижу.
Перепутал слова в вопросе, не «транзакции», а «репликация», исправил. Не подходит, потому как будет куча модифицирующих запросов (их может быть запросто >300 в минуту)
Средний
