Сейчас синхронизирую базы с удаленные серваком останавливая мускул и запуская rsync. Но базы растут и с ними растет и время простоя.
Вопрос в том насколько велика вероятность получить битые таблицы если не останавливать мускул на период синхронизации? А если сначала сделать LOCK TABLES? А потом еще прогонять проверку. Из активности в база на 99% SELECT-ы.
PS. Я прекрасно знаю про дампы и про репликацию и активно их использую, но в данном случае это неоправданно сложно.
Потому что баз много, все с разными кодировками, а хочется простого и надежного решения.
В репликации тоже не вижу смысла, это слишком сложно для данного случая.
Периодический дамп не испортит кодировки, при условии что вы не используете глупые параметры типа init-connect,skip-чтототам-client-charset.
Ну, хотя бы имейте ввиду, что с ростом базы и требований к скорости работы синхронизации, вы так или иначе придете к необходимости репликации.
Нет ничего особо сложного в односторонней репликации master->slave.
Под синхронизацией вы подразумеваете копирование — ибо сейчас она у вас осуществляется только в одну сторону — от удаленного сервака к вашему.
Можно вместо rsync использовать mysqldump, потом gzip, scp на удаленном сервере и mysql < dump.sql на локальном — будет то же самое, но удаленный сервер простаивать почти не будет (останется только лаг на время выполнения дампа).
А зачем такой изврат с rsync? Чем не подошла репликация?
В любом случае, вы можете воспользоваться mysqlhotcopy для копирования файлов таблиц при работающем сервере, и уже эти копии отправлять на слейв при помощи rsync.
Ну вы бы хоть дочитали что делает FLUSH TABLES WITH READ LOCK
Closes all open tables and locks all tables for all databases with a global read lock until you explicitly release the lock by executing UNLOCK TABLES
По крайней мере я сейчас попробовал и файлы myisam легко подменяются без ошибок.
Простой
