AlwaysOn no SQL Server 2014 e novidades lunares que talvez te interessem!


Imagem
“Esse cara pode ser um san admin futuramente” – Fonte: NASA

Boa noite!
Tá vendo aquela lua que brilha lá no céu?
A lua tecnicamente não brilha por si só, apenas reflete a luz do sol. Legal, né?
Quero compartilhar duas notícias (na verdade mais importantes do que realmente parecem) que sairam recentemente e vi na internet. Links do Olhar Digital:

Fantástico!

E o que isso tem relação com o SQL Server 2014?


Quero compartilhar com vocês três assuntos diferentes:

1) HA e DR com SQL Server 2014 AlwaysOn Availability Groups;
2) Quando a zueira disponibilidade não tem limites, nem na terra nem na lua;
3) O que podemos esperar daqui pra frente?;

O que  é AlwaysOn?

Introduzida no SQL Server 2012, uma nova tecnologia de alta disponibilidade (High Availability, aka HA) e Recuperação de Desastre (Disaster Recovery, aka DR) chegou atraindo bastante atenção no mercado. Estamos falando do AlwaysOn (que agora virou uma buzzword/categoria também), mais especificamente do AlwaysOn Availability Groups (Grupos de disponibilidade) que repetidamente será escrito como AG, neste post, que permite a replicação de um grupo de bases de dados.

Veja bem, isso é uma solução inédita e não se trata apenas da evolução de outras features do SQL Server, embora constantemente ela seja bastante associada com o Mirroring, com uma certa razão, embora muito superior a este , já que o mirroring possibilita criar réplicas mas sempre 1:1 enquanto Grupos de disponibilidade replicam, grupos de várias bases para N réplicas, onde o valor de N dependerá da versão do SQL Server utilizada.

Nem vou abordar outras tecnologias de Alta Disponibilidade e DR nesse post, pois não é o foco. Quero falar (e apenas um  pouco) do AG.

Creio que pela imagem abaixo, é fácil entender como funciona essa solução: Crie réplicas de grupos de banco de dados. Mas não apenas! Aproveite as suas réplicas.

Imagem
Printei do Introducing SQL Server 2012 – Ross Mistry e Stacia Misner

A grande maestria deste esquema é que você pode utilizar as réplicas para aliviar a carga de trabalho (workload) que as suas bases principais (que por razões de nomenclatura é chamada de réplica principal) possuem normalmente com operações bastante comuns, como por exemplo, Backup e realização de relatórios (e aqui pode incluir também aquele “SELECT simples” que envolve umas quinze tabelas de setenta mil linhas, direto em produção, kkkkk) além de, é claro, contar com uma excelente solução de Disaster Recovery (na minha opinião é a melhor tecnologia de DR do produto), enquanto também conta com Alta Disponibilidade caso seja necessário.

A replicação da réplica principal para a(s) secundária(s) pode ser síncrona (garantindo que a réplica secundária sempre terá o mesmo dado da principal: isso custa performance em troca desse tipo de segurança) e a assíncrona (bem mais performática, garantindo que a secundária terá o mesmo dado da principal, embora demore um pouquinho mais (e bem, bem pouco) que modo síncrono pra que haja essa igualdade).

Você pode configurar suas réplicas para terem preferências de atividades (por exemplo, uma réplica preferencial para leituras e outra pra retirada de backups, por exemplo) para melhor aproveitamento do seu ambiente! E como se já não fosse legal o suficiente, você pode contar com até quatro (4) réplicas secundárias.
Para maiores informações, verifique as referências do post.

E o AlwaysOn Availability Groups no SQL Server 2014?

Toda vez que leio algo sobre o 2014 sinceramente fico feliz em como ele traz boas surpresas, mesmo que talvez eu nunca vá utilizar em produção 😀
Depois do Hekaton um grande destaque foi a melhoria realizada no AG.
Sente o drama:
– No 2012, era possível ter quatro réplicas secundárias. No 2014, esse número dobrou. Oito réplicas agora!
– Possibilidade de se ter secundários no Azure (!!!)

E pode não parecer tão importante assim (porque muita gente sabe que o Azure é legal mas por algum motivo que desconheço é bastante ignorado) mas traz um conceito bastante interessante quando falamos de Disaster Recovery: Replicação Geográfica (Geo-replication).

