Подключение к SQL AG с использованием маршрутизации ReadOnly из Azure Analysis Services - PullRequest
0 голосов
/ 29 марта 2019

Мы используем табличную модель Azure Analysis Services. Он подключен через шлюз к группе доступности SQL Server On Prem.

Недавно мы добавили маршрутизацию только для чтения в группу доступности и создали веб-приложение со строкой подключения, которая добавляет «ApplicationIntent = ReadOnly» для наших запросов на чтение.

Мы можем проверить, что запросы попадают на узел только для чтения из веб-приложения, но не повезло с обновлением нашей табличной модели AAS. Запросы продолжают обновляться с узла ReadWrite, а не с ReadOnly (проверено с помощью sp_whoisactive на БД).

Это наше соединение xmla (с переименованной конфиденциальной информацией)

"dataSources": [
  {
    "type": "structured",
    "name": "someconnectionname",
    "connectionDetails": {
      "protocol": "tds",
      "address": {
        "server": "servername,portnum",
        "database": "mydbname", 
    "applicationIntent": "ReadOnly"
      },
      "authentication": null,
      "query": null
    },
    "options": {
      "commandTimeout": "P5D"
    },
    "credential": {
      "AuthenticationKind": "UsernamePassword",
      "kind": "SQL",
      "path": "servername,portnum;mydbname",
      "Username": "myUserName",
      "EncryptConnection": false,
      "PrivacySetting": "Private"
    }
  }

Я пытался редактировать приложение Intent: только для чтения на

"Назначение приложения": "ReadOnly"

"ApplicationIntent": "ReadOnly"

"applicationIntent": "ReadOnly"

"applicationIntent": "Только для чтения"

А затем попытался переместить намерение приложения чуть ниже «connectionDetails» и попробовал ту же самую дисперсию.

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

(запрос завершается с ошибкой , если я помещаю намерение в "опции")

Пожалуйста, дайте мне знать, если у вас есть ответ. Спасибо!

1 Ответ

1 голос
/ 29 марта 2019

И затем мы добавили multiSubnetFailover = true в json следующим образом.Интересно то, что на самом деле у нас не установлен MultiSubnetFailover на AG, но это заставляет работать тип структурированного соединения.

См. Руководство по Github

"dataSources": [
{
"type": "structured",
"name": "someconnectionname",
"connectionDetails": {
  "protocol": "tds",
  "address": {
    "server": "servername,portnum",
    "database": "mydbname", 
    "applicationIntent": "ReadOnly"
  },
  "authentication": null,
  "query": null
},
"options": {
  "commandTimeout": "P5D",
  "multiSubnetFailover": "true"
},
"credential": {
  "AuthenticationKind": "UsernamePassword",
  "kind": "SQL",
  "path": "servername,portnum;mydbname",
  "Username": "myUserName",
  "EncryptConnection": false,
  "PrivacySetting": "Private"
}

}

...