Определение проблемы

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

Нагрузка

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

Текущее решение и проблема

Мы используем снимки базы данных . В 10 вечера мы сбрасываем и воссоздаем снимок. Затем начинается обработка ETL. Это явно обременительно для нашего диска, но дает нашим пользователям возможность запрашивать базу данных без блокировки базы данных (они используют внешний интерфейс Access). Они используют его до поздней ночи и рано утром, чтобы заметить время простоя.

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

Рассмотренные подходы

Кластеризация

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

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

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

Администратор начал с репликации моментальных снимков, но он обеспокоен тем, что для создания моментального снимка и требуемого потребления диска требуется несколько дней высокой загрузки ЦП. Он указывает, что кажется, что все данные записываются в физические файлы перед отправкой подписчику, поэтому наша база данных .6 ТБ обойдется в 1,8 ТБ в стоимости хранения. Кроме того, если для создания моментального снимка потребуется несколько дней, он не будет соответствовать желаемому SLA.

После прочтения прекрасной статьи кажется, что Snapshot может быть способом инициализации подписчиков, но тогда мы бы хотели переключиться на Transactional Replication, чтобы после этого синхронизировать его. Я предполагаю, что включение / выключение репликации транзакций не приведет к полной повторной инициализации? В противном случае мы унесем наше временное окно

Зеркальное отображение базы данных

Наша база данных находится в режиме полного восстановления, поэтому зеркалирование базы данных является опцией, но я знаю об этом даже меньше, чем репликация. Я нашел ответ SO, который гласил: «Зеркальное отображение базы данных предотвращает прямой доступ к данным, зеркальные данные доступны только через моментальный снимок базы данных».

Доставка журналов

Похоже, что доставка журналов также может быть вариантом, но это еще одна из тех вещей, о которых я ничего не знаю. Будет ли это более дешевое решение (внедрение и обслуживание), чем что-либо еще? На основании комментария Ремуса «Доставка журналов разрешает доступ к копии реплики только для чтения, но отключает всех пользователей при применении следующего полученного журнала резервного копирования (например, каждые 15-30 минут)». Я не уверен, как долго это время простоя перешло бы в такое состояние, которое могло бы вызвать у пользователей беспокойство.

MS Sync

Я только слышал об использовании Sync в прошлые выходные и еще не исследовал его. Я бы не хотел вводить новую технологию для чего-то с высокой видимостью, как у этой проблемы, но если это лучший подход, пусть будет так.

SSIS

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

САН "волшебный" снимок

В прошлом я слышал о том, что наш администратор использует некоторые технологии SAN для мгновенного резервного копирования целых дисков. Возможно, есть какая-то магия EMC, которую можно использовать для создания uberquick-копий mdf / ldf, и тогда мы можем отсоединить / присоединить целевую базу данных.

Резервное копирование и восстановление

Я думаю, что мы делаем полное резервное копирование один раз в неделю, дифференциалы по ночам и тлог каждые 15 минут. Если бы пользователи могли жить с перерывом в 3-4 часа для полного восстановления, я полагаю, что это может быть подходом.

Ограничения

Windows 2008 R2, SQL Server 2008 R2 (Enterprise Edition), VMWare v5 Enterprise Edition, хранилище EMC SAN с дисками, сопоставленными с файлами vmdk, резервное копирование с обработкой commvault и 0,6 ТБ данных в исходном каталоге. Это стороннее приложение, которое мы размещаем самостоятельно. Изменение их структуры, как правило, осуждается. Пользователи не могут обходиться без запросов к базе данных и отказываются от ограничений, заранее идентифицируя таблицы, которые они контролируют для выполнения своей работы.

Наши администраторы баз данных на данный момент являются исключительно подрядчиками. Работающие на полную ставку отплыли, и мы еще не заменили их. Администраторы приложений не очень хорошо разбираются в вопросах SQL Server, и у нас есть команда администраторов Storage / VM, которые могут помочь / помешать этим усилиям. Команды разработчиков в настоящее время не участвуют, но могут быть зачислены на основе подхода. Так что более простое в реализации и поддержании решение было бы предпочтительным.

Я, я нахожусь на стороне разработки, так что я могу только предлагать подходы, и мне не приходилось иметь дело с административной стороной вещей. Поэтому, не имея времени в административном седле, я не решаюсь сказать, что один подход будет лучше другого - все выглядит великолепно в соответствии с документами. Я полностью готов идти в любом направлении, которое вы мне предложите, потому что, на мой взгляд, это только сделает меня более ценным профессионалом в области БД. У меня есть тачка, но нет плаща Холокоста .

Смежные вопросы

• /programming/525637/what-are-the-scenarios-for-using-mirroring-log-shipping-replication-and-cluste

• /programming/434982/mirroring-vs-replication

• /programming/4303020/sync-databases-mirroring-replication-log-shipping

• /programming/4303020/sync-databases-mirroring-replication-log-shipping

