|
Задавайте вопросы, мы ответим
Вы не зашли.
Доброго времени суток!
Есть пара вопросов по поводу репликации из одной страны в другую. Верны ли следующие утверждения?
1. master-master равносильно смерти из-за задержек.
2. mater-slave можно сделать, но при обращении к slave данные могут быть не самые последние.
3. В случае падения master, все запросы можно будет перенаправить на slave, а после подъема мастера - накатить на него дамп со слейва и продолжить работу.
А так же по поводу репликации на соседний сервер:
1. master-master возможны, но надо, чтобы запросы были без некоторых специальных "фич".
2. mater-slave - можно сделать. insert/update можно направлять на мастер, select - на slave.
Неактивен
1. Нет. Но написать хорошее приложение, которое умеет работать
с master-master — достаточно тяжелая работа.
2. Верно.
3. Если у Вас есть master-master — да. Если master-slave — в случае, если
на slave тоже включен binlog (и выключен log_slave_updates — иначе поло-
жение будет очень тяжело искать для проигрывания). Ну или целиком пере-
ливать всю базу на мастер.
1. Для работы master-master все запросы должны быть коммутативными. Т.е.
каждый последующий запрос не может полагаться на предыдущие.
2. Верно.
Неактивен
Спасибо за ответ!
paulus написал:
1. Нет. Но написать хорошее приложение, которое умеет работать
с master-master — достаточно тяжелая работа.
То есть, при наличии рук и желания реально сделать приложение географически разбитым? Апдейты и инсерты, скорее всего, достаточно частые. Что можете посоветовать почитать о том, какими запросы должны быть, а какими - нет?
Неактивен
Про почитать — не скажу, к сожалению. Боюсь, что нужно в каждом запросе
применять голову 
Единственная проблема, которая решается автоматически — это автоинкременты
(т.е. можно сделать один мастер нечетным, второй четным — и всё будет хорошо).
А так — на каждом изменяющем запросе думайте, что будет, если табличка
еще не изменилась. Скажем, INSERT INTO a SELECT FROM b — это запрос, который
точно всё убьет (потому что на том сервере в b уже написали, а тут еще нет, и
когда этот запрос приедет туда — он там побьет данные). Запрос вида DELETE
FROM a WHERE (тут условие не на PK) — убьет всё (т.к. там вставили, а вы сотрете).
И т.п. Везде надо применять голову
Неактивен
