Alta disponibilidade no SQL Server

Prévia do material em texto

www.devmedia.com.br
[versão para impressão]
Link original: http://www.devmedia.com.br/articles
/viewcomp.asp?comp=33296
Este artigo apresenta soluções de alta
disponibilidade para o SQL Server. Serão
discutidas estratégias para garantir a
continuidade dos negócios de sua empresa.
Fique por dentro
A necessidade de continuidade das atividades de negócio leva
empresas de tecnologia a criarem sistemas de alta disponibilidade. O
SQL Server apresenta várias tecnologias deste tipo, considerando
questões como tempo de recuperação, capacidade de manter as
informações íntegras, dentre outras.
Neste artigo apresentaremos uma visão geral de cada uma delas, suas
características e sugestões de uso. Conhecer as soluções de alta
disponibilidade do SQL Server permite que definamos estratégias que
R
e
c
e
b
a
 n
o
ti
fic
a
ç
õ
e
s 
:)
Alta disponibilidade no SQL Server http://www.devmedia.com.br/articles/viewcomp_forprint.asp?comp=33296
1 de 18 07/02/2017 13:32
estejam melhor alinhadas às restrições impostas pelo cenário que
estamos tratando.
Um sistema de alta disponibilidade é aquele que permanece disponível a
maior parte do tempo, minimizando ao máximo riscos de parada do
sistema. Como muitos sistemas de informação têm como elemento
central bancos de dados relacionais, a continuidade dos negócios
depende da disponibilidade destes bancos.
Um sistema de gerenciamento de banco de dados depende de vários
componentes de hardware e software para rodar e a alta disponibilidade
é conseguida com redundâncias que tentam eliminar pontos únicos de
falha (Single Point Of Failure - SPOF) de cada componente do sistema
O SQL Server fornece boas alternativas de alta disponibilidade que
trabalham em conjunto com outras tecnologias de software e hardware
que também eliminam pontos únicos de falha, aumentando assim a
confiabilidade do sistema como um todo.
Assim, a camada de hardware da solução de alta disponibilidade deve ser
levada em consideração pensando-se em dispositivos tolerantes a falha.
Para servidores físicos, os pontos de atenção são a fonte de alimentação,
o armazenamento e a rede.
Esta lista foca nos principais componentes que podem ter redundância, o
que garante que o hardware onde rodam sistema operacional e softwares
que fornecem serviços aos usuários não fique vulnerável a falhas. Vale
notar também que estas opções de hardware são independentes de
software e podem atender a várias plataformas como Windows, Linux e
Unix, e SGBDs como SQL Server e Oracle.
Apesar da virtualização ser uma realidade hoje em dia, não iremos entrar
nesse detalhe pois algumas características de proteção de máquinas
virtuais não se aplicam a servidores de banco de dados, pois não
contemplam o conceito de transação, conceito este que é essencial para
R
e
c
e
b
a
 n
o
ti
fic
a
ç
õ
e
s 
:)
Alta disponibilidade no SQL Server http://www.devmedia.com.br/articles/viewcomp_forprint.asp?comp=33296
2 de 18 07/02/2017 13:32
o funcionamento e garantia de consistência dos mesmos.
Em se tratando de software, a versão 2012 do SQL Server apresenta as
opções de alta disponibilidade listadas a seguir:
· Al w ay sOn Fa i l ove r Cl u st e r I n st an ces: com base no Windows
System Failover Cluster (WSFC), fornece alta disponibilidade através de
redundância no nível da instância.
Na prática, são duas instâncias de mesmo nome rodando em servidores
diferentes que estão ligados ao mesmo storage. No entanto, a instância
permanece ativa em um único nó do cluster usando exclusivamente o
storage que atende a todos os servidores do cluster;
· Al w ay sOn Ava i l ab i l i t y g r ou p: permite que um ou mais bancos de
dados de uma instância tenham uma cópia da base em outro servidor de
SQL Server. O termo “réplica”, neste artigo, se referenciará a cópias de
um banco de dados principal que fica em modo read/write;
· Dat abase m i r r o r i n g : espelhamento de um banco de dados de um
servidor principal em outro servidor secundário, que pode permitir
failover manual ou instantâneo e automático. A base principal é chamada
de principal database, enquanto que a base redundante é chamada
mirrored database. Esta funcionalidade será removida em futuras versões
do SQL Server;
· Log Sh ipp in g : também opera no nível de banco de dados e pode
manter uma ou mais cópias de um banco de dados principal. As cópias
são chamadas de bases secundárias e são warm databases, ou seja,
podem ser usadas apenas para leitura. Um exemplo seria seu uso para
apoiar a geração de relatórios.
Veremos a partir de agora como cada uma dessas opções podem ser
utilizadas de forma que tenhamos uma infraestrutura de banco de dados
com alta disponibilidade.
Hardware
R
e
c
e
b
a
 n
