|
|
Задавайте вопросы, мы ответим
Вы не зашли.
Страниц: 1
Имеется основная база на сервере в офисе. С ней работают как работники офиса, так и клиенты через Интернет. Время от времени некоторые сотрудники офиса выезжают на объекты с копиями базы на ноутбуках. Если на объекте есть доступ к Интернет, изменения на ноутбуках должны оперативно попадать в основную базу. Если же нет, то по завершении работы с объектами сотрудники возвращаются в офис и сливают изменения базы в основную базу на сервер. По какой схеме репликации это лучше сделать? Можно ли это делать без остановки основной офисной базы?
Это же получается, что при перекачке данных ноут будет мастером, а основной сервак - слейвом. Одновременной репликации с нескольких мастеров (ноутов) не требуется.Менеджеры могут и по очереди сливать. Но настраивать слейва каждый раз же придется? На каждом ноуте же может быть разный путь к бинлогу и разные имена этих бинлогов и точки, с которых нужно начинать репликацию тоже разные. Это значит, нужно каждый раз перед сливом слейв, т.е. основной сервак останавливать? Вариант нежелательный. Клиенты там через Интерент круглосуточно с базой работают. Можно ли это все реализовать встроенными средствами репликации mySQL или лучше написать что-то свое?
Неактивен
Во первых нужно позаботится чтоб выезжающие сотрудники не изменяли и не удаляли записи, то есть только добавляли.
Во вторых в вашем случае репликация не очень удобное решение, вам нужна двух сторонняя синхронизация.
Попробуй те Maatkit Table Sync , конкретно ваш случай я не проверял как работает, но по описанию по моему это как раз то что нужно.
Неактивен
evgeny написал:
Спасибо! Обязательно изучу!
Неактивен
Вообще если выезжающие агенты могут обновлять и удалять записи, то это очень сильно усложняет ситуацию. Тогда надо самому писать систему синхронизации которая будет работать по принципу SVN.
Неактивен
В принципе ничего сложного тут нет. Базы на ноутах должны вести бинлоги, причем необходимо сразу после слития базы на ноут записывать данные show master status куда либо
Итак они ездют меняют там все, приезжают на базу. на основном сервере говороим
STOP SLAVE;
CHANGE MASTER TO MASTER_HOST='айпи ноута',
MASTER_USER='реплиюзер',
MASTER_PASSWORD='<replication password>',
MASTER_LOG_FILE='вот сюда имя лога сохраненное ранее',
MASTER_LOG_POS=позиция лога сохраненная ранее;
START SLAVE;
теперь show slave status; пока не догонит (секунд отставания должно стать 0)
stop slave;
готово
ессно все это ручками делать геморно, а написать скриптик не вижу никаких проблем.
Неактивен
хотя коллизии будут решаться всегда в сторону ноутов, а не центральной базы. так что в центральную базу insert only.
ну или ноуты insert only
Неактивен
Спасибо! Буду думать в эту сторону. А простите мне мое невежество - при STOP SLAVE с последующей настойкой на нового мастера останавливается именно репликация, сам MySQL продолжает работать и обслуживать пользователей? А то, что офисную БД время от времени надо делать то мастером (это когда реплицируем базу на ноут перед выездом), то слейвом (когда сливаем обратно), перебоями в работе Интернет-пользователей с основной базой никак не скажется (данные эти самые пользователи будут писать/читать в те же таблицы, но работать с другими записями)? После таких перенастроек перед стартом очередной репликации перезапуск MySQL не требуется?
Отредактированно solka27 (05.08.2011 00:31:02)
Неактивен
Ну стоп слейв остановит только репликацию. сам мускул будет дальше жить. реплицировать на ноуты не стоит - лучше просто перегонять дампом всю базу (это будет быстрее и проще)
Не требуется, мастер меняется командой CHANGE MASTER TO
Неактивен
solka27, Не забывайте что вариант с репликацией подходит только в случае если на компах выезжающих агентов осуществляется только insert.
Неактивен
evgeny написал:
solka27, Не забывайте что вариант с репликацией подходит только в случае если на компах выезжающих агентов осуществляется только insert.
почему? в бинлог пишутся и апдейты и делиты - что мешает им выполниться?
Неактивен
А действительно, что? Делитов в моем случае у выезжающих не будет. Но апдейтов, пожалуй, даже больше, чем инсертов. Когда офисный работник вернется в офис, его ноут будет выступать в роли мастера, центральная база в роли слейва. Разве с мастера на слейв не ВСЕ изменения пишутся?
Отредактированно solka27 (08.08.2011 13:51:04)
Неактивен
почему? в бинлог пишутся и апдейты и делиты - что мешает им выполниться?
Я имел виду что может быть ситуация когда агент1 и агент2 в один день обновили одну и туже запись "x" где есть поля "a" и "b".
В случае с репликацией если запускать поочерёдно агент1 потом агент2 то в главной базе будут всегда преобладать записи из агент2, что может не соответствовать логики вашего приложения.
Но апдейтов, пожалуй, даже больше, чем инсертов.
Есть ситуация когда агент1 сделал insert а потом делает update по autoincriment id от прошлого инсерта. В это время на главной базе тоже делаются инсерты и получаются теже ID. В таком случае важно сделать разные autoincriment на всех базах.
Отредактированно evgeny (08.08.2011 15:56:34)
Неактивен
Страниц: 1
