Репликация днк

Логическая репликация

Нельзя начинать транзакцию, пока не завершены все транзакции, которые должны закончиться раньше. Так на рисунке ниже нельзя запускать транзакцию D, пока не завершены транзакции A и B.
Нельзя завершать транзакцию, пока не начаты все транзакции, которые должны закончиться до завершения текущей транзакции. Так на рисунке ниже даже если транзакция B выполнилась мгновенно, завершить её можно только после того, как начнётся транзакция C.

запрос обновляет (или вставляет, или удаляет) единственную запись, идентифицируя её по первичному (или уникальному) ключу;
все параметры запроса явно заданы в самом запросе.

ID	Name	Dept	Salary
3817	Иванов Иван Иванович	36	1800
2274	Петров Пётр Петрович	36	1600
4415	Кузнецов Семён Андреевич	41	2100

настройка набора реплицируемых данных на уровне таблиц (при физической репликации – на уровне файлов и табличных пространств, при блочной репликации – на уровне томов);
построение сложных топологий репликации – например, консолидация нескольких баз в одной или двунаправленная репликация;
уменьшение объёма передаваемых данных;
репликация между разными версиями СУБД или даже между СУБД разных производителей;
обработка данных при репликации, в том числе изменение структуры, обогащение, сохранение истории.

все реплицируемые данные обязаны иметь первичные ключи;
логическая репликация поддерживает не все типы данных – например, возможны проблемы с BLOB’ами.
логическая репликация на практике не бывает полностью синхронной: время от получения изменений до их применения слишком велико, чтобы основная база могла ждать;
логическая репликация создаёт большую нагрузку на реплику;
при переключении приложение должно иметь возможность убедиться, что все изменения с основной базы, применены на реплике – СУБД зачастую сама не может этого определить, так как для неё режимы реплики и основной базы эквивалентны.

репликация триггерами;
использование журналов СУБД;
использование программного обеспечения класса CDC (change data capture);
прикладная репликация.

Репликация триггерами

независимость от версий основной базы и реплики;
широкие возможности преобразования данных.

нагрузка на основную базу;
большая задержка при репликации.

Использование CDC

Oracle GoldenGate (компания GoldenGate приобретена в 2009 году);
IBM InfoSphere Data Replication (ранее – InfoSphere CDC; ещё ранее – DataMirror Transformation Server, компания DataMirror приобретена в 2007 году);
VisionSolutions DoubleTake/MIMIX (ранее – Vision Replicate1);
Qlik Data Integration Platform (ранее – Attunity);
Informatica PowerExchange CDC;
Debezium;
StreamSets Data Collector…

возможность репликации между разными СУБД, в том числе загрузка данных в отчётные системы;
широчайшие возможности обработки и преобразования данных;
минимальный трафик между узлами – платформа отсекает ненужные данные и может сжимать трафик;
встроенные возможности мониторинга состояния репликации.

увеличение объёма журналов, как при логической репликации средствами СУБД;
новое ПО – сложное в настройке и/или с дорогими лицензиями.

Прикладная репликация

возможность репликации между разными СУБД, в том числе загрузка данных в отчётные системы;
возможность обработки и преобразования данных, мониторинга состояния и т. д.;
минимальный трафик между узлами – платформа отсекает ненужные данные и может сжимать трафик;
полная независимость от базы данных – как от формата, так и от внутренних механизмов.

ограничения на архитектуру приложения;
огромный объём собственного кода, обеспечивающего репликацию.

Асинхронность

Несмотря на все достоинства данной техники репликация SQL имеет ряд недостатков. Одним из них становится асинхронность операций. Это означает, что существует задержка при передаче от мастер-сервера «слейву». Достаточно сложно определить, как быстро появятся новые данные на «слейве», ведь задержка может быть совсем незначительной, а может и очень большой. При необходимости непрерывной работы с данными нужно использовать обращение к одному и тому же «мастер»-серверу, а не читать данные со «слейва».

Для того чтобы этого избежать, можно использовать синхронный режим. Его принцип заключается в том, что все запросы поступают на мастер-сервер, а ответы приходят со «слейва». Таким образом, гарантируется полное копирование данных на вторичный узел. Естественно, это приводит к большой потере в скорости работы, однако упрощает всю систему в целом.

Физическая репликация

