Exercício – Alta disponibilidade comercialmente crítica

10 minutos

Neste exercício, você atualizará seu banco de dados para a camada Comercialmente Crítica. Você verá como ela fornece réplicas de leitura e melhor desempenho.

Você usará a ferramenta ostress usada no exercício anterior para criar uma carga de trabalho. Em seguida, você iniciará um failover usando o módulo Azure PowerShell no Azure Cloud Shell. Por fim, verá o efeito que o failover tem sobre a carga de trabalho ostress.

Alta disponibilidade básica na camada de serviço Comercialmente Crítica do Azure SQL

Neste exercício, você vai concluir as seguintes etapas:

Implante o banco de dados do exercício anterior na camada Comercialmente Crítica.
Executar a carga de trabalho do ostress.
Use o PowerShell para iniciar um failover.
Veja os resultados no ostress.
Conectar-se a uma réplica secundária para leitura.

Implante o mesmo banco de dados na camada Comercialmente Crítica

Em um módulo anterior, você aprendeu a dimensionar um banco de dados usando o T-SQL. A meta deste exercício é atualizar o banco de dados que você usou no exercício anterior de Uso Geral para Comercialmente Crítico. Você usará o Azure Cloud Shell para atualizar o banco de dados. Como há um limite na frequência de failovers, você usará o mesmo banco de dados de exemplo, mas dará a ele o nome de AdventureWorks-BC.

No terminal do Azure Cloud Shell no lado direito desta página, execute o seguinte script do PowerShell para configurar seu ambiente:

$resourceGroup = "<rgn>Sandbox resource group name</rgn>"
$database = "AdventureWorks-bc"
$server = Get-AzureRmSqlServer -ResourceGroupName $resourceGroup
$server = $server.ServerName

# Specify your default resource group and Azure SQL Database logical server
az configure --defaults group=$resourceGroup sql-server=$server

# Confirm the defaults are set
az configure --list-defaults

Execute este comando para criar um banco de dados na camada de serviço Comercialmente Crítica:
```
az sql db create --name $database `
--edition BusinessCritical `
--family Gen5 `
--capacity 2 `
--sample-name AdventureWorksLT `
--read-scale Enabled `
--zone-redundant false
```
Esse comando leva algum tempo para ser concluído. Enquanto ele está em execução, você pode examinar alguns dos parâmetros usados:
- family: Esse parâmetro especifica a geração do hardware. Para consistência com o exercício anterior, usamos Gen5.
- capacity: Esse parâmetro especifica o número de DTUs ou vCores. Para consistência com o exercício anterior, usamos vCores 2.
- sample-name: Para consistência com o exercício anterior, usamos o exemplo de banco de dados AdventureWorksLT.
- edition: Esse nome de parâmetro é um pouco enganoso. Na verdade, ele se refere à camada de serviço, que não é igual à edição usada no SQL Server.
- read-scale: Essa opção não está habilitada por padrão, mas não há nenhum custo adicional associado a ela. Ao habilitá-lo, você está habilitando uma de suas réplicas secundárias a ser usada como uma réplica secundária para leitura.
- zone-redundant: Por padrão, esse parâmetro é definido como false. Você poderá defini-lo como true se quiser uma implantação "Multi-AZ" sem custo adicional. Você aprenderá mais sobre as Zonas de Disponibilidade na próxima unidade.
  
  Observação
  
  Zonas de Disponibilidade estão disponíveis somente em determinadas regiões. No momento, não estão disponíveis no Instância Gerenciada de SQL do Azure.
Depois que o banco de dados for criado, você deverá ver informações detalhadas sobre as atualizações na saída do Azure Cloud Shell. Você verá duas categorias principais (embora também veja indicadores em várias outras propriedades):
- currentServiceObjectiveName: Deve ser BC_Gen5_2. BC significa Comercialmente Crítico.
- currentSku:
  - name: Deve ser BC_Gen5.
  - tier: Deve ser BusinessCritical.
Outra maneira de verificar a camada de serviço é acessar o banco de dados no portal do Azure. Na guia Visão geral, confira tipo de preço.

Dica

Há muitas outras maneiras de ver essas atualizações. Uma delas maneira é usar o SSMS. Se você clicar com o botão direito do mouse no banco de dados e selecionar Propriedades>Configurar o SLO, poderá ver as alterações.

Executar a carga de trabalho do ostress

Como no exercício anterior, você usará o ostress para consultar repetidamente seu banco de dados SQL do Azure.

