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