СУБД	Опция репликации
Oracle	Active DataGuard
IBM DB2	HADR
Microsoft SQL Server	Log shipping/Always On
PostgreSQL	Log shipping/Streaming replication
MySQL	Alibaba physical InnoDB replication

объём передаваемых данных меньше за счёт того, что передаются только журналы, но не файлы с данными; эксперименты показывают уменьшение трафика в 5-7 раз;
переключение на резервную базу происходит значительно быстрее: экземпляр-реплика уже поднят, поэтому при переключении ему нужно лишь откатить активные транзакции; более того, к моменту сбоя кеш реплики уже прогрет;
на реплике можно выполнять запросы, сняв тем самым часть нагрузки с основной базы. В частности, реплику можно использовать для создания резервных копий.

Maximum performance: репликация всегда асинхронная;
Maximum protection: репликация синхронная; если реплика не отвечает, commit на основной базе не завершается;
Maximum availability: репликация синхронная; если реплика не отвечает, то репликация переключается в асинхронный режим и, как только связь восстанавливается, реплика догоняет основную базу и репликация снова становится синхронной.

Типы репликации

Существует три основных типа репликации: снимок, журнальный и смешение. Тип репликации назначается каждой публикации. Таким образом, возможно использование нескольких типов репликации в одной базе данных.

Репликация снимка распределяет данные напрямую как отображение на определенный момент, без мониторинга изменений. Это самый простой тип, при котором происходит банальное копирование снимка всех или отфильтрованных данных. Можете уронить свой взгляд на этот тип в следующих случаях:

данные изменяются существенно, но редко;
подписчику требуются данные только для чтения;
возможна большая задержка, потому что данные обычно только периодически обновляются;
подписчику требуется автономность.

При репликации транзакций от источника к приемнику поступают только изменения. Агент мониторит изменения в журнале транзакций на изменение реплицированных данных и переносит необходимые записи дистрибьютору. Агент дистрибьютора отправляет изменения подписчику. Прежде чем этот тип начнет работать, подписчику отправляется полный снимок реплицированных таблиц, а затем подписчик получает только изменения.

Репликация транзакций может использоваться там, где необходимо, чтобы подписчик получал изменения с минимальной задержкой.

Смешение — этот тип позволяет сайтам автономно изменять реплицированные данные. Позже, изменения с сайтов сливаются в одно целое. Этот тип не гарантирует целостности транзакций, но он гарантирует, что все сайты сливаются в один результирующий набор.

Сущность процесса репликации ДНК

При репликации молекулы ДНК водородные связи между комплементарными азотистыми основаниями (аденином — тимином и гуанином — цитозином) рвутся при помощи специального фермента — хеликазы, и цепи расходятся.

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

Особенностью процесса репликации ДНК является тот факт, что ее молекулы сформированы из двух цепей и образуют двойную спираль. В ходе репликации молекулы ДНК расходятся, и каждая дочерняя цепь может пристроить к себе новую цепь ДНК по принципу комплементарности. В результате этого из одной двойной спирали образуется две. Обе дочерние цепи идентичны исходной цепи и одна молекула образует две идентичные друг другу.

Тем самым репликация ДНК имеет полуконсервативный характер, каждая дочерняя молекула ДНК имеет одну материнскую цепь и одну вновь синтезированную. Репликация эукариот начинается в подготовительном этапе клеточного деления или в S-фазе клеточного цикла.

Механизм репликации ДНК и участвующие в нем основные ферменты характерны для большинства существующих ныне организмов. Однако существует ряд исключений среди бактерий или вирусов.

При этом расхождение цепей исходных молекул ДНК обеспечивается ферментом геликазой. Этот фермент в определенных местах способствует разрыву водородных связей, находящихся между азотистыми основаниям и ДНК. Эти ферменты перемещаются с затратой энергии.

Определение 2

Геликаза – это фермент, который обеспечивает расхождение цепей ДНК при процессе репликации.

Виды репликации

Репликация может быть синхронной или асинхронной, как описано ниже.

Синхронная репликация

В случае синхронной репликации, если данная реплика обновляется, все другие реплики того же фрагмента данных также должны быть обновлены в одной и той же транзакции. Логически это означает, что существует лишь одна версия данных.

