Я работаю над решением, использующим SQL Server 2012 SP2, но без использования групп доступности AlwaysOn. Это связано с транзакциями между базами данных, что не работает для этого сценария.
Примечание: эта проблема решается, пока мы говорим, но добавлена в качестве справочной информации к моей проблеме.
Мы используем решение HP 3PAR StoreServ для получения синхронной репликации между сайтами через SAN. Это позволяет сценариям аварийного восстановления работать на нескольких площадках, поэтому мы можем переключаться на наш вторичный сервер.
Меня беспокоит значение RPO, равное 0, потому что существуют сценарии, в которых данные могут быть потеряны и произойдет повреждение. Например, связь между сайтами разрывается, затем отключается основной.
У меня следующие вопросы:
ИЛИ
Если ссылка разорвана, буферизует ли SAN блок, пока соединение не будет восстановлено?
Если ссылка разрывается во время записи журнала TL и происходит аварийное восстановление, не означает ли это, что у нас будет потенциально поврежденный TL, записанный на вторичный сайт, и, следовательно, потеря данных? Потеря данных происходит только из-за того, что первичный смог выполнить фиксацию, а вторичный не смог синхронизироваться.
Является ли нулевое значение RPO гарантией для всего стека (SQL Server / память / сеть / SAN / IO)?
Из технического документа HP 3PAR StorageServ: Решения репликации для требовательных отказоустойчивых сред, стр. 6:
Для решений с синхронной репликацией RPO решения всегда равен нулю. Однако для решений с асинхронной репликацией RPO всегда будет больше нуля. Асинхронный периодический режим - это асинхронная репликация. В результате при разработке решения, использующего асинхронную периодическую репликацию, RPO становится проблемой.
SAN гарантирует RPO с нулевым допуском, так что, когда сеть умирает, SAN не позволяет изменениям проникнуть в ввод-вывод?
Обновить:
Я нашел эту информацию на странице 12 ссылки выше:
Синхронная топология на большие расстояния
Топология синхронного удаленного копирования с удаленным копированием (SLD) - единственная поддерживаемая сегодня топология, которая позволяет реплицировать тома в группе томов удаленного копирования из одного исходного массива StoreServ в два разных целевых массива StoreServ. Это достигается путем синхронной репликации данных между двумя массивами StoreServ (массивы «Источник» и «Целевая синхронизация»), одновременно реплицируя одни и те же данные в периодическом асинхронном режиме в третий массив StoreServ, массив аварийного восстановления или массив «Асинхронная цель». У пользователя есть возможность обрабатывать два синхронизирующих массива в режиме «активный-активный», переключаться между ними, если / когда сбой в центре обработки данных требует аварийного переключения, и возобновлять операции с массивом «Sync Target». Это обеспечивает решение аварийного переключения, которое обеспечивает нулевое значение RPO из-за синхронного характера репликации, которая происходит между массивами синхронизации.
При переключении на массив Sync Target пассивная асинхронная периодическая связь между этим массивом и массивом Async Target становится активной, и любые данные, которые были реплицированы в Sync Target, но еще не попали в массив Async Target, отправляются из Sync Целевой массив для Async Target, обновляющий массив Async Target до последней записи, которая произошла в Sync Target. Затем операции продолжаются в центре обработки данных Sync Target, и он продолжает реплицировать данные в массив Async Target.
Исходя из этой информации, вам действительно нужна третья конечная точка для участия в асинхронной репликации, чтобы вторичный сайт мог быть информирован об изменениях при разрыве сетевого соединения.
Я не могу комментировать конкретно 3PAR, но у меня есть большой опыт работы с массивами EMC Symmetrix.
Мой совет: найдите другой способ. Синхронная репликация - одна из тех технологий, которые отлично выглядят на бумаге и в оптимальных условиях, но в реальном мире вызывают огромную боль.
Как это работает:
Это «RPO 0» в том смысле, что ЕСЛИ ОН НА ДИСКЕ, он находится на удаленном сайте. Большинство приложений используют кэширование памяти, которое будет потеряно при аварийном восстановлении. Однако за это приходится платить:
Вам потребуется достаточная общая пропускная способность для вашего удаленного сайта, которой всегда будет достаточно для обслуживания требований репликации - в противном случае ваши основные системы сильно пострадают, потому что латентность диска резко возрастет. если ты Когда-либо пропустите эту ссылку, вы пострадаете, и ваша основная служба может просто вылететь.
У вас всегда будет задержка, и в результате пострадает ваша производительность.
Возможно, обе эти вещи «в порядке». По моему опыту, RPO0 и «синхронная репликация» обычно обсуждаются только тогда, когда у вас есть действительно важные вещи.
Чтобы ответить на ваши вопросы прямо:
Does the SAN deny data writes to the I/O until synchronisation has completed?
Нет - он «догонит» в асинхронном режиме перед переходом в режим синхронизации. Это может занять некоторое время в зависимости от пропускной способности, и пока она не будет синхронизирована, у вас не будет «0 RPO».
If a link is severed, does the SAN buffer the block changes until the connection is restored?
Немного зависит от вашей конфигурации. Как правило, он будет рассматривать приостановку / возобновление ссылки как событие, которое необходимо для асинхронной повторной синхронизации. Пока ссылка отсутствует, ваш RPO больше не равен нулю. Вы можете «заблокировать» ввод-вывод при сбое соединения, но это, вероятно, просто приведет к сбою вашего приложения.
If a link is severed during a TL log write, and a DR occurs, doesn't this mean that we will have a potentially corrupt TL written to the secondary site, and therefore incur data loss? The data loss is only because the primary was able to commit, but the secondary was not able to synchronise.
Нет - синхронизация означает синхронизацию. Если вы синхронизированы, любой ввод-вывод на диске также находится на удаленном компьютере. Любой ввод-вывод не на диске теряется, поэтому вы можете потерять свои последние транслоги.
Is RPO of zero ever a guarantee across the stack (SQL Server / Memory / Network / SAN / IO)?
RPO - это точка восстановления. Если ваша цель (действительно) нулевая, то ... вам нужно очень хорошо подумать о своей архитектуре. Это достижимо, но невероятно дорого.
Лично я бы предложил вместо синхронизации:
Запустите свои основные хранилища данных в асинхронном режиме и полагайтесь на свои журналы, чтобы обеспечить бит «синхронизации». Ваш "RPO0" - практически говоря - в любом случае будет только "вашим преданным транслогом". Таким образом, NFS (CIFS?) Монтирует удаленный диск и записывает ваши транслоги по сети, а также в «локальное» хранилище, и воспроизводит их в вашей - несколько минут без синхронизации - базе данных.
В любом случае вы получите примерно такую же точку восстановления - потому что я очень сомневаюсь, что вы захотите использовать данные, которые не ведутся в журнале, - и вы сделаете это без необходимости дорогостоящих операций синхронизации.