Ковырялся я сейчас в рабочей почте, и натолкнулся на письмо коллеги, рассказывающее о том, как «великолепно» в MySQL организована репликация, и к чему это может привести (и приводит). Далее следует авторский текст, с небольшими правками:).

---

> 3. Каковы проблемы репликации MySQL судя по вашему опыту? Насколько описано
Это наколенная поделка. Работать не может в принципе, потому что исходно
написана неправильно. 
Оно вместо репликации изменений базы, как это делают "взрослые" СУБД -
- реплицирует команды. В порядке поступления и без анализа смысла.

> в документации и судя по инфе в инете, MySQL реплицируются - как миниумум
> master/slave работает вполне нормально.
В общем случае - жрет безобразное количество ресурсов и при этом
не работает без ручных пинков.

> 4. Конкретно в чём проявлялась её "полуживое" состояние - какие были
> симптомы?
Репликация останавливается. При этом точность совпадения исходной и
реплицированной  копий и до этой остановки была сомнительна. После первой же
остановки сомнений нет - они не совпадают.
Это у нас. Если поискать в интернете не восторженные свистки чайников 
"я запустил! оно отреплицировало все шесть моих записей в трех таблицах!" а 
сообщения о _проблемах_ - выясняется, что нам еще здорово повезло. У людей 
репликация просто встает колом по неясной причине и как ее спихнуть с мертвой
точки- просто непонятно.

> 5. В чём заключалось "ручное пинание"? Нельзя ли как-то его
В ручном пропуске вызвавшей проблемы команды. Пока это не сделано - сервер
будет висеть и жрать место на двух машинах одновременно.
> автоматизировать?
Нельзя, если интересует результат. Даже делать то что делается для ******
нельзя, потому что мы - не разработчики базы, структуры данных не знаем и 
решение сколько записей пропускать принимаем революционным правосознанием.
А там надо не только это сделать, но и прошедшую неправильную команду 
отменить.
У тебя зависает команда INSERT что-токудато. (типичная причина -
на мастере она не прошла, отвалившись по transaction timeout, но в
лог он ее записал и слэйв - выполнил) Одно (два, шестнадцать) полей
- автоинкременты и при том - ключи. Ты ее подтолкнул - INSERT прошел,
но у тебя в реплике ключевое поле у этой записи другое. Дальше на
мастере DELETE WHERE id= - у тебя удаляется совсем не та запись,
которая должна.

> 6. Минимально, безопасно для существующего кода (в смысле ничего не надо
> переписывать), нужно кластеризовать БД хотя бы на 2 реплики:
тут уже я ни одного слова не понял.

---

Единственно что, в 5.1 (которая ещё не stable даже), наконец-то, появляется кластерная репликация (построчная) — но это уже совсем другая история…