o
ti
fic
a
ç
õ
e
s 
:)
Alta disponibilidade no SQL Server http://www.devmedia.com.br/articles/viewcomp_forprint.asp?comp=33296
3 de 18 07/02/2017 13:32
As opções para se eliminar pontos de falha de hardware são as
seguintes:
· Fon t e de a l i m en t ação : um servidor com mais de uma fonte de
alimentação permite que ele continue funcionando no caso de uma das
fontes falhar. Estas fontes também podem ser do tipo hot swap, ou seja,
trocadas com o servidor em operação;
· Ar m azen am en t o : a redundância de disco local de um servidor pode
ser obtida utilizando RAID (Redundant Array of I nexpensive Disks) ou
através de sistemas de armazenamento como NAS (NAS é a sigla de
Network At t ached Storage, que representa volumes de disco conectados
a um servidor que os disponibiliza a outros servidores) e SAN (Storage
Area Network). Inclui-se nesta categoria também o uso de placas de HBA
(Host Bus Adapter) redundantes. Os termos SAN e RAID serão explicados
mais adiante;
· Rede: múltiplas placas de rede trabalhando em t eaming, ou seja,
atuam em conjunto se comportando para o sistema como se fossem uma
placa de rede única.
A SAN é um conjunto de discos ligados em uma rede específica para este
fim. Nesta SAN, vários grupos de discos podem ser configurados com
redundância a falha como se fossem um único volume, e os servidores
são ligados a esta rede para que possam usar os conjuntos de discos da
SAN.
A tecnologia RAID permite que vários discos configurados em
redundância sejam apresentados para o servidor como uma única
unidade lógica. A seguir são apresentadas algumas das configurações
RAID mais usadas:
· RAI D0 – vários discos físicos combinados e apresentados como um
único volume ao servidor, onde os dados são divididos em pequenos
segmentos e distribuídos entre os mesmos. Esta configuração não
apresenta dispositivo de redundância e não deve ser usada como
R
e
c
e
b
a
 n
o
ti
fic
a
ç
õ
e
s 
:)
Alta disponibilidade no SQL Server http://www.devmedia.com.br/articles/viewcomp_forprint.asp?comp=33296
4 de 18 07/02/2017 13:32
alternativa de alta disponibilidade;
· RAI D1 – os discos são espelhados no storage, mas apresentados ao
servidor como se fossem um só. O espelhamento garante a
disponibilidade no caso de falha de um dos discos;
· RAI D5 - vários discos físicos combinados e apresentados como um
único volume ao servidor garantindo a disponibilidade através de
paridade.
Nesta configuração, o bit de paridade é utilizado para garantir a
redundância e caso um dos discos fique indisponível, o volume único
apresentado continua respondendo.
A desvantagem dessa configuração é o desempenho. Este nem sempre
atende às demandas de uso intenso de escrita devido ao overhead do
cálculo de paridade.
Além disso, apesar de funcionar sem um dos discos, isso causa lentidão
pois os dados do disco faltante são calculados atravésdos discos ainda
disponíveis. Para entender o uso de paridade, vamos usar um array de
três discos e um dado representado pelo binário 10.
Ao realizar uma operação de escrita no conjunto de discos, no disco 1 é
escrito um bit 0, no disco 2, um bit 1. No terceiro disco, utiliza-se para
calcular a paridade o resultado de operação binária XOR (ou exclusivo). O
resultado de 1 XOR 0 é 1.
Caso o disco 1 falhe, o dado do mesmo pode ser reconstruído ao se fazer
a operação inversa entre o bit do disco 2 e o bit do disco 3 de paridade.
Obviamente, o algoritmo utilizado pelos sistemas de storage é mais
complexo do que o do exemplo, mas com o exemplo pode-se ter uma
ideia do funcionamento da paridade.
Isto serve para mostrar também o porquê dessa configuração não ser
recomendada para bancos de escrita intensa, pois a cada escrita, a
paridade deve ser calculada aumentando o tempo para persistir os
R
e
c
e
b
a
 n
