Зеркальное отображение в реальном времени между двумя базами данных сервера SQL
Я программист aC#, а не администратор баз данных, и мне посчастливилось (не очень) удачно передать задачу администратора базы данных. Поэтому, пожалуйста, имейте это в виду, отвечая на этот вопрос.
Меня попросили создать двустороннее зеркало в реальном времени между двумя базами данных с 10-мегабитным соединением между ними. Поэтому, когда одно из них меняется, оно обновляет другое. Это не стандартная задача зеркалирования / восстановления после сбоя данных, когда одна БД является главной, а другая - резервной копией - обе являются оперативными, и каждая из них должна мгновенно отражать изменения, внесенные в другую.
В моей голове это звучит как высокий заказ, который может быть даже невозможен - в конце концов, в быстро меняющейся среде с большим количеством пользователей это будет требовать значительных ресурсов и создавать повсеместные блокировки и очереди заданий.
Является ли это возможным? Если да, может ли кто-нибудь дать мне некоторые базовые инструкции и / или указать мне в каких-то местах, чтобы начать чтение и исследования?
Ура, Мэтт
3 ответа
Вы бы смотрели на некоторую форму репликации - слияние или транзакцию. Существует множество руководств по выбору того, какой тип лучше всего подходит для вашей среды.
Конечно, то, что бизнес имеет тенденцию требовать, имеет тенденцию быть невозможным, если воспринимать его буквально - например, они всегда хотят на 100% постоянно, без задержек, без штрафов за любые типы запросов. Вам придется управлять некоторыми ожиданиями. Это никогда не будет бесплатным.
Репликация также, как правило, требует изменения схемы (например, добавление столбцов rowguidcol в транзакционно публикуемые таблицы). Если вы пойдете по пути репликации, я бы порекомендовал вам сначала попробовать настроить его на несколько небольших тренировочных баз данных, чтобы понять, как он работает, и проблемы, с которыми вы можете столкнуться на этом пути.
Похоже, вы после слияния репликации. Это не просто, требует, чтобы ваши приложения знали, как это работает.
Репликация слиянием обычно приводит к головным болям и большому количеству поздних ночей, несвоевременным срокам и простоям, если у вас нет опытных сотрудников DBA для обеспечения правильной настройки. И даже тогда - мои клиенты сообщают об ошибках, которые "не могут произойти" из-за слегка неправильно настроенных сред.
Я настоятельно рекомендую взглянуть на базовые требования, а не слепо следовать по пути репликации слиянием.
По своему опыту я обнаружил, что в большинстве случаев мне обычно удавалось избежать доставки журналов и / или зеркалирования SQL.
Чтобы достичь этой цели, вам необходимо протестировать репликацию, но не какую-либо форму: Транзакционная одноранговая репликация (одноранговая версия была введена в версиях SQL 2005). Я не говорю, что это без проблем, и это будет легко... Вам нужен кто-то, кто знает DBA, иначе вы будете нести ответственность за то, что вы не очень хорошо знаете:)
Репликация слиянием может объединять модификации, сделанные на каждом участвующем сервере в репликации, но не в режиме реального времени. Каждый сервер будет автономным до разрешения конфликтов. У вас есть графики, когда происходит слияние. Это не в реальном времени.
Транзакционная одноранговая репликация обеспечивает решение с горизонтальным масштабированием и высокой доступностью, сохраняя копии данных на нескольких экземплярах сервера, также называемых узлами. Созданная на основе репликации транзакций, одноранговая репликация распространяет согласованные транзакции изменения практически в реальном времени. Это позволяет приложениям, которым требуется масштабирование операций чтения, распределять чтения от клиентов по нескольким узлам. Поскольку данные поддерживаются на узлах практически в режиме реального времени, одноранговая репликация обеспечивает избыточность данных, что повышает доступность данных.
подумайте, прежде чем читать ниже документацию и удачи. Это может быть весело:)
http://www.sql-server-performance.com/articles/dba/PeertoPeer_Replication_in_SQL_Server_2008_p2.aspx