> 3. Каковы проблемы репликации MySQL судя по вашему опыту? Насколько описано Это наколенная поделка. Работать не может в принципе, потому что исходно написана неправильно. Оно вместо репликации изменений базы, как это делают "взрослые" СУБД - - реплицирует команды. В порядке поступления и без анализа смысла. > в документации и судя по инфе в инете, MySQL реплицируются - как миниумум > master/slave работает вполне нормально. В общем случае - жрет безобразное количество ресурсов и при этом не работает без ручных пинков. > 4. Конкретно в чём проявлялась её "полуживое" состояние - какие были > симптомы? Репликация останавливается. При этом точность совпадения исходной и реплицированной копий и до этой остановки была сомнительна. После первой же остановки сомнений нет - они не совпадают. Это у нас. Если поискать в интернете не восторженные свистки чайников "я запустил! оно отреплицировало все шесть моих записей в трех таблицах!" а сообщения о _проблемах_ - выясняется, что нам еще здорово повезло. У людей репликация просто встает колом по неясной причине и как ее спихнуть с мертвой точки- просто непонятно. > 5. В чём заключалось "ручное пинание"? Нельзя ли как-то его В ручном пропуске вызвавшей проблемы команды. Пока это не сделано - сервер будет висеть и жрать место на двух машинах одновременно. > автоматизировать? Нельзя, если интересует результат. Даже делать то что делается для ****** нельзя, потому что мы - не разработчики базы, структуры данных не знаем и решение сколько записей пропускать принимаем революционным правосознанием. А там надо не только это сделать, но и прошедшую неправильную команду отменить. У тебя зависает команда INSERT что-токудато. (типичная причина - на мастере она не прошла, отвалившись по transaction timeout, но в лог он ее записал и слэйв - выполнил) Одно (два, шестнадцать) полей - автоинкременты и при том - ключи. Ты ее подтолкнул - INSERT прошел, но у тебя в реплике ключевое поле у этой записи другое. Дальше на мастере DELETE WHERE id= - у тебя удаляется совсем не та запись, которая должна. > 6. Минимально, безопасно для существующего кода (в смысле ничего не надо > переписывать), нужно кластеризовать БД хотя бы на 2 реплики: тут уже я ни одного слова не понял.
Представимся по-крупному, как полагается:).
via
NeydAchnica.