o
ti
fic
a
ç
õ
e
s 
:)
Alta disponibilidade no SQL Server http://www.devmedia.com.br/articles/viewcomp_forprint.asp?comp=33296
5 de 18 07/02/2017 13:32
dados.
No caso de falha de um disco, o tempo de leitura também fica
comprometido pois para extrair o bit do disco que falhou, deve ser feito o
cálculo inverso com os dados dos discos disponíveis;
· RAI D6 – funciona como o RAID5, porém utiliza dois bits de paridade,
permitindo assim a perda de dois discos e ainda assim mantendo o
conjunto de discos acessível;
· RAI D 1 0 ou 1 + 0 – discos espelhados dois a dois e depois
configurados em stripe (os dados são subdivididos em segmentos
consecutivos que são escritos sequencialmente através de cada um dos
discos), sendo apresentados como um único volume ao servidor;
· RAI D 0 1 0 u 0 + 1 – discos configurados em stripe e espelhados,
configurando assim um único volume que é apresentado ao servidor.
AlwaysOn Failover Cluster Instances (AOFCI)
Esta tecnologia fornece proteção contra falhas no nível de instância
(servidor), e não apenas em nível de banco de dados. O Windows Server
Failover Cluster (WSFC) utiliza dois ou mais servidores ligados a um
armazenamento em comum, os quais são chamados nodes ou nós.
Devido ao fato de todos os nós precisarem acessar os mesmos discos, é
utilizada uma SAN nesta configuração. Em ambos os nós, o Windows
fornece o serviço de cluster que controla, entre outros recursos, o uso do
storage comum entre os nós.
Além desse controle, o cluster também apresenta o serviço de nome
virtual e IP virtual, o que permite que o acesso ao cluster seja sempre
feito pelo nome e/ou IP virtual, ficando transparente para o usuário em
que nó o recurso está.
O software de cluster agrupa os itens necessários ao funcionamento da
instância em um grupo de recursos. Recursos são discos compartilhados,
R
e
c
e
b
a
 n
o
ti
fic
a
ç
õ
e
s 
:)
Alta disponibilidade no SQL Server http://www.devmedia.com.br/articles/viewcomp_forprint.asp?comp=33296
6 de 18 07/02/2017 13:32
nome virtual, IP virtual e os serviços do SQL Server. Este grupo de
recursos pode ser controlado por cada nó exclusivamente em um certo
momento.
Além dos recursos de disco, de serviço, de nome virtual e de IP virtual, o
cluster utiliza dois importantes componentes para seu funcionamento.
Um deles é a rede de comunicação entre os nós, chamada heartbeat, que
normalmente é dedicada a este fim.
Ela permite que os nós se monitorem para saber qual está ativo e, numa
eventual falha, qual deles pode assumir. O segundo componente é o
quórum, que é um disco dedicado do cluster utilizado para determinar o
número de falhas de nó que o cluster pode sustentar.
Em resumo, os nós do cluster usam o heartbeat para se comunicar e, em
uma eventual falha do nó ativo, as informações contidas no quórum são
utilizadas para decidir qual nó pode assumir os recursos do grupo.
O AlwaysOn Failover Instance Cluster é instalado e configurado em um
servidor que já está rodando o software de cluster do Windows, o
chamado Windows System Failover Cluster (WSFC). O software de
cluster controla a instância de qual nó fica ativa acessando os recursos e
disponibilizando serviços de SQL Server para os usuários.
Suponhamos que os servidores físicos SRV01 e SRV02 tenham
respectivamente os IPs 10.192.30.10 e 10.192.30.11 e ambos estão
ligados em um storage SAN. O cluster é configurado neste Windows e
são criados recursos de nome e IP virtual nestes servidores, que são
respectivamente SRV10 e 10.192.30.12. O cluster será acessado pelo
nome e/ou IP virtual, independentemente de qual servidor físico controla
os recursos de disco, nome e IP virtual.
Instalando o SQL Server também em cluster, será necessário definir um
grupo de recursos dedicado ao SQL Server.
Este grupo também terá nome virtual e IP virtual, que no nosso exemplo
são respectivamente SRVDB10 e 10.192.30.20. Supondo o nome de
R
e
c
e
b
a
 n