В большинстве продуктов синхронная репликация реализуется с помощью триггерных процедур (возможно, скрытых и управляемых системой). Но синхронная репликация имеет тот недостаток, что она создаёт дополнительную нагрузку при выполнении всех транзакций, в которых обновляются какие-либо реплики (кроме того, могут возникать проблемы, связанные с доступностью данных).

Асинхронная репликация

В случае асинхронной репликации обновление одной реплики распространяется на другие спустя некоторое время, а не в той же транзакции. Таким образом, при асинхронной репликации вводится задержка, или время ожидания, в течение которого отдельные реплики могут быть фактически неидентичными (то есть определение реплика оказывается не совсем подходящим, поскольку мы не имеем дело с точными и своевременно созданными копиями).

В большинстве продуктов асинхронная репликация реализуется посредством чтения журнала транзакций или постоянной очереди тех обновлений, которые подлежат распространению

Преимущество асинхронной репликации состоит в том, что дополнительные издержки репликации не связаны с транзакциями обновлений, которые могут иметь важное значение для функционирования всего предприятия и предъявлять высокие требования к производительности.. К недостаткам этой схемы относится то, что данные могут оказаться несовместимыми (то есть несовместимыми с точки зрения пользователя)

Иными словами, избыточность может проявляться на логическом уровне, а это, строго говоря, означает, что термин контролируемая избыточность в таком случае не применим.

К недостаткам этой схемы относится то, что данные могут оказаться несовместимыми (то есть несовместимыми с точки зрения пользователя). Иными словами, избыточность может проявляться на логическом уровне, а это, строго говоря, означает, что термин контролируемая избыточность в таком случае не применим.

Рассмотрим кратко проблему согласованности (или, скорее, несогласованности). Дело в том, что реплики могут становиться несовместимыми в результате ситуаций, которые трудно (или даже невозможно) избежать и последствия которых трудно исправить.

В частности, конфликты могут возникать по поводу того, в каком порядке должны применяться обновления. Например, предположим, что в результате выполнения транзакции А происходит вставка строки в реплику X, после чего транзакция B удаляет эту строку, а также допустим, что Y — реплика X.
Если обновления распространяются на Y, но вводятся в реплику Y в обратном порядке (например, из-за разных задержек при передаче), то транзакция B не находит в Y строку, подлежащую удалению, и не выполняет своё действие, после чего транзакция А вставляет эту строку. Суммарный эффект состоит в том, что реплика Y содержит указанную строку, а реплика X — нет.

В целом задачи устранения конфликтных ситуаций и обеспечения согласованности реплик являются весьма сложными. Следует отметить, что, по крайней мере, в сообществе пользователей коммерческих баз данных термин репликация стал означать преимущественно (или даже исключительно) асинхронную репликацию.

Основное различие между репликацией и управлением копированием заключается в следующем:

Если используется репликация, то обновление одной реплики в конечном счёте распространяется на все остальные автоматически.

В режиме управления копированием, напротив, не существует такого автоматического распространения обновлений. Копии данных создаются и управляются с помощью пакетного или фонового процесса, который отделён во времени от транзакций обновления.

Управление копированием в общем более эффективно по сравнению с репликацией, поскольку за один раз могут копироваться большие объёмы данных. К недостаткам можно отнести то, что большую часть времени копии данных не идентичны базовым данным, поэтому пользователи должны учитывать, когда именно были синхронизированы эти данные.

Обычно управление копированием упрощается благодаря тому требованию, чтобы обновления применялись в соответствии со схемой первичной копии того или иного вида.

Репликация MS SQL Server

Очень удачно сделана возможность репликации в MS SQL Server. Настройка проста, как три копейки, потому что ее легко сделать с помощью двух мастеров, но есть подводные камни, о которых мастер не может рассказать, а мануалы просто умалчивают. Итак, давайте бегло пробежимся по процессу настройки репликации и сделаем упор на подводные булыжники, о которых все молчат как рыбы.

Для начала необходимо создать издателя и дистрибутора. Для этого на одном из серверов выбираем меню Tools | Replication | Create and Manage Publication. Я бы порекомендовал использовать для издателя машину помощнее. Первое, что у нас попросит мастер – выбрать базу данных. Выбираем, жмем Create Publication, и на следующем этапе сервер предложит создать дистрибутора. По умолчанию дистрибутором предлагается сделать ту же машину.

Мастер запрашивает создание дистрибутора репликации

