Для системного администратора

Синхронная
Синхронная репликация – это зеркалирование данных на две системы хранения или два дисковых раздела внутри одной системы.
Популярный RAID-1 («зеркало») для дисковых контроллеров есть по сути просто синхронная репликация на два диска, выполняемая контроллером диска. При этом каждый блок данных записывается более или менее одновременно, параллельно, на оба устройства. Аналогичным образом это осуществляется на два «диска» в разных дисковых системах хранения.
Это «идеальная репликация», обе копии данных полностью идентичны, потому что пока данные не будут гарантированно записаны на оба устройства, оно не может приступить к записи следующего блока.
Однако теоретическая идеальность в реальной жизни оказывается ограничением.


Как мы видим, общая скорость системы ограничена самым узким каналом передачи данных. Если мы соединены с системой хранения FC-каналом в 4GB/s, а система хранения синхронно реплицируется на удаленную систему по каналу в 10MB/s, то скорость обмена по FC-каналу 4GB/s будет 10MB/s и ни байтом больше.

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

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

«Полусинхронная»
Вариантом, сочетающим в себе возможности синхронной и асинхронной репликации, является так называемая «semi-synchronous» репликация, или «полусинхронная».
В этом случае репликация проводится синхронной до тех пор, пока это позволяет быстродействие системы или канала связи. А затем, вместо замедления и остановки операций записи, временно переключается в асинхронный режим, продолжая обрабатывать поступающие данные без задержек, отправляя данные репликации в асинхронном режиме до тех пор, пока не возникнет возможность восстановить синхронный режим.

Проблемы консистентности
Для любой репликации отличной от синхронной серьезной проблемой является также “проблема консистентности”. Рассмотрим ее на простом примере.
Узел хранения А асинхронно реплицирует данные на узел хранения Б.
На устройстве хранения работает база данных, которая обрабатывает запросы, например финансовой системы.

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

Если вы работаете с базами данных и используете асинхронную или semi-synchronous репликацию, то не забывайте об этой особенности асинхронности в применимости к репликации баз данных и подобных им задач.

Взято с about NetApp