o
ti
fic
a
ç
õ
e
s 
:)
Alta disponibilidade no SQL Server http://www.devmedia.com.br/articles/viewcomp_forprint.asp?comp=33296
7 de 18 07/02/2017 13:32
instância SQLCL10, os acessos a esta instância deverão ser ao
SRVBD10\SQLCL10 independente da instância estar ativa no servidor
SRV01 ou SRV02.
O tempo de resposta de um cluster à falha do nó ativo é o tempo de
detecção da falha mais o tempo que os serviços demoram para subir no
novo nó ativo. Esta ação é chamada failover e é automática na
configuração do cluster. Pode-se também fazer a troca de papéis entre os
nós do cluster manualmente (move group). O termo “group” evidencia o
fato de que a mudança dos recursos é feita por grupos, ou seja, todos os
recursos (storage, nome virtual e IP virtual) do cluster são movidos em
conjunto.
Uma das grandes vantagens desta configuração é que o software de
cluster tem toda a inteligência para configurar e administrar o SQL
Server, sendo basicamente necessária a instalação inicial do SQL Server
em cluster para poder utilizar seus benefícios.
Nos itens seguintes do artigo será possível perceber que as outras
soluções exigem um certo grau de esforço por parte do DBA para
implementar com sucesso a alta disponibilidade.
Além disso, as outras soluções trabalham no nível do banco de dados e
não da instância, o que também pode aumentar a carga de trabalho do
DBA para configurar e utilizar as outras tecnologias de alta redundância.
Como a SAN tem redundância de hardware de disco, de elementos de
rede e outros dispositivos, ela elimina o ponto único de falha de disco e
como o cluster utiliza mais de um servidor, o ponto único de falha de
servidor também é eliminado.
Por outro lado, redes de armazenamento SAN são estruturas complexas
e, por isso, com alto custo de implantação, configuração e manutenção.
Assim, o ganho em disponibilidade tem como contrapartida o alto custo
de hardware e software se comparado às outras soluções.
R
e
c
e
b
a
 n
o
ti
fic
a
ç
õ
e
s 
:)
Alta disponibilidade no SQL Server http://www.devmedia.com.br/articles/viewcomp_forprint.asp?comp=33296
8 de 18 07/02/2017 13:32
Log Shipping
Log shipping é uma tecnologia de redundância que existe desde a versão
2005 do SQL Server. Ela opera no nível de banco de dados e pode ser
usada para manter uma ou mais bases standby (chamados secondary
database) de uma única base de produção, chamada primary database.
A construção do log shipping envolve, inicialmente, o backup de uma
base principal no servidor principal e posteriormente um restore deste
backup em servidor secundário. Esta fase pode ser feita no momento ou
antes da configuração do log shipping.
Fazer este backup antes permite um maior controle sobre esta fase, o
que é uma vantagem para basesgrandes pois para elas os tempos de
backup e restore em disco podem ser maiores do que o tempo disponível
para configurar o log shipping.
Além disso, por ser uma solução no nível de banco de dados, objetos
externos ao banco como logins e jobs envolvendo a base do log shipping,
por exemplo, não são levados para o servidor secundário
automaticamente, forçando o DBA a realizar estas transferências
manualmente antes de configurar o mesmo.
A transferência de logins é importante para não haver usuários de banco
sem logins associados. Os jobs, se contiverem DML, não podem ser
executados na base secundária enquanto ela está em modo read only,
porém uma vez que esta base se torna a base principal e fica em estado
online, os jobs podem ser executados.
Caso a fase de backup e restore seja feita antes de se iniciar a
configuração do log shipping, a base secundária deve ser restaurada com
a opção NORECOVERY. Cabe aqui uma distinção entre restore e recovery.
Ao se usar o comando RESTORE DATABASE sem definir informações de
recovery, na fase de restore os datafiles que estão em um backup são
lidos e copiados para disco.
R
e
c
e
b
a
 n
