Можно ли получить задержку менее 1 секунды при репликации транзакций?

Question

Наша архитектура базы данных состоит из двух серверов Sql Server 2005, каждый из которых имеет экземпляр одинаковой структуры базы данных: один для всех операций чтения и один для всех операций записи. Мы используем репликацию транзакций, чтобы поддерживать актуальность прочитанной базы данных.

Два сервера действительно имеют очень высокую производительность (сервер записи имеет 32 ГБ ОЗУ) и подключены через оптоволоконную сеть.

Принимая решение об этой архитектуре, мы полагали, что задержка репликации данных на сервер чтения будет составлять несколько миллисекунд (очевидно, в зависимости от нагрузки). На практике мы наблюдаем задержку около 2-5 секунд даже в самых простых случаях, что неудовлетворительно. В простейшем случае я имею в виду обновление одного значения в одной строке в одной таблице в базе данных записи и просмотр времени, необходимого для наблюдения нового значения в базе данных чтения.

Какие факторы мы должны учитывать, чтобы достичь задержки ниже 1 секунды? Это вообще достижимо?

В качестве альтернативы, мы должны рассмотреть другой способ репликации? Как лучше всего размещать данные и файлы журналов?

Редактировать

Спасибо всем за совет и понимание - я считаю, что латентные периоды, которые мы переживаем , являются нормальными; наша компания по хостингу баз данных ошибочно повела нас к ожиданиям!

Мы используем метод, описанный в нижней части этой статьи MSDN (под заголовком "масштабирование баз данных"), и мы не смогли правильно обработать это предупреждение:

Следствием создания таких специализированных баз данных является задержка: для записи теперь потребуется время для распространения в базах данных считывателя. Но если вы справитесь с задержкой, потенциал масштабирования огромен.

Сейчас мы смотрим на реализацию изменения в нашем механизме кэширования, который обеспечивает чтение из базы данных записи, когда элемент данных считается «изменчивым».

Answer 1

Нет. Маловероятно, что вы могли бы достичь времени ожидания менее 1 с репликацией транзакций SQL Server даже с быстрым оборудованием.

Если вы можете получить задержку в 1 - 5 секунд, значит, у вас все хорошо.

С здесь :

Используя репликацию транзакций, это Абонент может быть несколько секунд позади издателя. С задержка всего несколько секунд, Абонент может легко использоваться как сервер отчетов, разгрузка дорогая пользовательские запросы и отчеты от Издатель подписчику.

В следующем сценарии (используя Таблица клиентов, показанная позже в этом раздел) Подписчика было всего четыре секунд позади издателя. Четное более впечатляющим, 60 процентов время задержки составляло две секунды или менее. Время измеряется от когда запись была вставлена ​​или обновляется в издателе, пока не будет на самом деле написано для подписки базы данных.

Answer 2

Что нужно помнить о репликации транзакций, так это то, что для одного изменения требуется несколько операций, чтобы это изменение произошло.

Сначала вы обновляете исходную таблицу. Затем читатели журнала видят изменения и записывают изменения в базу данных распространителя. Затем агент распространителя видит новую запись в базе данных распространителя и считывает это изменение, а затем запускает на подписчике правильную хранимую процедуру для обновления строки.

Если вы будете следить за временем выполнения операторов на двух серверах, вы, вероятно, увидите, что они выполняются всего за несколько миллисекунд. Однако это время ожидания ожидания чтения и агента распространения журналов, чтобы понять, что им нужно сделать что-то, что может вас убить.

Если вам действительно нужно время обработки менее секунды, то вам стоит заняться написанием собственного обработчика для обработки данных, перемещающихся с одного сервера на другой. Я бы порекомендовал использовать SQL Service Broker, чтобы справиться с этим, поскольку таким образом все является родным для SQL Server, и никакой сторонний код не должен быть написан.

Answer 3

Я бы сказал, что это определенно возможно.

Я бы посмотрел на:

• Ваша сеть
  Запустите команды ping между двумя серверами и посмотрите, есть ли какие-либо проблемы
  Если серверы находятся рядом друг с другом, у вас должно быть <1 мс. </li>
• Узкие места на сервере
  Это может быть сетевой трафик (объем)
  Как сетевые карты не настроены на 1 ГБ / с
  Антивирус или другие вещи
• Проведите некоторый анализ некоторых запросов и посмотрите, сможете ли вы определить индексы или блокировки, которые могут быть проблемой
• Проверьте, может ли какой-либо выбор из базы данных для чтения блокировать записи.
  Добавьте с помощью (nolock) и посмотрите, будет ли это иметь значение для одного или двух анализируемых запросов.

По сути, у вас сложная система, с которой у вас проблема, вам нужно определить, какой компонент является проблемой, и устранить ее.

Репликация транзакций, вероятно, лучше всего подходит, если отчеты / выборки, которые вам нужно запустить, должны быть обновлены. Если этого не произойдет, вы можете посмотреть на доставку журналов, хотя это добавит время простоя при каждом импорте.

Для файлов данных / журналов убедитесь, что они находятся на отдельных дисках, чтобы производительность была максимальной.