В настоящее время я размещаю около 400-500 баз данных SQL 2005 разного размера (1-10 гигабайт) каждая. Мне известно о большинстве различных доступных методов и общих плюсах и минусах зеркалирования, доставки журналов, репликации и кластеризации, но я не знаю, насколько хорошо они работают, когда они используются в указанном мною размере (400- 500 уникальный базы данных).
Есть ли у кого-нибудь хороший совет о том, какой, вероятно, лучший способ иметь возможность переключиться на другой сервер с такой настройкой?
Отказ не обязательно должен быть немедленным, я просто ищу что-то получше, чем делать резервные копии каждый день и перемещать их в хранилище. Я предпочтительно ищу что-то, что также упростило бы массовое управление базами данных (а не по одной за раз).
Спасибо за ваш вклад!
Угадайте, что ваше целевое решение будет вращаться вокруг вопроса о том, чего вы действительно хотите?
Если вам нужна HA, то, на мой взгляд, вы могли бы рассмотреть возможность кластеризации с учетом количества баз данных в одном экземпляре (я предполагаю, что это так).
Если вам нужна возможность аварийного восстановления и вы беспокоитесь о том, что ваша инфраструктура хранения подведет вас, то мы действительно говорим о втором сайте (логическом или физическом) и вариантах, доступных для этого сценария. Зеркальное отображение в этом случае было бы невозможным для такого количества баз данных. Отправка журналов - это вариант, но управляемость будет проблемой, как правильно указал Farseeker. Кроме того, при репликации возникают схожие проблемы.
Я предполагаю, что это оставляет нас в стороне от возможной аппаратной репликации, как было предложено как Farseeker, так и no_one выше. Это может быть объединено с возможностью геокластеризации Windows2008, чтобы предоставить вам отличные возможности HA и DR. Хотя в эти тяжелые экономические времена это могло быть более подходящим решением.
Еще один радикальный вариант - вложить деньги в что-то вроде HP Polyserve или Шкала Ккото.
Надеюсь это поможет.
Вам следует поговорить с поставщиком хранилища и узнать, предоставляют ли они аппаратную репликацию. Это будет намного быстрее, чем любое другое решение, которое вы могли бы придумать.
Я использую 3 довольно большие базы данных и реплицирую их по SAN как для резервного копирования (резервное копирование выполняется на реплике), так и для проверок dbcc и для целей горячего резервирования. Вначале это было кошмаром, но после настройки работает замечательно.
У меня есть 3 базы данных по 8–12 ТБ каждая, размещенные в EMC SAN, каждая из которых работает на отдельном сервере. Сначала мы реплицируем его по тому же SAN, монтируем на другом хосте, подключенном к SAN, и используем реплицированную копию для автономного резервного копирования и проверки DBCC, а также для пакетной отчетности. Для этого мы используем менеджер репликации.
Мы также выполняем копирование из SAN в SAN каждые 3 дня для резервного копирования второй линии.
Это был кошмар - у нас ушло довольно много времени. Нас перевели из EMC в Dell и обратно. Накричав на них, они наконец послали кого-то, кто действительно знал, что он делал. Я хотел использовать NetApp, так как у меня довольно большой опыт работы с ним, но начальство меня отвергло. Судя по всему, Dell предложила им более выгодную лизинговую сделку.
Честно говоря, последние 2 года он нам очень хорошо служил.
HTH
Мы используем доставку журналов на резервный сервер, и поскольку она работает без файлов журналов, влияние на сервер (за исключением начальной копии) незначительно.
Мы запускаем нашу каждые 15 минут (у нас около 75 баз данных), однако я подозреваю, что в 500 базах данных, запускаемых каждые 15 минут, это будет означать, что к тому времени, когда будет завершена последняя, первая будет просрочена, поэтому вам может потребоваться немного разложи свой.
Вы можете создать сценарий конфигурации доставки журналов, однако ее необходимо настроить с двух сторон (исходная и конечная). Я подозреваю, что это может быть довольно много.
Другой вариант - резервное копирование на уровне блоков, как предложил no_one. Дубль есть продукт, который будет выполнять блочную репликацию вашего SQL-сервера (я считаю, что это очень дорогой вариант для и без того дорогостоящего продукта) - вы просто указываете ему свои папки данных и журналов, а он позаботится обо всем остальном.
Мы использовали DoubleTake для других баз данных, отличных от SQL (BTrieve), и он работал очень хорошо, а задержка при репликации составляла всего 20 секунд или около того.
Я использовал DoubleTake примерно год назад. Это позволило нам довольно быстро и с высокой степенью сжатия реплицировать от 70 до 90 (количество растет ежемесячно) баз данных на DR. Как заявил Farseeker, он позволяет репликацию на уровне блоков, которая работает довольно хорошо. Это также позволяет создавать очередь для тех случаев, когда существует большая транзакционная нагрузка.
Единственная проблема, которую я действительно вижу для вашего экземпляра, - насколько тяжелы эти базы данных? У меня есть как минимум 5 баз данных размером более 10 ГБ с большим объемом транзакционных данных в часы пик и на рабочих местах, от 1 до 3 ГБ в день на каждую базу данных. В общем, ежемесячная передача более 800 + ГБ по проводам (в сжатом виде, конечно, НАМНОГО меньше). С момента добавления дополнительных 20+ баз данных за последние 15 месяцев я наблюдал чрезмерно высокий уровень ввода-вывода, связанный с очередью на диск. Поэтому может возникнуть проблема при попытке использовать что-то подобное, если большинство ваших баз данных очень загружены. Вы можете получить недостающие данные или получатель, если у вас слишком много очереди, и ваша ссылка не работает. Конечно, это будет иметь значение только для развертывания аварийного восстановления. Но пристальное наблюдение за этим и настройка пропускной способности очень помогут уменьшить очередь.