o
ti
fic
a
ç
õ
e
s 
:)
Alta disponibilidade no SQL Server http://www.devmedia.com.br/articles/viewcomp_forprint.asp?comp=33296
9 de 18 07/02/2017 13:32
Posteriormente a esta fase, é realizado o recovery, ou seja, rollback de
transações não comitadas e o roll forward de transações comitadas que
estão pendentes na mídia de backup.
Ao final do recovery, a base é colocada em estado online e fica acessível.
No recovery, o transaction log do backup é lido e aplicado aos dados. Se
no comando RESTORE for feito o uso da função NORECOVERY, a fase de
recovery não ocorre completamente.
Nas configurações do SQL Server de log shipping, um terceiro servidor
opcional (chamado Monit or) pode ser configurado para realizar tarefas de
monitoramento do log shipping. Caso não seja possível utilizar um
servidor exclusivo para este fim, o secondary server pode realizar o papel
de Monitor.
Em linhas gerais, o log shipping funciona da seguinte maneira:
1. Na etapa inicial de configuração, no Primary Server é realizado um
backup full da base a ser replicada em pasta compartilhada;
2. No Secondary Server, o arquivo de backup do item anterior é utilizado
para criação de base réplica através de restore, sem que a base réplica
seja aberta para alterações. Os passos 1 e 2 podem ser feitos no
momento da configuração inicial do log shipping, ou antes disso para
maior controle do processo de backup/restore;
3. Backups periódicos do transaction log são gerados em disco no
Primary e depois copiados para o Secondary automaticamente por jobs
do SQL Server;
4. Com as cópias dos backups do transaction log já no Secondary, é feito
o restore de transaction log na base no Secondary, deixando-a em um
estado em que futuros backups de transaction log sejam restaurados.
Para que a transmissão de arquivos entre Primary e Secondary ocorra, é
necessário que os backups de transaction log fiquem em uma pasta
compartilhada que todos os servidores envolvidos no log shipping
R
e
c
e
b
a
 n
o
ti
fic
a
ç
õ
e
s 
:)
Alta disponibilidade no SQL Server http://www.devmedia.com.br/articles/viewcomp_forprint.asp?comp=33296
10 de 18 07/02/2017 13:32
possam acessar.
Uma vez configurado o log shipping, as tarefas de cópia e restore de
transaction log são feitas automaticamente através de jobs do SQL
Server e o monitoramento é feito através do Management Studio.
Existem ambientes em que o backup é feito em fita, seja localmente no
servidor ou em robôs. Caso o servidor configurado com log shipping
esteja em um ambiente onde o padrão é o backup de SQL Server em
fita, os servidores do log shipping devem utilizar backup em disco.
Com isto, o software de backup, em vez de fazer backup do SQL Server
direto para fita, deve fazer backup em fita dos arquivos gerados pelo
backup do SQL Server.
Uma vantagem do log shipping é que ele pode ter mais de uma base
replicada em servidores instalados em locais distantes. O fato do backup
ficar em disco pode ser uma desvantagem, pois é necessário espaço para
manter backups full e de transaction logs, aumentando o custo de
storage.
Database mirroring
Esta é uma tecnologia que fornece proteção no nível do banco de dados,
assim como o log shipping. Por ser uma proteção em nível de banco de
dados, os cuidados a entidades externas ao banco como backup, restore
e database users órfãos são as mesmas do log shipping.
A diferença para o log shipping é que, após o restore inicial, não é
necessário ter um compartilhamento de rede para manter e compartilhar
os backups de transaction log pois o mirror não depende destes arquivos
para funcionar.
Como esta tecnologia não será mantida em futuras versões do SQL
Server, deve-se tomar cuidado com uso de mirror em ambientes que
sofrerão upgrade.
R
e
c
e
b
a
 n
