Технология построения защищенных распределенных приложений
Особенности репликации в Percona XtraDB Cluster
жүктеу/скачать 0.74 Mb. Pdf көрінісі
|
- Бұл бет үшін навигация:
- 3.3 Порядок выполнения работы
| 3.2.3 Особенности репликации в Percona XtraDB Cluster
В Percona XtraDB Cluster можно выполнять запись на любом узле и при этом кластер гарантирует консистентность записи. То есть, запись либо произойдет на всех узлах, либо ни на одном. Все запросы исполняются локально на узле, особым образом обрабатывается только коммит (commit). Как только дана команда коммит, транзакция должна пройти верификацию (подтверждение коммита) на всех узлах. Транзакция подтверждается только, если верификация проходит успешно, в противном случае происходит откат транзакции. Из этой архитектуры вытекают два важных следствия: во-первых, существует небольшой период времени, когда slave не синхронизирован с master. Это происходит, потому что master может зафиксировать коммит быстрее, чем slave. И если в этот момент происходит чтение из slave, есть вероятность прочитать еще не изменившиеся данные. Впрочем, это поведение можно изменить, если установив переменную настройки wsrep_causal_reads=ON. В этом случае чтение на slave будет ожидать, пока коммита не будет зафиксирован, что впрочем, увеличивает время отклика на операцию чтения. во-вторых, если ведется запись на два разных узла, кластер будет использовать оптимистичную модель блокировки. То есть, транзакция не будет проверять возможные конфликты блокировок между узлами во время отдельных запросов, а только лишь на стадии коммита. Таким образом, можно 39 получить ошибку при выполнении коммита, что в обычном InnoDB MySQL не возможно. В InnoDB MySQL ошибки вида DEADLOCK и LOCK TIMEOUT могут возникать только в ответ на отдельные запросы, но не на коммит. Поэтому приложения, использующее Percona XtraDB Cluster, должны в обязательном порядке проверять ошибку коммита. 3.3 Порядок выполнения работы жүктеу/скачать 0.74 Mb. Достарыңызбен бөлісу:
|