Тут появляется первый подводный камень – если дистрибутор будет установлен на удаленно от издателя (на другой машине), то SQL Server Agent не может работать от имени системного аккаунта. Почему? Агент должен иметь возможность авторизоваться на машине дистрибутора и передать изменения, а для этого используется учетная запись, под которой работает агент. Под Local Account авторизоваться нигде не удастся, поэтому изменения никуда не пойдут.

Настройка учетной записи MS SQL Server Agent

После этого вам предложат сконфигурировать самого агента вручную или автоматически. Если выбрать ручной режим, то количество шагов мастера резко возрастает, но они просты и с минимальными знаниями английского ты разберешься в них. Если выбрать автомат, то остается только указать мастеру требуемый тип репликации – снимок (Snapshot publication), транзакции (Transaction publication) или смешение (Merge publication) и указать необходимые таблицы. Да, в репликации участвует не вся база, а указанные таблицы. Системные таблицы реплицировать незачем.

Выбор типа репликации

После создания издателя необходимо создать подписчика и настройку можно считать завершенной. Во время создания подписчика ты сможешь настроить план выполнения, указать дни, время или промежутки, через которые нужно выполнять репликацию.

Если ты настроил репликацию, и решил перенести базу данных на другой сервер, то можешь забыть про перенос через резервное копирование и восстановление. Дело в том, что в резервную копию не попадает информацию о репликации :(. Тут приходиться отключать базу Detach, копировать файлы на другой компьютер и подключать их заново Attach.

ДНК-полимераза

ДНК-полимеразы добавляют нуклеотиды к 3′-концу цепи ДНК. Если несоответствие случайно включено, дальнейшее удлинение полимеразы ингибируется. Вычитка удаляет несовпадающий нуклеотид, и расширение продолжается.

ДНК-полимеразы — это семейство ферментов, которые осуществляют все формы репликации ДНК. ДНК-полимеразы в целом не могут инициировать синтез новых цепей, а могут только удлинить существующую цепь ДНК или РНК в паре с цепью-матрицей. Чтобы начать синтез, необходимо создать короткий фрагмент РНК, называемый праймером , и соединить его с цепью ДНК-матрицы.

ДНК-полимераза добавляет новую цепь ДНК, удлиняя 3′-конец существующей нуклеотидной цепи, добавляя новые нуклеотиды, соответствующие цепочке матрицы, по одному за счет создания фосфодиэфирных связей . Энергия для этого процесса полимеризации ДНК происходит от гидролиза высокоэнергетических фосфатных (фосфоангидридных) связей между тремя фосфатами, прикрепленными к каждому не включенному основанию . Свободные основания с присоединенными к ним фосфатными группами называются нуклеотидами ; в частности, основания с тремя присоединенными фосфатными группами называются нуклеозидтрифосфатами . Когда нуклеотид добавляется к растущей цепи ДНК, образование фосфодиэфирной связи между проксимальным фосфатом нуклеотида и растущей цепью сопровождается гидролизом высокоэнергетической фосфатной связи с высвобождением двух дистальных фосфатов в виде пирофосфата. . Ферментативный гидролиз полученного пирофосфата в неорганический фосфат потребляет вторую высокоэнергетическую фосфатную связь и делает реакцию необратимой.

В целом, ДНК-полимеразы обладают высокой точностью, с частотой внутренних ошибок менее одной ошибки на каждые 10 7 добавленных нуклеотидов. Кроме того, некоторые ДНК-полимеразы также обладают способностью корректировать; они могут удалять нуклеотиды с конца растущей нити, чтобы исправить несовпадающие основания. Наконец, механизмы восстановления несоответствия после репликации контролируют ДНК на предмет ошибок, будучи способными отличить несовпадения во вновь синтезированной цепи ДНК от исходной последовательности цепи. Вместе эти три этапа дискриминации обеспечивают точность репликации менее одной ошибки на каждые 10 9 добавленных нуклеотидов.

Скорость репликации ДНК в живой клетке сначала измеряли как скорость удлинения ДНК фага Т4 в инфицированной фагом E. coli . В период экспоненциального увеличения ДНК при 37 ° C скорость составила 749 нуклеотидов в секунду. Частота мутаций на пару оснований на репликацию во время синтеза ДНК фага Т4 составляет 1,7 на 10 8 .

Если упираемся в процессор

вот результаты всё тех же sysbench тестов

MTS на слейве достигает 10-кратного увеличения производительности по сравнению с однопоточной репликацией
использование уже приводит к росту пропускной способности слейва в более чем 3.5 раза
производительность row-based репликации практически всегда выше, чем statement-based. Но MTS оказывает больший эффект на statement-based, что несколько уравнивает оба формата с точки зрения производительности на OLTP нагрузках.

Физическая репликация в PostgreSQL

документации по Hot Standby

не поддерживаются, потому что для этого требуется модификация файлов данных
2PC команды не поддерживаются по тем же причинам
явное указание «read write» состояние транзакций ( и т.д.), LISTEN, UNLISTEN, NOTIFY, обновления sequence не поддерживаются. Что в целом объяснимо, Но это значит, что какие-то приложения придётся переписывать при миграции на Hot Standby, даже если никаких данных они не модифицируют
Даже read-only запросы могут вызывать конфликты с DDL и vacuum операциями на мастере (привет «агрессивным» настройкам vacuum!) В этом случае запросы могут либо задержать репликацию, либо быть принудительно прерваны и есть конфигурационные параметры, которые этим поведением управляют
слейв можно настроить для предоставления «обратной связи» с мастером (параметр ). Что хорошо, но интересны накладные расходы этого механизма в нагруженных системах.

failoverОбновлено 28.09.2016:eng.uber.com/mysql-migrationОбновлено 30.10.2017:thebuild.com/blog/2017/10/27/streaming-replication-stopped-one-more-thing-to-checkтоже люди

Логическая репликация в PostgreSQL

что-то приунылкто сказал «разброд»?за них часто критикуют репликацию в MySQLкто сказал «форки»?быстро

Это не репликация как таковая, а конструктор/фреймворк/API для создания сторонних решений для логической репликации
Использование Logical Decoding требует записи дополнительной информации в WAL (требуется установить ). Привет критикам бинарного журнала в MySQL!
Какие-то из сторонних решений уже переехали на Logical Decoding, а какие-то ещё нет.
Из чтения документации у меня сложилось впечатление, что это аналог row-based репликации в MySQL, только с кучей ограничений: никакой параллельности в принципе, никаких GTID (как делают клонирование слейва и failover/switchover в сложных топологиях?), каскадная репликация не поддерживается.
Если я правильно понял эти слайды SQL интерфейс в Logical Decoding использует Poll модель для распространения изменений, а протокол для репликации использует Push модель. Если это действительно так, что происходит при временном выпадении слейва из репликации в Push модели, например из-за проблем с сетью?
Есть поддержка синхронной репликации, что хорошо. Как насчёт полусинхронной репликации, которая более актуальна в высоконагруженных кластерах?
Можно выбирать избыточность информации с помощью опции для таблицы. Это некий аналог переменной в MySQL. Но переменная в MySQL динамическая, её можно устанавливать отдельно для сессии, или даже отдельно для каждого запроса. Можно ли так в PostgreSQL?
Короче говоря, где можно посмотреть доклад «Асинхронная логическая репликация в PostgreSQL без цензуры»?. Я бы с удовольствием почитал и посмотрел.

разных докладах

Master-Slave репликация

В этом подходе выделяется один основной сервер базы данных, который называется Мастером. На нем происходят все изменения в данных (любые запросы MySQL INSERT/UPDATE/DELETE). Слейв сервер постоянно копирует все изменения с Мастера. С приложения на Слейв сервер отправляются запросы чтения данных (запросы SELECT). Таким образом Мастер сервер отвечает за изменения данных, а Слейв за чтение.

Читайте как настроить Master-Slave репликацию на MySQL.

В приложении нужно использовать два соединения — одно для Мастера, второе — для Слейва:

Несколько Слейвов

Преимущество этого типа репликации в том, что Вы можете использовать более одного Слейва. Обычно следует использовать не более 20 Слейв серверов при работе с одним Мастером.

Тогда из приложения Вы выбираете случайным образом один из Слейвов для обработки запросов:

Задержка репликации

Асинхронность репликации означает, что данные на Слейве могут появится с небольшой задержкой. Поэтому, в последовательных операциях необходимо использовать чтение с Мастера, чтобы получить актуальные данные:

Выход из строя

При выходе из строя Слейва, достаточно просто переключить все приложение на работу с Мастером. После этого восстановить репликацию на Слейве и снова его запустить.

Если выходит из строя Мастер, нужно переключить все операции (и чтения и записи) на Слейв. Таким образом он станет новым Мастером. После восстановления старого Мастера, настроить на нем реплику, и он станет новым Слейвом.

Резервирование

Намного чаще репликацию Master-Slave используют не для масштабирования, а для резервирования. В этом случае, Мастер сервер обрабатывает все запросы от приложения. Слейв сервер работает в пассивном режиме. Но в случае выхода из строя Мастера, все операции переключаются на Слейв.

Общие представления

Репликация ДНК — ключевое событие в ходе деления клетки. Принципиально, чтобы к моменту деления ДНК была реплицирована полностью и при этом только один раз. Это обеспечивается определёнными механизмами регуляции репликации ДНК. Репликация проходит в три этапа:

инициация репликации
элонгация
терминация репликации.

Регуляция репликации осуществляется в основном на этапе инициации. Это достаточно легко осуществимо, потому что репликация может начинаться не с любого участка ДНК, а со строго определённого, называемого сайтом инициации репликации. В геноме таких сайтов может быть как всего один, так и много. С понятием сайта инициации репликации тесно связано понятие репликон. Репликон — это участок ДНК, который содержит сайт инициации репликации и реплицируется после начала синтеза ДНК с этого сайта. Геномы бактерий, как правило, представляют собой один репликон, это значит, что репликация всего генома является следствием всего одного акта инициации репликации. Геномы эукариот (а также их отдельные хромосомы) состоят из большого числа самостоятельных репликонов, это значительно сокращает суммарное время репликации отдельной хромосомы. Молекулярные механизмы, которые контролируют количество актов инициации репликации в каждом сайте за один цикл деления клетки, называются контролем копийности. В бактериальных клетках помимо хромосомной ДНК часто содержатся плазмиды, которые представляют собой отдельные репликоны. У плазмид существуют свои механизмы контроля копийности: они могут обеспечивать синтез как всего одной копии плазмиды за клеточный цикл, так и тысяч копий.

Репликация начинается в сайте инициации репликации с расплетания двойной спирали ДНК, при этом формируется репликационная вилка — место непосредственной репликации ДНК. В каждом сайте может формироваться одна или две репликационные вилки в зависимости от того, является ли репликация одно- или двунаправленной. Более распространена двунаправленная репликация. Через некоторое время после начала репликации в электронный микроскоп можно наблюдать репликационный глазок — участок хромосомы, где ДНК уже реплицирована, окружённый более протяжёнными участками нереплицированной ДНК.

В репликационной вилке ДНК копирует крупный белковый комплекс (реплисома), ключевым ферментом которого является ДНК-полимераза. Репликационная вилка движется со скоростью порядка 100 000 пар нуклеотидов в минуту у прокариот и 500—5000 — у эукариот.

Ферменты и их функции
Фермент	Функция
ДНК-гираза	Вносит временные двуцепочечные разрывы в ДНК, облегчая её разматывание.
Хеликаза	Разделяет цепи двухцепочечной молекулы ДНК на одинарные цепи.
SSB-белки	Связывают одноцепочечные фрагменты ДНК и предотвращают комплементарное спаривание.
Праймаза	Синтезирует РНК-затравку (праймер) — короткий фрагмент РНК, которая является инициатором в работе ДНК-полимеразы (полимераза не способна синтезировать ДНК с нуля, но может добавлять нуклеотиды к уже имеющимся).
ДНК-полимераза	Синтезирует ДНК, связываясь с праймером. Следует отметить, что один конец материнской ДНК полимераза синтезировала непрерывно и в одном направлении, а второй — в противоположном — фрагментами.
Белки скользящего зажима (застежки)	Окружают кольцом ДНК и «скользят» по ней вместе с продвигающейся вперед фермента ДНК-полимеразы. Они предотвращают диссоциацию фермента от матрицы ДНК и повышают эффективность его работы.
РНКаза H	Удаляет уже ненужные фрагменты РНК-затравки.
ДНК-лигаза	Сшивает фрагменты ДНК (фрагменты Оказаки).
Теломераза	Добавляет особые повторяющиеся последовательности нуклеотидов к одному концу цепи ДНК на участках теломер, тем самым компенсируя их укорачивание во время деления.
Реплисома (комплекс всех ферментов репликации)	Движется вдоль молекулы ДНК-матрицы, расплетая её и наращивая комплементарные цепи ДНК.

Ферменты и белки репликации

Удвоение молекулы ДНК можно сравнить с любым метаболическим процессом в клетке, для которого необходимы соответствующие белки. Так как в биологии репликация – это важная составляющая клеточного деления, соответственно, немало вспомогательных пептидов здесь участвуют.

ДНК-полимераза — важнейший фермент редупликации, который отвечает за синтез дочерней цепи дезоксирибонуклеиновой кислоты. В цитоплазме клетки в процессе репликации обязательно присутствие нуклеиновых трифосфатов, которые приносят все нуклеиновые основания.

Эти основания являются мономерами нуклеиновой кислоты, поэтому из них строится вся цепочка молекулы. ДНК-полимераза отвечает за процесс сборки в правильном порядке, иначе неизбежно появление всевозможных мутаций.

Праймаза — белок, который отвечает за формирование затравки на матричной цепи ДНК. Эта затравка называется также праймер, она имеет строение РНК

Для фермента ДНК-полимераза важно наличие начальных мономеров, с которых возможен дальнейший синтез всей полинуклеотидной цепочки. Эту функцию выполняет праймер и соответствующий ему фермент.
Хеликаза (геликаза) формирует репликационную вилку, которая представляет собой расхождение матричных цепей путем разрыва водородных связей

Так полимеразам проще подойти к молекуле и начать синтез.
Топоизомераза. Если представить молекулу ДНК в виде закрученной веревки, при продвижении полимеразы по цепи будет формироваться положительное напряжение из-за сильного скручивания. Эту проблему решает топоизомераза – фермент, который на короткое время разрывает цепочку и разворачивает при этом всю молекулу. После чего поврежденное место сшивается вновь, а ДНК не испытывает напряжения.
Ssb-белки, как грозди, присоединяются к цепям ДНК в репликационной вилке, чтобы предупредить повторное формирование водородных связей раньше окончания процесса редупликации.
Лигаза. Функция фермента заключается в сшивании фрагментов Оказаки на отстающей цепи молекулы ДНК. Происходит это путем вырезания праймеров и встраивания на их месте нативных мономеров дезоксирибонуклеиновой кислоты.

В биологии репликация – это сложный многоступенчатый процесс, который предельно важен при делении клеток. Поэтому использование различных белков и ферментов необходимо для эффективного и правильного синтеза.

Особенности логической репликации:

независимость от формата хранения данных: мастер и слейв могут иметь разные представления данных на диске, разные архитектуры процессора, разные структуры таблиц (при условии совместимости схем), разные конфигурации и расположение файлов данных, разные движки хранения (для MySQL), разные версии сервера, да и вообще мастер и слейв могут быть разными СУБД (и такие решения для «кросс-платформенной» репликации существуют). Эти свойства используют часто, особенно в масштабных проектах. Например, в rolling schema upgrade.
доступность для чтения: с каждого узла в репликации можно читать данные без всяких ограничений. С физической репликацией это не так просто (см. ниже)
возможность multi-source: объединение изменений с разных мастеров на одном слейве. Пример использования: агрегация данных с нескольких шардов для построения статистики и отчётов. Та же Wikipedia использует multi-source именно для этих целей
возможность multi-master: при любой топологии можно иметь более одного доступного на запись сервера, если это необходимо
частичная репликация: возможность реплицировать только отдельные таблицы или схемы
компактность: объём передаваемых по сети данных меньше. В отдельных случаях сильно меньше.

Асинхронность репликации

В MySQL репликация работает в асинхронном режиме. Это значит, что приложение не знает, как быстро данные появятся на Слейве.

Задержка в репликации (replication lag) может быть как очень маленькой, так и очень большой. Обычно рост задержки говорит о том, что сервера не справляются с текущей нагрузкой и их необходимо масштабировать дальше, например техниками горизонтального и вертикального шардинга.

Синхронный режим

Синхронный режим репликации позволит гарантировать копирование данных на Слейв.

Это упростит работу в приложении, т.к. все операции чтения можно будет всегда отправлять на Слейв. Однако это может значительно уменьшить скорость работы MySQL. Синхронный режим не следует использовать в Web приложениях.