o
ti
fic
a
ç
õ
e
s 
:)
Alta disponibilidade no SQL Server http://www.devmedia.com.br/articles/viewcomp_forprint.asp?comp=33296
11 de 18 07/02/2017 13:32
O database mirroring é uma solução para aumentar disponibilidade
através do suporte quase instantâneo a falhas. Pode ser usado para
manter uma única base de standby ou mirrored database,
correspondente a uma base de produção chamada principal database.
Cada base da parceria principal/mirrored fica em instâncias distintas e,
para garantir disponibilidade, devem ficar em servidores distintos.
No mirroring, toda operação de DML executada na base principal é
refeita no mirrored database. Refazer envolve enviar um conjunto de
transaction log records ao server mirror, que aplica os logs records no
mirror database. O servidor principal compacta o conjunto de transaction
log records antes de enviar ao mirror server, otimizando o uso de rede.
O mirroring possui dois modos de funcionamento:
· Sín cr on o – neste modo, a finalização da transação ocorre apenas
quando ela é confirmada nas bases principal e mirrored, trazendo desta
forma possível latência no tempo de resposta. Este modo é chamado
high-safety pois garante que as bases estão no mesmo estado
transacional a qualquer momento;
· Assín cr on o – neste modo, assim que o principal servidor envia o log
de uma transação para o mirror server, ele ao mesmo tempo envia
confirmação ao cliente sem aguardar um reconhecimento vindo do mirror
server.
Este modo é chamado também de high-performance e é útil em cenários
de recuperação de desastres no qual a distância entre os pares do mirror
é significativa, pois a latência ou mesmo queda de rede entre os
servidores não causa grande impacto no funcionamento do servidor
principal.
Este modo deve ser utilizado com cuidado pois, dependendo do caso, a
mudança de papéis entre principal e mirrored pode causar perda de
dados.
A ação de troca de papéis entre principal e mirror é chamada failover. O
R
e
c
e
b
a
 n
o
ti
fic
a
ç
õ
e
s 
:)
Alta disponibilidade no SQL Server http://www.devmedia.com.br/articles/viewcomp_forprint.asp?comp=33296
12 de 18 07/02/2017 13:32
modo high safety ou síncrono pode ser usado com failover manual ou
failover automático. O failover manual pode ser feito quando as bases
estão sincronizadas porque se a instância do servidor mirror ficar inativa,
a instância principal trabalha sem problemas, mas exposta a falhas.
Se o servidor principal cair, o mirror é suspenso, mas o serviço pode ser
forçado para o servidor mirror com possível perda de dados pois eles
poderiam não estar sincronizados no momento da queda do servidor
principal.
A melhor forma de usar o modo síncrono é com failoverautomático.
Nesta configuração, além dos servidores principal e mirror, existe uma
terceira instância (chamado Witness) que é usada no quórum do
conjunto. Este quórum é utilizado para saber qual dos nós deve ser o
principal em um determinado momento.
Esta configuração utiliza discos distintos para cada servidor, ou seja,
cada parceiro do mirror pode estar ligado a volumes distintos da SAN ou
cada servidor pode ter seu conjunto local de discos.
A independência de armazenamento compartilhado traz a vantagem que
os servidores, além de poderem evitar o uso de SAN de alto custo,
podem estar localizados a grandes distâncias, possibilitando seu uso
como solução de disaster recovery.
AlwaysOn Availability Group (AOAG)
Primeiramente você deve estar se perguntando o porquê deste item de
AlwaysOn não estar na sequência do assunto AlwaysOn Failover Cluster
Instance. A resposta é que o AlwaysOn Availability Group (AOAG) é uma
alternativa ao mirroring, o qual acabamos de explicar.
Entender o mirroring ajuda a entender o AOAG pois seu funcionamento é
parecido, porém os availability groups têm vantagens em relação ao
mirror e acreditamos que sejam estas melhorias que levaram a Microsoft
a descontinuar o mirror.
R
e
c
e
b
a
 n