Se você fechou o Prompt de Comando usado no exercício anterior, abra uma nova janela do Prompt de Comando no computador local. Use cd para acessar o diretório no repositório clonado ou baixado anteriormente que contém o módulo de disponibilidade. Por exemplo, você pode usar este comando:
```
cd C:\Users\username\mslearn-azure-sql-fundamentals\05-Availability
```
A carga de trabalho ostress executa e se conecta a uma consulta simples 50 mil vezes.
Use o script ostress a seguir para executar a carga de trabalho. Substitua serverName pelo nome do servidor lógico do Banco de Dados SQL do Azure. Substitua password pela sua senha. Esse comando é levemente diferente daquele do exercício anterior. O nome do banco de dados agora é AdventureWorks-bc.
```
.\ostress.exe -S"serverName.database.windows.net" -Q"SELECT COUNT(*) FROM SalesLT.Customer" -U"cloudadmin" -d"AdventureWorks-bc" -P"password" -n1 -r50000
```
Se a carga de trabalho estiver sendo executada corretamente, você verá o resultado da consulta 847 aparecendo repetidamente na janela Prompt de Comando.

Se você quiser interromper a execução da carga de trabalho ostress antes que ela seja concluída, selecione Ctrl+C no terminal.

Se você quiser executar a carga de trabalho novamente, poderá executar o comando outra vez.

Iniciar um failover e exibir os resultados

Configure suas janelas para que você possa ver esse navegador e a janela Prompt de Comando ao mesmo tempo.

Execute o código a seguir no terminal do Azure Cloud Shell. Esse comando é o mesmo usado no exercício anterior.

# create a failover
Invoke-AzSqlDatabaseFailover -ResourceGroupName $resourceGroup `
    -ServerName $server `
    -DatabaseName $database

Enquanto esse comando estiver em execução, você deverá observar as alterações que aparecem no terminal. Você observará que não é possível acessar o banco de dados enquanto o failover ocorre. Esse tempo é muito curto. Depois de se desconectar, você deverá ser reconectado após cerca de 5 segundos. Esse failover é mais de seis vezes mais rápido do que aquele na camada de Uso Geral.

Lembre-se de que os bancos de dados ou as instâncias gerenciadas na camada de serviço Comercialmente Crítico têm essencialmente um grupo de disponibilidade Always On implantado nos bastidores, portanto, quando você faz failover, tudo o que acontece é uma alteração nos ponteiros no back-end, à medida que o Azure redireciona você para uma das instâncias secundárias. Por isso, o failover é muito mais rápido do que seria em Uso Geral.

Conectar-se à réplica somente leitura

Como você habilitou o parâmetro read-scale, pode usar uma das réplicas secundárias para cargas de trabalho somente leitura. Para acessar a réplica somente leitura em aplicativos, basta adicionar este parâmetro à sua cadeia de conexão para um banco de dados:

ApplicationIntent=ReadOnly;

No SSMS, crie uma conexão de consulta (selecione Arquivo>Novo>Consulta do Mecanismo de Banco de Dados).
Na caixa de diálogo Conectar-se ao Servidor, use a configuração usada para se conectar ao servidor lógico do Banco de Dados SQL do Azure (ou seja, use Autenticação do SQL Server). Selecione Opções.
Selecione Propriedades de Conexão e depois Redefinir Tudo. Em Conectar-se ao banco de dados, selecione Procurar servidor e selecione seu banco de dados AdventureWorks-bc. Selecione OK.
Selecione a guia Parâmetros de Conexão Adicionais e cole o conteúdo a seguir na caixa de texto. Selecione Conectar.
```
ApplicationIntent=ReadOnly;
```
Com o SSMS, você precisa especificar o servidor e o banco de dados aos quais deseja se conectar de modo somente leitura. Isso porque pode haver vários bancos de dados em um servidor que têm recursos diferentes para secundários legíveis.
Como um teste, experimente a consulta a seguir em sua nova consulta do mecanismo de banco de dados. Observe os resultados. Eles são os esperados?
```
SELECT DATABASEPROPERTYEX(DB_NAME(), 'Updateability')
```
Outra opção é reconectar e atualizar os Parâmetros de Conexão Adicionais (substitua ReadOnly por ReadWrite). Confirme que você está acessando a réplica primária de leitura/gravação. ReadWrite é o padrão, portanto, se você não selecionar nada, obterá isto:

Continuar