Комментарии 11
(комментарий ниже это мое личное мнение)
У физической репликации (не важно, реплицируется диск целиком или только журнал базы) есть один существенный минус, о котором, к примеру, было упомянуто в статье Uber о найденных ими недостатках PostgreSQL: https://eng.uber.com/postgres-to-mysql-migration/. Если кратко, то любая ошибка при записи на диск, или при проигрывании журнала, добавленная в новой версии СУБД приведет к порче данных и на мастере и на реплике, поскольку у них одинаковый код. В случае с логической репликацией и обновлению сначала реплики, а потом мастера, такой проблемы не возникнет, ну и обновляться можно без downtime, поскольку формат журнала изменений в случае с логической репликацией несложно сделать обратно-совместимым и, в том же MySQL, он на практике тоже является обратно совместим.
Репликация средствами СХД подвержена тем же проблемам: любые систематические ошибки работы с диском будут точно также отреплицированы с ошибками на другие новые диски. Плюс есть дополнительный риск из-за того, что у одних и тех же производителей (или самих дисков) будут одни и те же программные баги в их прошивке и соответственно либо портить данные они будут одинаково, либо выходить из строя примерно одновременно.
Более того, все рассмотренные виды репликации интересны, но некоторые режимы ухудшают доступность, как например режим, где мастер фейлит транзакцию, если не удалось записать в реплику: если либо мастер либо реплика упадут, то запись остановится, и это примерно в два раза вероятнее, чем если если выйдет из строя только мастер, если считать события выхода из строя серверов независимыми. Переход на асинхронную репликацию в случае недоступности реплики так и вообще равноценен репликации Шредингера: Вы никогда не можете быть уверены, что данные куда-то реплицируются.
Намного лучше такой репликации в плане сохранности данных и доступности системы мне видится кворумная запись с автоматическим leader election. То есть, при записи мы ждём не только ответа от лидера, но и ответа от кворума ([N+1]/2 участников, оно должно быть нечётным). Репликация всё ещё может быть и логической и физической, но, насколько я знаю, физическую никто не выбирает. В кворум могут входить сервера разных производителей и архитектур, если хочется максимальной надёжности.
не важно, реплицируется диск целиком или только журнал базы
Как раз это очень важно, потому что «запись на диск» и «проигрывание журнала» – это разные вещи. Вы правы, чем ниже уровень репликации, тем выше вероятность переноса ошибки на реплику. Но в случае с репликацией средствами БД эта вероятность существенно меньше.
кворумная запись с автоматическим leader election
Технология репликации и топология кластера – это два совершенно отдельных вопроса. Никто не мешает сделать две синхронных реплики и успешно фиксировать транзакцию, когда ответила хотя бы одна из них.
но, насколько я знаю, физическую никто не выбирает.
Вас обманули :))
У MySQL действительно нет общедоступного средства физической репликации, поэтому выбирать не из чего. Но у всех промышленных экземпляров «взрослых» СУБД – Oracle, MS SQL, PostgreSQL, DB2 – есть физическая реплика, она же standby.
Для полноты картины недостает RFC-4533.
Нет, никакого ETL там нет, от слова совсем.
Видимо вы совсем не в теме.
Да, там "синхронизация содержимого" (что следует из заголовка RFC).
Т.е. RFC-4533 — это примерно CDC вшитый в СУБД, причем в вариантах как с журналом изменений, так и без, но никак не ETL.
С точки зрения развития технологий RFC-4533 является заметной вехой, его "уши" видны во многих реализациях (включая упомянутые коммерческие CDC).
Если в статье есть какая-то неточность, не стесняйтесь написать о ней в комментарии или в личку.
Если считаете, что есть какие-то важные аспекты, которые могли бы добавить статье информативности и повлиять на выводы, дайте какие-нибудь ключевые слова, о чём надо узнать.
— есть блочная репликация томов в синхронном и асинхронном виде
— есть файловая репликация (для файловых СХД)
— есть журналирование и интеграция журналирования с транзакциями (букмарки на коммиты) — например EMC RecoverPoint CDP
— есть клоны / снапшоты и их репликация
— отдельно есть активное зеркалирование томов (как VPLEX), которое может быть как локльное, так и в метро-режиме (и вообще происходит отдельно от базы полностью прозрачно)
При этом у вендоров есть свои фирменные технологии
И есть еще промежуточный слой уровня гипервизора и ОС, как например vSphere Replication.
Строго говоря только вышеперечисленное займет объем еще двух-трех таких же статей.
вышеперечисленное займет объем еще двух-трех таких же статей.
Если вы такую статью напишете, обещаю стать самым первым и самым благодарным читателем :)
Что касается СУБД, то с этой точки зрения перечисленный возможности не очень интересны:
- про блочную репликацию и зеркалирование томов я сказал
- клоны и снапшоты – это, скорее, про резервное копирование, чем про репликацию
- файловые СХД для баз данных применяют разве что совсем от безнадёжности
- RecoverPoint – интересная штука, но по сути она повторяет функционал СУБД в части обеспечения сохранности данных
В общем, ждём статью о возможностях современных СХД :))
Путеводитель по репликации баз данных