o
ti
fic
a
ç
õ
e
s 
:)
Alta disponibilidade no SQL Server http://www.devmedia.com.br/articles/viewcomp_forprint.asp?comp=33296
13 de 18 07/02/2017 13:32
A funcionalidade AOAG está disponível no SQL Server a partir da versão
2012 e fornece proteção contra falha de database. Os principais
benefícios do AOAG são:
· No SQL Server 2012 podem haver até cinco réplicas de uma base
enquanto no SQL 2014 podem haver nove réplicas de uma base;
· A réplica pode ser configurada como uma base somente leitura, que
pode ser útil para desonerar a base principal em caso de consultas que
consumam muito recurso do servidor, como as de geração de relatório ou
de carga para data warehouse;
· A réplica também pode ser utilizada para backups, desonerando a base
principal;
· Uso de listener para manter a acessibilidade das bases
independentemente da localização dela. Desta forma, a base pode estar
online em qualquer um dos servidores do grupo e o acesso à mesma é
fornecido pelo listener (processo que roda no servidor e fica ouvindo
pedidos de conexão na porta definida).
O AOAG está disponível na versão Enterprise e tem como um dos
pré-requisitos o Windows System Failover Cluster nos servidores
envolvidos na configuração.
Além disso, cada réplica deve ficar em um nó distinto do cluster. A base
que fica em estado de escrita e leitura é chamada de primária e a base
replicada é chamada secundária.
O funcionamento é o mesmo do mirror, onde o setup inicial envolve o
backup da base original no servidor primário e o restore da mesma no
servidor secundário com a opção WITH NORECOVERY. Esta permite que
na base replicada possam ser aplicados registros de log vindos do
primary database. Após o setup inicial, sequências de registros do
transaction log são enviados do servidor primário para o secundário, o
qual aplica estes registros à base replicada.
R
e
c
e
b
a
 n
o
ti
fic
a
ç
õ
e
s 
:)
Alta disponibilidade no SQL Server http://www.devmedia.com.br/articles/viewcomp_forprint.asp?comp=33296
14 de 18 07/02/2017 13:32
Availability group é um grupo de um ou mais bancos de dados que
possuem uma cópia dos mesmos em outro servidor e o SQL Server
mantém a sincronização dos bancos. O failover das bases ocorre em
grupo. Por exemplo, pode-se colocar várias bases em um Availability
Group e estas bases são chamadas availability databases, que passam
por failover todas juntas.
O availability group suporta dois modos de disponibilidade, a saber:
· Assín cr on o ( Asyn ch r on ou s- com m i t m ode) – solução de
recuperação de desastres que funciona bem quando as réplicas de
disponibilidade são distribuídas por distâncias consideráveis.
Se cada réplica secundária está sendo executada em modo assíncrono, a
réplica primária não espera que nenhuma das réplicas secundárias
escreva o log em disco.
Em vez disso, imediatamente depois de escrever o escrever o registro de
log no arquivo local, a réplica primária envia a confirmação da transação
para o cliente. A réplica primária é executada com o mínimo de latência
de transação em relação a uma réplica secundária que está configurada
para o modo assíncrono.
Se o primário atual está configurado para assíncrona, ele irá fazer
commit das operações de forma assíncrona para todas as réplicas
secundária independentemente de suas configurações de modo de
disponibilidade individuais;
· Sín cr on o ( Syn ch r on ou s- com m i t m ode) – prioriza a alta
disponibilidade em relação ao desempenho à custa do aumento da
latência da transação. Sob o modo síncrono, as transações enviam ao
cliente a confirmação da transação após a réplica secundária ter escrito
em disco o registro de log.
Quando a sincronização de dados começa em um banco de dados
secundário, a réplica secundária começa a aplicar registros de log de
transação vindas do banco de dados primário correspondente.
R
e
c
e
b
a
 n