Geo-Replication?

Em resumo, Replicação Geográfica é uma abordagem utilizada pelo Windows Azure para manter sua estrutura extremamente estável, para garantir que não haja de forma alguma perda de dados. Existem vários Datacenters do Azure pelo mundo e os dados são replicados entre eles justamente para garantir tudo isso.

Em outras palavras: no momento que você envia uma réplica pro Azure,  de modo transparente a mesma  será replicada para outros Datacenters ao redor do mundo, garantindo uma confiança maior ainda na segurança dos seus dados (no sentido de não perdê-los em caso de desastre).

Já imaginou ter seus dados replicados para um site de DR fora de seu ambiente (justamente por estar na nuvem) e que tem redundância por ele mesmo mesmo que você não precise?

Isso é muito bacana da Cloud Computing inteligente e está aí disponível no SQL Server 2014 utilizando o Azure.

Tem também o armazenamento de backups do SQL Server para o Azure, mas esse assunto, embora seja muito interessante e relacionado com o tema Disaster Recovery, não será abordado aqui 🙂

Alguns vídeos caso tenha interesse sobre o Windows Azure (e seus humildes datacenters):

https://www.youtube.com/watch?v=JJ44hEr5DFE

Mas bem, sabemos que temos vários Datacenters na terra. Existe alguma chance de termos fora dela?

Tá, e de onde você tirou a ideia de reunir lua, alwaysOn e SQL Server num post só?

O primeiro motivo é óbvio: tava muito tempo sem postar e PAM! Me aparecem essa duas notícias. Achei legal compartilhar.
O segundo motivo: falar um pouco (quase nada, mas já é alguma coisa) sobre SQL Server 2014.
O terceiro motivo é pra interligar um relato engraçado sobre tudo isso.

Que relato?

Era uma vez alguns prezados dentro de um carro em movimento, conversando exatamente sobre essa nova habilidade do AG no SQL Server 2014 onde ter réplicas no Azure é uma possibilidade. Até que o prezado eu#### comentou que se um meteoro cair na terra, ainda assim ia ter réplicas de pé pra de alguma forma manter a continuidade do negócio (vale lembrar que tal meteoro em momento algum foi citado como “suficiente pra destruir a terra inteira”).

O final dessa conversa foi bastante polêmica, pois existem várias versões sobre ela onde cada um entendeu uma coisa diferente (e pra deixar a brincadeira rolar, não vou contar a original, pois vão me chamar de tendencioso, obviamente. Stakeholders do assunto, fique à vontade para usar os comentários  *risos*) mas a conclusão que grande parte dos envolvidos saiu é que: é bem provável que todas as soluções de HA e DR não saiam do nosso planeta mesmo que se fosse pra algo perto, tipo a lua. Lembro como se tivesse escutado hoje as palavras “imagina a latência disso aí kkkkkk” e veja bem…voltamos ao começo do post com as notícias onde empresas já visam locais mais seguros que a terra para armazenar arquivos de extrema importância e agora, ficamos sabendo de um link wi-fi criado pela NASA e MIT que dá um banho na maioria das conexões existentes no Brasil.

Lembro que li isso rindo:

Imagem

Vou deixar esse dilema para os conspiracionistas de plantão.

Sendo direto: Existe alguém que acredita que a lua seja um lugar extremamente seguro pra guardar ativos que considera importante. Ou não é tão seguro, mas pelo menos tá longe da Terra (sacou o pensamento de contigência?).

Será que os grandes players do mercado de SGBD’s possuem interesse em criar alguma solução  por lá também? A partir do momento que for rentável, não duvidaria dessa possibilidade. Vamos acompanhar….

Alguém chuta em qual versão do SQL Server (20XX) teremos réplicas lunares?

Teremos edições com nome mais sugestivos, tipo Interplanetary Edition?

Tem algum trocadilho engraçado, opinião, crítica, elogio, piada, versão do relato do meteoro pra compartilhar?

[]’s

Referências:

Visão Geral AlwaysOn

Novidades no AlwaysOn no SQL Server 2014


2 responses to “AlwaysOn no SQL Server 2014 e novidades lunares que talvez te interessem!”

Leave a Reply to Rodrigo Ribeiro Gomes Cancel reply

Your email address will not be published. Required fields are marked *