Выравнивание нагрузки SQL Server 2008 года

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

4
задан 3 July 2009 в 13:22
5 ответов

Кластеризация является высокодоступным решением, не решением для масштабируемости. Так называемым 'Активным/активным' является действительно повторное использование резервных узлов для развертывания другого, абсолютно отдельного, экземпляр.

Для запросов Transact-SQL чтения-записи ни в какой форме нет никакого выравнивания нагрузки. Для Transact-SQL только для рада (сообщающего) существует опция 'Масштабируемой Общей Базы данных'.

Единственная технология, которые поддерживают выравнивание нагрузки 'out-of-the-box' в SQL 2005 и SQL 2008, является Сервисным Брокером через развертывание маршрутов выравнивания нагрузки. Но я сомневаюсь, что это представляет любой интерес для Вас.

3
ответ дан 3 December 2019 в 02:24

Что Ваше в основном описание называют Кластеризацией SQL Server. Это относится к группе из двух или больше серверов (узлы), которые действуют вместе и замечены единственный виртуальный сервер клиентам.

Кластеры SQL Server могут быть настроены как Активные/Активные или Активные/Пассивные в двух Серверных сценариях. Или оба узла Кластера Microsoft SQL Server выделены выполнению, по крайней мере, единственного (Активно-активного) экземпляра SQL или по крайней мере один из этих узлов, резервируется как резервное устройство для принятия обработки отказа неудавшегося (Активно-пассивного) экземпляра SQL Server.

Вот некоторые статьи, которые Вы могли прочитать:

Некоторая статья, описывающая другие опции (на прикладном уровне, хотя):

6
ответ дан 3 December 2019 в 02:24
  • 1
    Таким образом, мое понимание корректно - Активный/Активный, означает две абсолютно отличных базы данных? There' s никакой путь к балансу загрузки два экземпляра к чтению-записи та же база данных? –  Duncan 3 July 2009 в 13:35
  • 2
    Хорошо там другая опция, если у Вас есть дисковый массив. –  splattne 3 July 2009 в 13:41
  • 3
    У нас действительно есть дисковый массив, как это влияет на вышеупомянутое? –  Duncan 3 July 2009 в 13:42
  • 4
    Проблема, что все решение, прежде всего, фокусируется на высокой доступности. Нет никакого реального " из box" решение для выравнивания нагрузки. –  splattne 3 July 2009 в 14:27
  • 5
    Duncan, Вы корректны. Два экземпляра не могут читать и записать в тот же файл данных одновременно. –  GilaMonster 6 July 2009 в 11:09

Вы могли бы хотеть читать о MySpace и как они обработали высокие загрузки с SQL Server. Это - серия приемов, но нет никакого выравнивания нагрузки.

http://highscalability.com/myspace-architecture

2
ответ дан 3 December 2019 в 02:24

Просто добавление большего количества узлов к Кластеру SQL не добавляет мощность переработки, оно просто увеличивает доступность, поскольку у Вас есть больше узлов, чтобы остаться онлайн. Обработка запросов чтения-записи ограничена одним узлом, нет никакого понятия циклического выравнивания нагрузки.

Вот является техническое описание от названной Производительности и Масштаба SQL Server Microsoft 2008 года http://www.microsoft.com/sqlserver/2008/en/us/wp-sql-2008-performance-scale.aspx

Это техническое описание обсуждает различия между Увеличением масштаба и Масштабированием Из SQL Server. Как указано Remus существует понятие Масштабируемой Общей Базы данных для баз данных только для чтения (думайте большие хранилища данных).

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

3
ответ дан 3 December 2019 в 02:24

Во-первых: SQL Server не поддерживает балансировку нагрузки для бокса, поэтому пусть операционная система Windows сделает всю работу. Вы можете установить 2 экземпляра SQL Server и настроить «одноранговую репликацию», чтобы у вас были согласованные данные на обоих серверах. Вы действительно тогда работаете с 2 (!) Разными базами данных. Но тогда могут возникнуть конфликты во время операторов DML для одной и той же записи от двух пользователей (один случайно находится на сервере 1, а другой - на сервере 2 ..). Ваша задача - избежать подобных конфликтов с помощью вашего планирования и внешнего программирования. К сожалению, SQL-сервер не может взять на себя эту задачу. С другой стороны, «отказоустойчивый кластер» возможен, когда для всех участвующих узлов используется ОБЩИЙ ХРАНИЛИЩ. Таким образом, система работает с ОДНОЙ отдельной базой данных без балансировки нагрузки (!), А только для переключения при отказе. Подумайте, что это не то же самое! Если один узел выходит из строя, другой немедленно берет на себя его задачи. Пока я надеюсь, что это может вам помочь. Томас

1
ответ дан 3 December 2019 в 02:24

Теги

Похожие вопросы