o
ti
fic
a
ç
õ
e
s 
:)
Alta disponibilidade no SQL Server http://www.devmedia.com.br/articles/viewcomp_forprint.asp?comp=33296
15 de 18 07/02/2017 13:32
Assim que todos os registros de log foram escritos no disco, o banco de
dados secundário entra no estado sincronizado. A partir daí cada nova
transação é escrita em disco pela réplica secundária antes do registro de
log ser gravado no arquivo de log local.
Quando todos os bancos de dados secundários de uma determinada
réplica secundária estiverem sincronizados, o modo síncrono suporta
failover manual e, opcionalmente, o failover automático.
Como se pode ver, o funcionamento de controle transacional do AOAG é
parecido com o do mirror, no entanto, o AlwaysOn possui vantagens
como o uso do listener, possibilidade de mais de uma réplica e uso da
base secundária para desonerar servidor principal. Como bases replicadas
podem ser usadas como disaster recovery, o monitoramento do estado
do funcionamento das réplicas é muito importante.
Etapas pré-con�guração
Exceto pelo AlwaysOn Failover Instance Cluster, as outras alternativas
citadas demandam ações do DBA como backup e restore, migração de
logins e de jobs.
A etapa de backup e restore, conforme comentado, pode ser manual ou
automática. Muitos recomendam fazê-la manualmente para maior
controle do técnico. A seguir explicaremos como realizar estas etapas.
Back u p e Rest o r e :
1. No servidor original, realizar backup normal em disco:
BACKUP DATABASE DB01 TO DISK = ‘C:\TEMP\DB01.BAK’ 
2. No servidor destino (secundário ou mirrored), realizar o restore com a
opção NORECOVERY:
RESTORE DATABASE DB01 FROM DISK = ‘C:\TEMP\DB01.BAK’ WITH NORECOVERY 
R
e
c
e
b
a
 n
o
ti
fic
a
ç
õ
e
s 
:)
Alta disponibilidade no SQL Server http://www.devmedia.com.br/articles/viewcomp_forprint.asp?comp=33296
16 de 18 07/02/2017 13:32
A partir desse ponto, podemos aplicar os registros de log vindos de um
backup de log no caso do log shipping ou registros de log diretamente de
outro servidor, nos casos de mirror e AlwaysOn availability group.
No SQL Server, o database user de um banco está vinculado a um login
do SQL Server, ou seja, quando uma base é transportada de um servidor
para outro por backup e restore, os database users são migrados, mas os
logins da instância não.
Se a base for restaurada em outro servidor, os database users ficam
órfãos e, por este motivo, no caso de restore de base em servidor
distinto do original, os logins devem ser recriadosmanualmente.
O fato de existirem usuários órfãos não impede a alteração da base para
online, mas as permissões no banco devem ser revistas e como as
aplicações usarão sempre o mesmo login, deve-se recriar os logins no
servidor destino.
Para migrar os Jobs, deve-se gerar o script do mesmo no servidor origem
e executar no servidor destino o script criado.
Cada uma das opções de alta disponibilidade do SQL Server possui
características distintas de arquitetura, manutenção e custo. Não existe
uma resposta única às necessidades de disponibilidade.
Elas devem ser escolhidas de acordo com as necessidades de negócio,
recursos financeiros disponíveis e conhecimento da equipe de suporte
sobre as alternativas de alta disponibilidade.
Lin k s
Opções de a l t a d i spon ib i l i dade do SQL Ser v er
ht tp: / / msdn.microsoft .com/ en-us/ library/ ms190202(v= sql.110) .aspx
Si st em as de r edu n dân ci a de d i sco
ht tp: / / www.infowester.com/ raid.php
R
e
c
e
b
a
 n
o
ti
fic
a
ç
õ
e
s 
:)
Alta disponibilidade no SQL Server http://www.devmedia.com.br/articles/viewcomp_forprint.asp?comp=33296
17 de 18 07/02/2017 13:32
por Alex m. Bastos
Revista SQL Magazine lover 
R
e
c
e
b
a
 n
o
ti
fic
a
ç
õ
e
s 
:)
Alta disponibilidade no SQL Server http://www.devmedia.com.br/articles/viewcomp_forprint.asp?comp=33296
18 de 18 07/02/2017 13:32