Технология построения защищенных распределенных приложений

25 
Клиент, не дожидаясь ответа подчиненных серверов, сразу же получает 
сообщение об успешном завершении процесса. Такой подход обеспечивает 
максимальную скорость и позволяет производить репликацию даже по 
коммутируемым соединениям, но имеет один существенный минус, особенно 
актуальный для кластеров. Если после подтверждения транзакции ведущий 
сервер выходит из строя, а подчиненные сервера еще не успевают получить 
реплику, данные будут потеряны, но клиент будет уверен, что все в порядке. В 
случае мультимастер репликации проблема только усугубляется. 
В MySQL 5.5 появилась поддержка полу-синхронного (semi-synchronous) 
механизма репликации, основанного на патчах к InnoDB от компании Google. В 
этом случае ведущий сервер ожидает подтверждения от одного из ведомых, 
который сообщает, что получил и записал на диск реплику. При этом не 
ожидается, когда ведомый выполнит сам запрос, и нет никаких гарантий, что он 
вообще будет выполнен (например, ошибка).
Чтобы не быть зависимым от доступности подчиненного сервера, 
предусмотрен таймаут, позволяющий автоматически перейти асинхронный 
режим, если ни один из ведомых серверов не ответил за запрос. При 
восстановлении связи будет опять активирован semi-synchronous. 
Также поддерживается отложенная репликация, когда подчиненный 
сервер начинает выполнять запрос после истечения указанного промежутка 
времени (устанавливается при помощи MASTER_DELAY, по умолчанию 0). 
Это может быть полезно, если на ведомом сервере понадобится откатить 
транзакцию. 
По умолчанию используется асинхронная репликация, чтобы включить 
полу-синхронную, необходимо установить специальный плагин и активировать 
параметр в my.cnf. 
П
осмотрим, чем нам грозит асинхронность репликации. Данные между 
базами данных передаются с произвольной задержкой (от миллисекунд до 
дней). Для архитектуры master-slave с ведомого сервера можно просто не 
читать данные, отставшие, допустим, на 30 секунд. А вот для master-master все 
хуже — у нас нет и не будет (даже в случае полу-синхронной репликации) 
никаких гарантий, что копии БД — синхронны. Т.е. один и тот же запрос может 
выполняться по-разному на каждой из БД. А одновременное выполнение 
команд на разных серверах: 
UPDATE mytable SET mycol=mycol+1; 
UPDATE mytable SET mycol=mycol*3; 
также приведет к рассинхронизации данных в обеих БД. 
Одновременная вставка в обе БД одинакового уникального значения 
столбца — приведет к остановке репликации по ошибке (при авто инкременте 
такой проблемы не возникает). Таких «жутких» примеров можно привести 
множество. И хотя иногда советуют решения типа «ON DUPLICATE KEY 
UPDATE», игнорирование ошибок и пр. и заодно «перелопатить» приложение 
— здравый смысл подсказывает, что подобные подходы — скользкие и 
ненадежные. 

26 
Очевидно, к какому коллапсу и несогласованности это может привести 
ваше приложение. 
Как 
результат, 
использовать 
асинхронный master-master для 
одновременной записи в обе БД без знания подводных камней — опасно и 
ненадежно и применяется в редких случаях. 

жүктеу/скачать 0.74 Mb.

Достарыңызбен бөлісу: