Replicação Semi Sincronizada no Mysql 5.5

Fala Pessoal, estava meio afastado mas hoje vou falar das novas caracteristicas de replicação no Mysql 5.5


MySQL 5.5 suporta uma interface de replicação semi-síncronas, além da embutida replicação assíncrona.

A replicação do MySQL, por padrão é assíncrona. O mestre grava eventos em seu log binário, mas não sabe se ou quando um escravo tem recuperado e transformado-los. Com a replicação assíncrona se o máster  falhar, as operações de que tenham sido comitadas não poderiam ser  transmitidas a um escravo. Consequentemente esse failover de um mestre a escravo neste caso pode resultar em failover para um servidor que está faltando operações relativas ao mestre.

A Replicação semi-síncronas pode ser usada como uma alternativa para a replicação assíncrona:

· Um Escravo indica se ele esta semi sincronizado quando se conecta ao master

· Se a replicação semi-síncronas está habilitada, no lado mestre e há pelo menos um escravo semi-síncronizado , uma thread que executa uma operação de commit em um master  cria um bloqueio após o commit  ser realizado ,então o master espera até que pelo menos um escravo semi-síncronizado reconheça que tenha recebido todos os eventos da operação, ou até um tempo limite .

· O escravo reconhece a recepção de eventos de uma transação somente após que esses eventos foram gravados em seu relay log e sofrerem flush para o disco.

·  Se um tempo limite ocorre sem que qualquer escravo tenha reconhecido a operação, o master volta a replicação assíncrona. Quando pelo menos um escravo alcança o nivel semi-síncronizado, o mestre retorna à replicação semi-síncrona..

· A Replicação semi-síncronas deve ser ativada em ambos os lados e dominar a escrava. se a replicaçãosemi-síncronas está desabilitado no master, ou habilitado no master mas não escravos, o mestre usa replicação assíncrona.

Enquanto o master está bloqueando (Esperando confirmação de um escravo, após ter efetuado um commit), ele não irá retornar para a sessão que realizou a transação. Quando o bloqueio termina, o máster retorna à sessão, que pode então proceder para executar outras instruções. Neste ponto, a transação foi comittada no lado mestre, e a recepção de seus eventos foram reconhecidas por pelo menos um escravo.

O bloqueio também ocorre após rollbacks que são escritas no log binário, que ocorrem quando uma operação que modifica as tabelas não transacionais é revertida. A transação rolled-back é registrada, mesmo que não tem nenhum efeito para tabelas transacionais porque as modificações nas tabelas não transacionais não podem ser revertidas e devem ser enviados para os escravos.


As instruções que não ocorrem em contexto transacional (ou seja, quando nenhuma transação tenha sido iniciado com START TRANSACTION ou SET autocommit = 0), O autocommit é ativado e cada declaração compromete implicitamente. Com a replicação semi-síncronas, O master é bloqueado após o commit da instrução, da mesma forma que ocorreria para uma transação com um commit explicito.



Para entender o que o "semi"  "da replicação semi-síncrona" significa,  vamso compar a replicação assíncrona e totalmente sincronizada:

·         Com a replicação assíncrona, o master grava eventos em seu log binário e escravos requisitam quando eles estiverem prontos. Não há garantia de que qualquer evento jamais chegar a qualquer escravo.


·         Com a replicação totalmente sincronizada, quando um master efetua um commit de uma transação, todos os escravos terão o commit da transação antes do retorno do mestre para a sessão que realizou a transação. A desvantagem desta situação é que pode haver muita demora para completar uma transação.


·          A Replicação semi-síncrona cai entre replicação assíncrona e totalmente sincronizada. O Master aguarda após o commit apenas até, pelo menos, um escravo tem recebido e registrado os eventos. Ele não espera que todos os escravos confirmem a recepção, e ele exige apenas a recepção, não que os eventos tenham sido integralmente executados e empenhados no lado escravo.

Comparado a replicação assíncrona, a replicação semi-síncronas proporciona maior integridade dos dados. Quando um commit é retornado com sucesso, sabe-se que os dados existem, em pelo menos, dois lugares (no mestre e pelo menos em um escravo). Mas se ocorre um crash no  master enquanto o ele está esperando a confirmação de um escravo, é possível que a operação possa não ter alcançado nenhum escravo.( Ai Chora!!! )


A Replicação semi-síncronas tem algum impacto no desempenho porque os commits são mais lentos devido à necessidade de esperar pelo os escravos. O dilema para a aumentar a integridade dos dados é o tempo de resposta do TCP / IP para enviar a confirmação para o escravo e aguardar a confirmação da recepção pelo escravo. Isto significa que a replicação semi-síncronas funciona melhor para os servidores que fecham comunicação através de redes rápidas, e o pior para os servidores distantes se comunicando por redes lentas.

Tempo médio de recuperação de uma Instância - MTTR- Oracle

Fala Pessoal,
Hoje eu vou falar sobre falha e recuperação de uma instância.
Dizemos que um banco de dados esta corrompido quando o banco é finalizado por uma falha ou um shutdown abort , armazenando transações sem commit. Quando ocorre isso na hora da inicialização da instância o oracle irá aplicar o conteudo dos Redo logs para recuperar a instância, vai usar o conteúdo dos arquivos de redo log para reconstruir o cache do banco de dados para o estado que ele estava antes da falha.

O MTTR (mean time to recover)  - Tempo médio de recuperação

A Recuperação da instância garante corrupção zero, mas até todas as alterações dos arquivos de Redo tenham sido aplicadas nos blocos de undo e nos blocos de dados, vamos ter um custo de I/O referente aos arquivos de dados a medida que o redo é aplicado. Esses fator pode ser controlado pelo checkpoint.

O Checkpoint , vai garantir que apartir de uma certa hora, as alterações dos dados, que compõem um SCN específico tenham sido aplicadas nos datafiles pelo DBWn. Quanto mais atualizada esta a posição do checkpoint, mais rápida vai ser a recuperação da instância, porque não há necessidade de aplicar o redo nas transações que sofreram commit antes de uma falha.

Avançamos a posição do checkpoint quando gravamos gravamos os blocos alterados no disco, o que gera I/O . Porém se DBWn ficar muito atrasado de uma forma com que caso ocorra um falha SMOn tenha que fazer um I/O muito grande nos datafiles para aplicar as alterações do redo,isso vai gerar um tempo de recuperação da instância muito grande, ou seja o MTTR vai subir.

Para ajudar a controlar essa questão temos o parâmetro FAST_START_MTTR_TARGET. Esse parâmetro é especificado  em segundos e  ajuda a controlar o tempo de recuperação de uma instância. Esse parâmetro vem configurado como default 0, caso esse valor seja modificado , vai ser ativado o autoajuste do checkpoint, o que força uma analise das estatísticas sobre os recursos e utilização da máquina, e caso houver capacidade extra , esta será usada para gravar os buffers sujos adicionais do database buffer cache, fazendo assim a posição do checkpoint subir.

O que um DBA deve saber ....

Certa vez lendo algum artigo na internet achei essas recomendações ....
Para que o DBA possa exercer adequadamente o seu papel e cumprir com suas responsabilidades é importante que ele detenha algumas competências:
*Conhecimentos em Sistemas Operacionais: Um banco de dados é totalmente dependente do sistema operacional onde está instalado.
É fundamental que o DBA conheça conceitos ligados ao sistema operacional (processos, threads, gerenciamento de memória, paginação, sistema de arquivos, etc)
para poder adequar o máximo possível o sistema operacional ao banco de dados utilizado.
*Conhecimentos em Redes: É desejável que o DBA conheça características da rede (capacidade de tráfego, protocolos, etc).
*Compreensão em arquitetura em banco de dados: Entender como funciona um banco de dados é um pouco mais do que conhecer uma tecnologia específica
(ORACLE, DB2, SQL Server, etc).
Entender alguns dos andamentos de banco de dados (algoritmos de indexação, concorrência, transações, etc) podem ser tão valiosos quanto conhecer
as implementações de um produto específico.
*Noções do sistema de armazenamento: É importante ao DBA ter conhecimento dos princípios que são utilizados nos sistemas de armazenamento (RAID, SAN, etc).
Esse conhecimento pode ajudar o DBA a utilizar a infra-estrutura de armazenamento para um projeto físico eficiente.
*Manuseio do XML: Esse padrão já possui uma forte aceitação e cada vez mais os profissionais de banco de dados têm de conviver com ele.
É importante que o DBA conheça XML e suas tecnologias correlatas (XSD, Web Services, etc).
*Noções de ETL (Extract, Transform, Load*.*): Com o crescente mercado de Business Inteligence é esperado o aumento de bases multidimensionais utilizando diversas tecnologias
de banco de dados (XML, Flat Files, banco de dados relacionais, banco de dados orientados a objeto, etc).
É importante ao DBA conhecer meios para dar suporte a rotinas de extração, transformação e carga no projeto de Data Warehouse além de monitoramento das consultas.

O Processo de Commit

Fala Pessoal,estava lendo um artigo sobre performance o qual explicava sobre o processo de commit e explicava o conceito do termo SCN, achei interessante e resolvi publicar aqui no blog.
O Banco de Dados Oracle usa um rapido mecanismo de de commit o qual garante que as mudanças efetivadas possam ser recuperadas em caso de falhas da instância.

 SCN (System Change Number) Número de mudança do Sistema.

 Sempre que uma transação sofre commit, o banco de dados Oracle atribui SCN para a transação. O SCN é constantemente incrementado e é único dentro do banco de dados. Ele é usado pelo banco de dados Oracle como um carimbo de tempo interno para sincronizar os dados e fornecer consistência de leitura quando os dados são obtidos a partir dos arquivos de dados. Usando o SCN habilitamos o banco de dados oracle para executar verificações de consistência sem depender da data e da hora do sistema operacional.
Quando o commit é emitido, as seguintes etapas são realizadas:

1. Processo do servidor coloca um registro de commit, com o SCN, no buffer redo log.
2. O Processo de background Log Writer (LGWR) realiza uma constante escrita de todo Redo Log buffer até e inclusive o registro de commit para os arquivos de Redo Log .Após esse ponto o banco de dados já pode garantir que as alterações não serão perdidas mesmo se houver uma falha na instancia.
3. O Processo do servidor fornece um retorno ao usuário sobre o processo de realização da transação.

 Em Algumas vezes o Processo de background DBWR  escreve as reais mudanças de volta para o disco baseado  em um próprio sistema de temporalização interno.
Fonte :Oracle Database 10g :SQL Tuning - Priya Vennapusa

Processamento das Instruções SQL no Oracle

Fala Pessoal,

Um Bom entendimento de como as instruções SQL são processadas no banco é fundamental para uma criação otimizada de instruções SQL. No Processamento de Instruções SQL, existem quatro fases Importantes as quais vou relatar ao longo dos meus posts e que são elas:
Parsing,binding,Executing and Fetching. Nesse post irei começar falando da fase de parse.

Fase de Parse (Análise)
A Fase de Parsing é um dos estágios que ocorre no processamento das instruções SQL. Quando uma aplicação emite uma instrução SQL, , ela na realidade emite uma chamada para o banco de dados e durante essa chamada para o banco analisar essa instrução, ou seja verificar se realmente é possível extrair resultados dela, e nessa fase de analise, o Oracle:

Verifica a instrução sql, sua sintaxe e  valida a sua semântica

Determina se o processo de emissão da instrução SQL tem a devida permissão para executá-la.

Aloca uma área privada para a instrução SQL

O Oracle primeiramente verifica se já existe uma analise (parse) dessa instrução SQL no cachê de biblioteca. Se já existir uma analise dessa instrução no cachê de biblioteca, essa instrução é executada imediatamente porém se a mesma não existir, o Oracle irá gerar uma analise dessa instrução e o processo do usuário ira alocar uma área de SQL compartilhada para a instrução no cachê de biblioteca após esse procedimento a instrução será analisada nesta área.
A Operação de Parse (análise) do Oracle sempre aloca uma área compartilhada para uma instrução SQL. Depois dessa área compartilhada ter sido alocada para essa instrução, a mesma já pode ser executada novamente repetitivamente(varias vezes) sem precisar ser analisada , ou seja sem precisar passar pela fase de Parse. O processo de Analise pode ser "caro" em relação a execução, pode ter um alto custo dos requisitos disponíveis, por isso essa etapa deve ser minimizada sempre que possível. O Ideal é que a instrução deva ser analisada uma vez e executada varias vezes sem a necessidade de uma nova análise para cada execução.
Existem dois Tipos de Operação de Parse (Analise):

1. Hard Parsing : Dizemos que existe uma operação de Hard Parse quando uma instrução Sql é executada pela primeira vez e ela não se encontrada na shared pool. Esse tipo de parse é a fase que mais consome recurso intensivamente do banco de dados, porque quando isso ocorre é necessario executar todas as operações necessárias da fase de parse.
2. Soft Parsing: Dizemos que existe uma operação de Soft Parse quando uma instrução executada já existe na shared pool..Quando uma instrução sql já esta armazenada no cache de biblioteca temos um ganho de performance.No entando, até mesmo na fase de parse temos ainda um consumo de recursos, pois mesmo a instrução já estando armazenada o banco ainda precisa verificar os parâmetros de segunça e a sintaxe da instrução e isso consome recursos do sistema.

Quando as variáveis bind (ligação) são usadas de modo correto, a operação de sof parsing ocorre mais vezes no banco da dados, reduzindo assim a operação de hard parsing e mantendo as instruções analisadas na cachê de biblioteca por um tempo maior.