Зеркалирование против репликации

Как решить, следует ли выбирать репликацию или зеркалирование в SQL Server 2005 для обеспечения доступности и производительности данных одновременно.

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

Ответ 1

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

Ответ 2

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

Различные механизмы в SQL Server обеспечить резервирование на уровне базы данных, таких как резервное копирование/восстановление, отправка журналов, и зеркалирование базы данных (в SQL Server 2005 и позднее). Зеркалирование базы данных единственный механизм, обеспечивающий в реальном времени, точная копия защищенного база данных с гарантией нуля потери данных (когда зеркало синхронизированы).

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

Эта техническая документация MS, Обеспечение высокой доступности с использованием зеркалирования базы данных, охватывает ряд сценариев.

Вероятно, вам следует прочитать эту статью TechNet, Рекомендации по оптимальному использованию зеркал баз данных и производительности.

Ответ 3

Я не знаю SQL Server 2005, но для общего использования SQL я всегда предпочитаю репликацию. Вы должны отделять чтение/запись в своем приложении (для MySQL есть MySQL Proxy, который может сделать это прокси-сервером для вас), но получить масштабируемую систему. (считывает ведомый (-ы), записывает мастеру)

Зеркалирование означает репликацию master-master, которая приводит к проблемам concurrency/транзакции. Даже в сценариях master-master вы НИКОГДА не должны отправлять запросы на запись на разные серверы. В зависимости от размера вашего проекта, следующие шаги будут добавлением большего количества подчиненных устройств, а затем добавьте еще один мастер + его ведомые устройства для резервирования.

master --- master
  |          |
slave       slave
  |          |
slave       slave
  |          |
slave       slave

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