Как решить, следует ли выбирать репликацию или зеркалирование в SQL Server 2005 для обеспечения доступности и производительности данных одновременно.
Чтобы быть более конкретным в моей архитектуре SQL-сервера, у меня есть активный/активный кластер из двух узлов, которые используются для балансировки нагрузки, и у меня есть другой сервер для репликации, который будет использоваться только для отчетов, я хочу сделать что лучшая технология обеспечивает как доступность, так и производительность, репликацию транзакций или зеркальное отображение базы данных?
Оказывается, что зеркальное отображение базы данных не позволяет получить доступ к данным напрямую, зеркальные данные доступны только через моментальный снимок базы данных, поэтому отчеты из данных моментальных снимков не будут обновлены, поэтому я буду использовать репликацию транзакций базы данных, чтобы обеспечить высокую доступность и балансировка нагрузки.
Это зависит от уровня (горячего, теплого, холодного) доступности в режиме ожидания, которое вам требуется.
Различные механизмы в SQL Server обеспечить резервирование на уровне базы данных, таких как резервное копирование/восстановление, отправка журналов, и зеркалирование базы данных (в SQL Server 2005 и позднее). Зеркалирование базы данных единственный механизм, обеспечивающий в реальном времени, точная копия защищенного база данных с гарантией нуля потери данных (когда зеркало синхронизированы).
Зеркалирование базы данных работает либо в синхронном, либо в асинхронном режиме. При асинхронной операции транзакции фиксируются, не дожидаясь, пока зеркальный сервер будет записывать журнал на диск, что максимизирует производительность.
Эта техническая документация MS, Обеспечение высокой доступности с использованием зеркалирования базы данных, охватывает ряд сценариев.
Вероятно, вам следует прочитать эту статью TechNet, Рекомендации по оптимальному использованию зеркал баз данных и производительности.
Я не знаю SQL Server 2005, но для общего использования SQL я всегда предпочитаю репликацию. Вы должны отделять чтение/запись в своем приложении (для MySQL есть MySQL Proxy, который может сделать это прокси-сервером для вас), но получить масштабируемую систему. (считывает ведомый (-ы), записывает мастеру)
Зеркалирование означает репликацию master-master, которая приводит к проблемам concurrency/транзакции. Даже в сценариях master-master вы НИКОГДА не должны отправлять запросы на запись на разные серверы. В зависимости от размера вашего проекта, следующие шаги будут добавлением большего количества подчиненных устройств, а затем добавьте еще один мастер + его ведомые устройства для резервирования.
master --- master
| |
slave slave
| |
slave slave
| |
slave slave
Даже тогда вы только отправляете запросы на запись одному хозяину, но в случае неудачного мастера вы можете автоматически продвигать второго мастера к вашей новой цели запроса на запись.