Мы только что перешли с SQL Server 2000 на SQL Server 2008.
В 2000 году мы использовали нашу собственную доставку журналов для аварийного переключения. В 2008 году нам нужно решить использовать нашу собственную доставку журналов, встроенную доставку журналов или репликацию.
У нас на сервере много баз данных (400+); некоторые маленькие, некоторые большие.
Сбой сервера БД должен быть редким, и мы можем допустить 15-30-минутную потерю данных. Более важным является быстрое включение второго сервера БД.
Исходя из приведенных выше критериев, что мне лучше с доставкой журналов или репликацией?
Если доставка журналов, есть ли простой способ обеспечить ее перемещение по всем БД?
Для всех, кто предлагает зеркальное отображение - зеркалировать 400 баз данных будет невозможно. У вас закончатся рабочие потоки задолго до того, как вы достигнете 400, будь то 32- или 64-разрядная версия. Есть не менее 2 рабочих потоков на каждую базу данных на главном сервере и не менее 3 на базу данных на зеркале.
На самом деле это не имеет ничего общего с навыками администратора базы данных. Это полностью зависит от требований к высокой доступности для бизнеса или приложения - это движущие факторы, а не то, с чем может справиться администратор баз данных. Если более сложное решение обязательный, а затем получить от администратора базы данных, что сделка с ним также обязательный. Ограничивать ваше решение высокой доступности из-за навыков администратора базы данных бессмысленно.
Зеркальное отображение базы данных также не является быстрым обнаружением и быстрой отработкой отказа - оно полностью зависит от того, в чем заключается сбой, каков тайм-аут партнера по зеркалированию, каковы очереди SEND и REDO. Для завершения аварийного переключения может потребоваться довольно много времени, если зеркало решит сделать его основным. Я помог многим клиентам внедрить зеркальное отображение (как в Microsoft, когда я владел зеркалированием базы данных вместе с остальной частью Storage Engine), так и с тех пор, как ушел в 2007 году.
Забудьте о зеркальном отображении для такого количества баз данных.
Прежде чем мы сможем дать вам рекомендацию, вам необходимо ответить на несколько фундаментальных вопросов:
Доставка журналов, вероятно, самая простая для вас, как с точки зрения ее настройки, мониторинга, так и с точки зрения возможности быстро доставить избыточные копии в пределах ваших ограничений на потерю данных. При доставке журналов вы можете перевести избыточные копии в оперативный режим, не завершая восстановление всех резервных копий журналов транзакций, поставленных в очередь на восстановление, приняв потерю данных.
Вы также можете выполнить простую отработку отказа, используя технологию маршрутизации среднего уровня, или даже что-то более простое, как Windows NLB с конфигурацией 0/100 или переключение на 100/0. Я также видел клиентов, использующих переключение DNS для отработки отказа, когда имя сервера не может измениться.
При репликации приходится иметь дело с непредсказуемой задержкой между транзакциями, которые собираются из журнала транзакций базы данных публикации, попадают в базу данных распространителя и затем передаются / извлекаются в базу данных подписки агентом распространения. Репликация также может быть запутана, и ее сложно понять и сбросить - доставка журналов очень проста.
Учитывая, что вы использовали собственную доставку журналов, я предполагаю, что скорость генерации журналов транзакций и пропускная способность сети не являются проблемой - я бы придерживался доставки журналов и избегал репликации. Даже не думайте о зеркальном отображении базы данных, так как это не сработает для вашего тома.
Надеюсь, это поможет - это действительно двухдневная дискуссия, когда я преподаю HA администраторам баз данных внутри Microsoft - на ответ на это ушло всего 5 минут. Не стесняйтесь отвечать на более конкретные вопросы в комментариях.
Вот еще несколько мыслей:
Я не верю, что репликация - лучший способ. Я обычно смотрю на репликацию как на способ распространения данных, а не как на решение аварийного восстановления. При попытке реплицировать 400 баз данных вы, скорее всего, столкнетесь с нагрузкой на роли распространителя и издателя, что в конечном итоге может поставить сервер на колени. Кроме того, реализация, управление и обработка изменений схемы будет кошмаром, поскольку вам потребуется настроить издателя и подписчика для каждой базы данных.
С точки зрения доставки журналов, да, это можно сделать, однако, опять же, это будет сложно реализовать и управлять, поскольку вам придется реализовать доставку журналов для каждой базы данных. Если произойдет сбой, вам придется вручную перевести каждую базу данных в оперативный режим и перенаправить все свои приложения. В зависимости от вашей рабочей нагрузки, скорее всего, решение не будет масштабироваться до 400 баз данных. Так что, пожалуйста, проверьте.
При работе с таким количеством баз данных лучше реализовать решение Geo-Cluster или использовать какую-либо форму репликации SAN и работать на уровне тома или блока. Если у вас нет SAN, то стороннее программное обеспечение, такое как InMage или Doubletake, может помочь.
Помните, что каждая технология, такая как доставка журналов, зеркальное отображение базы данных или репликация, может значительно увеличить рабочую нагрузку и отрицательно повлиять на производительность серверов, поэтому проведите тестирование производительности перед запуском в производственную среду.
Если вы решите использовать доставку журналов, вы можете записать весь процесс, включая отработку отказа.
Росс Мистри, SQL MVP
Автор - SQL Server 2008 Management and Administration и Windows Server 2008 Unleashed
Twitter - @RossMistry
Мы используем зеркалирование для мгновенного восстановления на месте.
Для резервного копирования за пределы WAN (например, с высокой задержкой) мы используем встроенную доставку журналов.
Обратите внимание, что для ЛЮБОЙ опции вы должны настроить эту БАЗУ ДАННЫХ, что для 400 БД будет огромной болью в тылу.
Вы используете массив хранения (SAN или NAS)? Самый простой метод - это репликация на уровне блоков с помощью привязок к вашему массиву хранения (с соответствующим подключаемым модулем стабилизации SQL Server), которая автоматически захватывает ВСЕ базы данных.
Это во многом зависит от навыков вашего администратора базы данных.
Если у вас есть опытный администратор базы данных, то зеркалирование - самый безопасный вариант с самым быстрым отказом, если вы настроите его со следящим сервером, тогда «клиент» не должен заметить ничего, кроме небольшого отставания. Если ваш администратор базы данных менее опытен, доставка журналов - это путь, но он имеет более длительную и сложную процедуру аварийного переключения, которая включает воспроизведение транзакций, которые еще не были зафиксированы в основном файле данных и не были переданы. Если вы хотите потерять не более 15–30 минут данных, лучшим вариантом будет зеркалирование.
Если вы делаете это только с двумя серверами, вам следует установить его в режим высокой безопасности. Третий дополнительный сервер-свидетель может быть экспресс-экземпляром SQL2008, поэтому у вас не будет минимальной стоимости оборудования, поэтому не исключайте это как вариант.
Я написал руководство о том, как зеркалировать два сервера SQL 2005, которые не являются членами домена в этом режиме, и оно доступно @ http://danmacs.blogspot.com/2009/05/database-mirroring-for-non-domain-ms.html
В этом сценарии аварийное переключение выполняется вручную (но быстро), существует только вероятность потери одной транзакции (при условии, что ваше зеркало работает правильно) НО клиенты, которые подключаются к нему, необходимо будет переместить вручную (или через изменение DNS, если вы используете TCP / IP и не используете именованные каналы, именованные каналы могут очень хорошо работать, но я не могу сказать наверняка)
Сколько денег у вашей компании?
Если они флеш и есть требование переехать все баз данных тогда двухузловой активный / пассивный кластер с теплой репликацией SAN на другой активный / пассивный кластер за пределами площадки сделает свое дело :)
Если нет, то придерживайтесь доставки журналов - 2008 Enterprise предоставляет вам преимущества сжатых резервных копий журналов (за счет ЦП), а все выпуски SQL, начиная с 2005 года, имеют возможность создавать резервные копии журналов одновременно с полными резервными копиями (что было проблематично. на 2000 ящиков с большими объемами транзакционной активности).
Является ли вторая БД исключительно для аварийного переключения или вы также хотите использовать ее, например для отчетности MI.
Вы тоже смотрели на зеркалирование?
Есть ли у вас для этого бюджет или вы хотите использовать внутренние инструменты. Раньше я использовал как доставку журналов, так и репликацию, но в настоящее время я использую Double Take, что до сих пор было фантастическим.
Если вы потратили много времени на создание системы для ручного ведения журнала поставок более 400 баз данных, и она работает, я бы остановился на ней. Если это сколочено, и продолжать бегать (побывать там) больно, возможно, пришло время для перемен и перейти к зеркалированию.
Если вы попытаетесь использовать зеркальное отображение базы данных, я думаю, что у вас закончатся рабочие потоки задолго до того, как вы дойдете до 100 баз данных, не говоря уже о 400+. Посмотри на этот.
Каждая зеркальная база данных использует пару потоков, а SQL Server по умолчанию настроен для работы только с 255 потоками. Когда у вас заканчиваются рабочие потоки, происходят неприятные вещи. Я запускал серверы, которые были настроены с большим количеством потоков (512, IIRC), но, похоже, MS очень нервничала. Делать что-то, что заставляет РС нервничать, как правило, плохо кончается.
Я думаю, что вы могли бы пойти с 400 базами данных с доставкой журналов, если предположить, что журнальный трафик не слишком большой и что вы напишете некоторые инструменты, которые помогут вам с их настройкой и мониторингом. Инструменты могут быть написаны на tsql или чем-то вроде powershell.
Для меня настоящие проблемы с доставкой журналов заключались в том, чтобы убедиться, что у вас есть те же логины / пакеты / связанные серверы / и т. Д. На другом сервере, убедившись, что те же задания находятся на сервере аварийного переключения (но отключены, пока вам не понадобится чтобы включить их, и вам нужен способ их включения и отключения), не назад на исходный первичный сайт, как восстановить доставку журналов, когда последовательность журналов нарушается по какой-либо причине, и тому подобное. При развертывании легко забыть сделать другой сервер.
http://msdn.microsoft.com/en-us/library/ms366349(SQL.90).aspx
Говорит, что 10 зеркальных БД - это максимум для 32-битной машины.