Альтернатива репликации SQL?

Question

Эй, у меня есть большая база данных в SQL Server 2005, и, поскольку она настолько велика, мне нужно скопировать ее на другой сервер. Я настроил издателя и подписчика репликации sql, но он не работает стабильно. Он не реплицируется для каждой вставки и не вызывает никаких исключений. Кроме того, я беспокоюсь о производительности здесь, поэтому мне было интересно, если, возможно, есть какая-то другая альтернатива, которую я мог бы использовать ... Мне не нужно дублировать каждую строку в базе данных или все таблицы.

Любой комментарий будет оценен здесь!

Спасибо!

UPDATE: Здесь я пытаюсь достичь баланса нагрузки для базы данных. Я ожидаю много трафика здесь, поэтому я думаю использовать реплицированную базу данных для показа информации пользователям. Значение, вставки, обновления и удаления будут выполняться в основной базе данных, а выбор будет выполняться в новой базе данных. Поскольку реплицированная база данных предназначена только для выбора и показывает информацию пользователям, мне просто нужны те строки, которые активны для приложения. Кроме того, я думаю о том, чтобы здесь не было нормализованных таблиц, чтобы избежать использования объединений и получения информации так быстро, как я могу. Репликация, которую я настроил, является транзакционной, и на самом деле проблемы, которые у меня возникают, заключаются в том, что, следуя тому же процессу, чтобы вставить строку, он один раз повторяет результат, а затем пытается снова, и это не так. И с тех пор так и работает.

Answer 1

Звучит так, как будто вы хотите использовать Транзакционная репликация :

Приложению требуется небольшая задержка между изменениями времени, внесенными на издателе, и изменениями, поступающими на подписчика.

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

---

Из ваших изменений видно, что вы уже пробовали репликацию транзакций и столкнулись с проблемами. Обычно я рекомендую вам настроить репликацию aКоличество раз, и просто получить общее представление о том, как это работает, прежде чем пытаться сделать это с реальной базой данных. Начните с пары таблиц и нескольких строк данных. Настройте репликацию (обе базы данных могут находиться на одном сервере).Поэкспериментируйте с различными опциями. Если репликация перестает работать (как вы указали), вам нужно искать события и регистрировать сообщения, которые указывают, что пошло не так / перестало работать.

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

Answer 2

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

в этом случае я реализовал собственную логику создания таблицы репликации с идентификаторами серверов и журналами sql.

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

это решает мою проблему, однако ему все еще требуется дополнительная оптимизация, например сжатие данных во время путешествия для увеличения скорости репликации, поскольку у меня есть почти 100000 записей в неделю в каждой базе данных, и у меня есть 4 местоположения.

Answer 3

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