У нас есть веб-приложение, которое использует SQL Server 2008 на одном сервере базы данных. Все хранилище локальное. В течение последнего года мы пытались заставить любую форму репликации SQL Server работать с нашей конфигурацией, но это не так. Причина в том, что у нас есть более 2000 баз данных, которые постоянно обновляются (по одной для каждого из наших клиентов), поэтому наши тесты показывают, что все формы репликации слишком ресурсоемки.
Каждый раз, когда я задаю этот вопрос, люди обращают внимание на то, что у нас слишком много баз данных. Это то, что нельзя изменить (по нормативным и другим причинам), поэтому я хотел бы сосредоточиться на том, как мы можем реплицировать данные.
Нам сказали, что один из вариантов - переместить все данные в SAN и позволить SAN реплицировать данные (или делать частые снимки). Однако, если наш сервер базы данных выйдет из строя, существует ли риск повреждения базы данных в этом случае? Можно ли использовать SAN, реплицированную в другой SAN, чтобы обеспечить достойное решение для аварийного восстановления (в нашем случае мы можем потерять до 30 минут данных, но мы не можем потерять ценность целого дня ... т.е. мы можем » t перейти к резервной копии предыдущей ночи).
Как упоминалось в других ответах:
Для зеркального отображения баз данных в старом стиле и AlwaysOn в новом стиле нужны потоки, и у вас определенно закончится поток с 2000 базами данных. Я напомню, что практический предел намного ниже 200 баз данных. (Где-то есть официальный документ по этому поводу, но я слишком ленив, чтобы искать его прямо сейчас, а этот ответ уже очень длинный.) Конечно, 200 баз данных на экземпляр. Теоретически вы можете запустить 20 экземпляров и запустить 100 баз данных на каждом экземпляре. Управление всем этим было бы проблемой, и я подозреваю, что управление памятью между всеми этими экземплярами будет головной болью.
Репликация SQL Server (репликация таблиц (или подмножеств таблиц), а не файлов) на самом деле не предназначена для аварийного восстановления. Даже для нескольких баз данных сложно настроить и администрировать. Возможно, вам придется изменить модель данных, чтобы заставить ее работать, что может означать изменения в вашем приложении. Вам понадобится автоматизированный способ применения одной и той же конфигурации репликации к каждой из ваших 2000 (предположительно идентичных или почти идентичных) баз данных. Хранимые процедуры, которые вам нужно использовать для настройки репликации, беспорядочные. Администрирование 2000 баз данных, настроенных для репликации через графический интерфейс, было бы кошмаром. Когда / если вы выполняете аварийное переключение, вам может потребоваться внести изменения, чтобы все снова заработало. Время отработки отказа - это не время, когда вы хотите делать какие-либо привередливые изменения или работу, которых можно избежать. Вы хотите как можно скорее вернуть все в исходное состояние и запустить его. Это просто похоже на кучу проблем.
Репликация между хранилищами SAN может быть дорогостоящей, особенно если вы говорите об оборудовании от такой организации, как EMC. Как только вы начинаете с поставщика, вы в значительной степени женитесь на нем в плане обновлений, обслуживания, дополнительного места и т. Д.
Предложение №1: Вы смотрели что-то вроде DataKeeper Стили? Это программный продукт репликации, который работает на ваших серверах и использует отказоустойчивую кластеризацию Windows. На самом деле я никогда не использовал его, и у меня нет никакой связи с компанией, кроме как сидеть на нескольких выставках собак и пони. Выглядит идеально для вашей ситуации.
Предложение №2: Если бы это был я и у меня совсем не было бюджета, я бы посмотрел на какую-нибудь самодельную систему доставки бревен. Я сомневаюсь, что встроенная доставка журналов очень хорошо справится с 2000 базами данных. Написать систему доставки журналов не так уж и сложно, и она может решить все проблемы, характерные для вашей среды. (Например, возможно, вам нужно отправить файлы через sftp на ваш сайт аварийного восстановления.)
По сути, система состоит из трех частей. Каждая часть должна работать по регулярному расписанию:
Одна часть берет резервные копии журнала транзакций, помещая файлы резервных копий tlog для каждой базы данных в другую папку (для масштабирования файловой системы). Я бы не стал использовать для этого мастер обслуживания, я слишком много раз видел, как он шатается, начинает пропускать базы данных и вообще плохо себя вести. Если вы хотите предоставить 30-минутную гарантию, возможно, это будет выполняться каждые 15 минут.
Одна часть копирует файлы резервных копий из промежуточной области на ваш сайт аварийного восстановления. Это может быть что-то простое, например CMD-файл robocopy, если у вас есть VPN для вашего DR. Вы можете написать пакет или сценарий PowerShell, если вам нужно что-то более интересное (sftp или ssh / scp, или, возможно, zip / unzip, если у вас нет встроенного сжатия резервных копий). Это может выполняться быстрее, может быть, каждые 5 минут, чтобы убедиться, что он получит все. Когда что-то копируется за пределы сайта, это «безопасно».
Вам нужны таблицы, которые проверяют все три шага, некоторые отчеты / сценарии, которые показывают вам, что произошло (работает ли конкретная база данных на вашем первичном или вторичном сайте? Может ли какая-либо база данных на вторичном сайте не увидеть восстановление tlog, скажем, за два часа? ) и схему оповещения.
Вдобавок ко всему, я бы также хотел иметь возможность выбрать конкретную базу данных для аварийного переключения, а также иметь возможность аварийного переключения всего. Возможность выбрать базу данных для аварийного переключения позволяет легко проводить тестирование (вы переключаете тестовую базу данных, а не базу данных клиента) и может дать вам элементарную схему балансировки нагрузки, если у вас возникнут проблемы с масштабированием. Вам также понадобится автоматический способ «повторной синхронизации» между первичным и вторичным (взять полную резервную копию с первичного и применить его к вторичному, запустить поток протоколов и т. Д.) Эти функции могут быть лучше для версии 2.0.
(Все забыли, что самая ранняя доставка tlog, поддерживаемая MS, была реализована с помощью нескольких скриптов, которые вы могли загрузить и запустить на SQL 7.0. Был графический интерфейс пользователя, пользовательский интерфейс представлял собой несколько отчетов SQL и несколько хранимых процедур.)
Помимо написания небольшого кода tsql, существуют следующие проблемы:
Переход на модель полного восстановления (мне кажется, что вы можете использовать простую модель восстановления) и увеличение использования хранилища, которое, вероятно, для резервных копий журналов, увеличение размеров базы данных и т. Д.
Убедитесь, что ваша система хранения может справиться с нагрузкой частых резервных копий tlog, и своевременно скопируйте их на сайт аварийного восстановления. IOW, если у вас есть 2000 баз данных и вы хотите гарантировать данные до последнего часа, вам необходимо сделать одну резервную копию журнала транзакций для каждой из этих 2000 баз данных и перенести ее в сетевое хранилище (где-то, что не на вашем основном сервере. ).
Убедиться, что в целом все идет в ногу.
После того, как у меня все заработало, я бы начал заниматься автоматизацией аварийного переключения, как сообщать своим веб-сайтам, где работает действующая версия базы данных конкретного клиента и т. Д. Если вы не используете кластерные системы, убедитесь, что вы синхронизировать все логины / пароли, задания, связанные серверы и т. д. и т. д. - это PITA.
Да, есть вероятность того, что база данных будет повреждена, это то же самое, как если бы коробка потеряла питание (у вас есть «постоянство сбоев»).
ОДНАКО движки баз данных принимают много мер предосторожности. Каждый раз, когда вы меняете данные в своей базе данных, он говорит: «Я собираюсь внести изменение», затем он вносит изменения, затем он говорит: «Я сделал изменение». Уровень детализации зависит от того, как он настроен, но вы почти всегда можете вернуться к согласованному состоянию, воспроизведя журналы (того, что он намеревался делать).
Это не означает, что вы не потеряете данные, это просто означает, что они точны.
Что вы, вероятно, захотите в этой ситуации (при условии, что вы не потеряете тысячи долларов, если вернетесь на 10 минут или что-то еще), так это АСИНХРОННАЯ репликация (вы не хотите ждать, пока запись в базу данных будет подтверждена удаленным хранилищем. ). В большинстве распространенных систем хранения вы можете просто сказать «снимок каждые X минут», и все будет готово.
Наконец, это не 100% - вам все равно нужно делать традиционные резервные копии. Но это довольно надежно. Эта настройка очень распространена и хорошо работает с виртуальными машинами, а также с базами данных.
Ознакомьтесь с журналами намерений, воспроизведением, доставкой журналов, контрольными точками максимального уровня и согласованности для получения дополнительной информации.
Это определенно выполнимо, я не знаю бесплатного способа сделать это, но мы используем ЭТОТ, он в основном позволяет блоку MSSQL стабилизировать свои файлы, а затем сообщает массиву 3Par сделать снимок, который по своей сути согласован, а затем продолжает работу. Затем массив берет привязку и позволяет вам иметь столько, сколько вы хотите - на самом деле вам нужно сказать всего 24 часа или около того, поэтому вы просто сбрасываете их на этом основании. Как я уже сказал, далеко не бесплатно, но работает на 100% каждый раз и специально разработан для этого. Я почти уверен, что NetApp сделает что-то похожее / идентичное - извините, я просто не знаю этого продукта.
Да, есть вероятность коррупции. Краткая версия: после сбоя SQL воспроизводит журналы транзакций, чтобы проверить целостность ваших данных. Если файлы журнала повреждены, ваши базы данных будут помечены как подозрительные. (Есть еще кое-что Вот.)
Что касается репликации: похоже, что доставка журналов - ваш лучший выбор. Если вы можете потерять 30 минут, вы, вероятно, могли бы (в зависимости от размера баз данных и их загруженности) отправлять 1/3 из них каждые 10 минут для вашего тридцатиминутного окна. (Другими словами, в случае сбоя 1/3 баз данных будет старше 10 минут, другая треть - 20, а еще одна треть - 30 минут.)
Я работал над похожим приложением. Не мультитенантное приложение, которое мы притворялись мультитенантным, поэтому одна БД на одного клиента. Отстой.
Вы можете попробовать разделить базы данных на несколько SQL-серверов, чтобы у вас не закончились рабочие потоки или не возникло одно из других узких мест при зеркалировании / репликации / доставке журналов.
Я посмотрел на AlwaysOn в SQL 2012, и похоже, что он удовлетворяет тем же требованиям, что и зеркалирование рабочих потоков 2008 года, поэтому обновление вам не поможет.
Вы можете попробовать репликацию на уровне хранения, о чем спрашиваете. У меня нет большого опыта работы с ними.