• http://nilebride.wordpress.com/2011/07/24/log-shipping-vs-mirroring-vs-replication/

Правки

Чтобы ответить на вопросы @ onpnt

Принятие задержки данных

В настоящее время пользователи просматривают данные, которые отстают на 24 часа. Данные только актуальные на 2200

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

Подключение к вторичному

Внутренняя сеть, отдельный виртуальный хост и выделенное хранилище

Прочитайте требования на вторичном экземпляре

Группа Windows будет иметь доступ на чтение к вторичным, всем таблицам

Время работы вторичного экземпляра

Не существует четкого определения требования к времени работоспособности. Пользователи хотят, чтобы это всегда было доступно, но готовы ли они платить за это, вероятно, не так много. На самом деле, я бы сказал, что 23 часа в день будет достаточно.

Изменения в существующей схеме и всех объектах

Редкие модификации, возможно, один раз в квартал для табличных объектов. Может быть, один раз в месяц для объектов кода.

Безопасность

Никаких особых требований безопасности. Разрешения на производство будут соответствовать разрешениям копии. Хотя, как я думаю, мы могли бы отозвать доступ пользователей на чтение к prod и разрешить им только читать копию ... Хотя это и не требование.

пролив @darin

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

@cfradenburg

Я предполагал, что мы будем использовать только один из этих подходов, но это хорошая точка зрения, что восстановление нарушит «другие» технологии синхронизации. Они изучают возможности использования магии снимков EMC. Как описал админ, в 1900 они сделают снимок и перенесут изображение в зону вторичного устройства. Это должно завершиться к 2200, и затем они выполнят отсоединение и присоединение вторичной базы данных.

Заворачивать

2012-10-29 Мы оценили магический снимок EMC и некоторые другие варианты репликации, но администраторы решили, что им лучше всего разобраться с зеркалированием. Подняли ответы, потому что все они помогли и дали мне много вариантов, а также «домашнюю работу» для расследования.

Изменение их структуры обычно осуждается

Репликация более чем вероятна, и перед этим я бы выбрасывал Sync. (из реальных трансацитональных тестов на Sync Framework)

Если время ожидания данных составляет 3-4 часа, доставка журналов, вероятно, будет вашей лучшей ставкой на копию только для чтения. Но сколько изменений происходит в журнале? выясните это, следите за этим, чтобы увидеть, как быстро и сколько вам нужно пройти.

Если вы не можете перейти к зеркалированию или обновлению до версии 2012 для предприятия, этого не произойдет, хотя это будет разумной стратегией, если вы сможете перейти на версию Enterprise, если ее нет.

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

Действительно, будет четкое сужение выбора, основанное на ответе на несколько вопросов

• Принятие задержки данных
• Количество изменений данных в данную минуту, час и день. Подключение к вторичному.
• Прочитайте требования на вторичном экземпляре
• Время работы вторичного экземпляра
• Изменения в существующей схеме и всех объектах
• Безопасность

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

Чтобы расширить Log Доставка, вам не нужно восстанавливать журналы каждые 15-30 минут. Если вы решите, вы можете делать это каждые четыре часа или один раз в день. Решение, похожее на это, которое я реализовал, заключается в еженедельном полном резервном копировании и восстановлении базы данных отчетов (что может занять некоторое время и произойдет в выходные дни). В течение недели производятся разностные резервные копии, которые еженедельно восстанавливаются в базе данных отчетов. Пользователи должны быть загружены перед восстановлением, но поскольку база данных отчетов является приложением в рабочие часы, с этим проблем не возникает. Данные - это день, и это не должно быть проблемой в зависимости от ваших требований.

Чтобы использовать для этого зеркальное отображение базы данных, вам необходимо приобрести Enterprise, чтобы иметь возможность использовать моментальные снимки, если вы еще не используете Enterprise. Это также не позволит поддерживать данные на 100% в актуальном состоянии, поскольку снимок необходимо удалить (это означает, что все пользователи должны отсутствовать), а затем создать заново, чтобы получить новые данные. Однако это займет меньше времени, чем восстановление журнала или метод, который я объяснил выше.

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

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

1. Вам не нужно инициализировать подписчика со снимком. Вы можете взять резервную копию издателя и выполнить инициализацию.
2. Вы можете приостановить доставку команд подписчику, просто остановив задание распространения (это обычное задание агента SQL либо у распространителя, либо у подписчика, в зависимости от того, настроили ли вы его как push или pull подписки соответственно). Просто помните о том, что вы удерживаете у дистрибьютора так, чтобы у вас было достаточно истории, чтобы вы могли наверстать упущенное.
3. Вы можете изменить индексирование на подписчике, чтобы приспособиться к рабочим нагрузкам, которые будут там выполняться (предположительно, по типу отчетов), вместо того, чтобы принимать индексирование от вашего издателя (предположительно по типу OLTP), если хотите.