Configurando Replicação Semi – Sincronizada no Mysql

    Hoje vou explicar como configurar uma replicação semi sincornizada no mysql, no post Replicação Semi Sincornizada eu expliquei o que era essa nova feature do mysql , e as vantagens dela em relação a replicação normal contida na versão 5.1 e anteriores.
    Na realidade demorei para publicar esse post, porque não podia falar dela sem testa-la, eu precisei configura-la em uma ambiente de produção web, e após 2 meses a replicação se encontra totalmente estavél. Com a segurança de um ambiente de produção de um grande portal, com mais de 300 consultas por segundo, vou explicar agora como configurar a replicação semi sincronizada
utilizando o mysql 5.5.3.

Meu cenário foram de 3 servidores com o mysql 5.5.3 em uma rede Gigabyte, utilizando o CentOS 5.5.

A Primeira coisa a ser realizada é a instalação dos plugins necessários.

Os plugins da replicação semi-síncronizada já estão incluídos com a distribuição MySQL. Atualmente, os plugins só estão disponíveis para Linux. Em outras plataformas são ainda não é suportado.

No master instale o seguinte plugin:

semisync_master.so

mysql >; INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';

No Slave instale o seguinte plugin:

semisync_slave.so

mysql >; INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';

Caso na hora da instalação do plugin , ocorra o erro abaixo :

ERROR 1126 (HY000): Can't open shared library
'/usr/local/mysql/lib/plugin/semisync_master.so' (errno: 22 libimf.so: cannot open
shared object file: No such file or directory)

Será necessário o download da libmf em :
http://dev.mysql.com/downloads/os-linux.html.


Para verficar os plugins instalados você pode dar um show plugins ou ainda efetuar a consulta SELECT * FROM  INFORMATION_SCHEMA.PLUGINS.

Após a instalação os plugin são ativados por default, é importante a instalação dos plugins tanto no master quanto no slave, caso contrario a replicação será assincrona.

Configuração no Master

No banco master é necessário a configuração das seguintes variaveis no arquivo de configuração do Mysql (Quando instalado em distribuições rpm, fica localizado em /etc/my.cnf)

Entre os servidores que compoem o esquema de replicação, cada servidor deve possuir um id único, o id do servidor é estabelecido pelo parâmetro :

--server-id=x ( Onde x é o id do servidor)

Caso ocorra duplicação desse valor entre os servidores, ocorrera problemas na replicação.

Habilite a Replicação Semi-Sincronizada com as variaveis:

rpl_semi_sync_master_enabled=1
Essa variavel determina o tempo de resposta do slave ( Maiores informações leia meu post sobre replicação semi sincronizada)

rpl_semi_sync_master_timeout=10
O Log binário deve estar habilitado no master porque o log binário é a base para o envio de dados das alterações do master para seus escravos. Se o log binário não estiver habilitado, a replicação não será possível.

Exemplo
log-bin     =     /var/lib/mysql/mysql-bin-database-01.log
log-bin-index = /var/lib/mysql/mysql-bin-database-01.log.index

Para uma maior durabilidade e consistência possível em uma configuração de replicação usando InnoDB com transações, configure as seguintes variaveis:

usar innodb_flush_log_at_trx_commit = 1
sync_binlog = 1

Para estabelecer que a replicação ocorra para um unico banco utilize a varivavel a seguir:

binlog-do-db = nome_do_banco

Para estabelecer o numero de dias de vida dos logs binários utilize a seguinte variavel :

expire_logs_days = (número de dias)

Configuração no Slave

Configure o id do servidor com :

--server-id=x ( Onde x é o id do servidor)

Habilite a replicação semi sincronizada
rpl_semi_sync_slave_enabled=1

Configure o Relay Log

O relay log consiste em ler os eventos do log binário do master e escrito pela  thread de I/O do Slave. Eventos no relay log são executadas no slave, como parte da linha SQL.

Exemplo:
relay-log=relay-bin-server2

Obs: Após as alterações no arquivo de configuração my.cnf é necessário o restart do mysql.

Crie um usuário para a Replicação

È necessário que você crie um usuário no servidor master, com permissão de acesso das outros servidores presentes na arquitetura de replicação
Esse usuário precisa de grant de replicação.

Use esse comando para conceder grant ao usuário.

GRANT REPLICATION SLAVE ON *.* TO 'user'@'%';

Verifique a necessidade de segurança do seu banco de dados, para verificar os privilégios adequado a esse usuário.


Ativando a Replicação.

Se você seguiu todos os passos corretamente nesse momento o master já esta registrando gerando as informações no log binário, então agora é o momento de ligar a replicação.
Existe duas formas de ligar a replicação, uma é atraves de variaveis do my.cnf, outra é com o comando change master to, por considerar o comando change master to mais seguro escolhi essa opção:

No master execute o comando:

Show master status;
Você deve ter uma resposta parecida com essa:
mysql> show master status;
+------------------+-----------+--------------+------------------+
| File             | Position  | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+-----------+--------------+------------------+
| mysql-bin.000005 | 153469228 | qb3_migracao |                  |
+------------------+-----------+--------------+------------------+

No slave execute o seguinte comando :

use as informações obtidas no comando show master status;

 CHANGE MASTER TO
         MASTER_HOST='nome_do_servidor_master',
         MASTER_USER='usuario_para_replicacao',
         MASTER_PASSWORD='senha_do_usuario',
         MASTER_LOG_FILE='nome_do_log_binario',
         MASTER_LOG_POS=0;
Agora execute o comando:

mysql> STOP SLAVE IO_THREAD; START SLAVE IO_THREAD;

Pronto , você acabou de configurar uma replicação semi sincronizada no Mysql.

Para verificar o status execute o comando:

show slave status\G;

Verifique no log do servidor slave as seguintes linhas:

 [Note] Slave I/O thread: Start semi-sync replication to master 'slave-01@qb-database-main-01:3306' in log 'mysql-bin.000005' at position 001

Embora a versão 5.5 do mysql ainda não seja uma versão  Generally Available (GA) ,
hoje tenho servidores em produção com essa versão e tenho obtido ganhos relavantes a versão  5.1, e a feature  replicação semi sincronizada , é uma das que mais tem me agradado, é mais segura , eu acompanho via log qualquer problema que possa ocorrer.

Nos proximos posts , irei abordar sobre as novas features do innodb.

Abraços !

A Luz no fim do túnel ... no Oracle

Perdeu os archives ???
Perdeu o backup ???
Não tem mais jeito ???
Demissão ???

È pessoal pode ser que ainda exista a última esperança.

_allow_resetlogs_corruption = true

Com esse parametro no spfile, pode ser que  o banco abra resetando os logs , ai você recupera os dados e reza, mas raza muito pra ninguém descobrir o que realmente aconteceu.

Bem não preciso nem dizer que esse é um parâmetro não documentado, que a chance de dar errado é grande, e se você ferrou seu ambiente de produção pra testar se ele funciona, boa demissão!!!

Sem brincadeiras, já testei o parâmetro em um ambiente de testes, fiz o backup, deletei todos os archives e exclui alguns datafiles, acrescentei ele no spfile e dei um alter database open resetlogs e ele subiu.

Já presenciei outra situação na qual ele também funcionou, mas espero que nem eu nem vocês nunca tenham que usá-lo pra valer.
Abraços!!

Cache Hit Ratio Oracle

A Buffer Cache é um recurso compartilhado, acessível por todos os usuários.
Quando um usuário emite uma consulta , O Oracle antes de ir nos datafiles buscar os blocos necessários para retornar o resultado, primeiro olha para os blocos de dados na buffer cache.
Se os dados colocados no cache são retornados para o solicitante imediatamente .
Ocorre o famoso Hit Ratio .
Quando os dados não forem encontrados, um cache miss ocorre e o processo do usuário irá lêr os dados do disco para um buffer disponível no cache.
A taxa de acerto do cache é a percentagem total de solicitações de dados que são servidos diretamente a partir da buffer cache.
No Oracle, o buffer cache hit ratio normalmente é calculado utilizando a seguinte fórmula:
Cache Hit Ratio = 100 * (1 - leituras físicas / lógicas leituras)
Nesta fórmula, "leituras físicas", corresponde à falta de cache e 'leituras lógicas "corresponde ao total de solicitações de dados.
Ajustando o buffer cache para optimizar o desempenho normalmente ocorre a adição de buffers no cache até que a taxa de acerto foi maximizada.
O número de buffers no cache é especificado pelo parâmetro de inicialização DB_BLOCK_BUFFERS.
Abraços !!

Tempo de Recuperação e outros parâmetros no Oracle

Fala Pessoal,
A visão V$Instance_Recovery merece destaque nesse assunto, as principais colunas são:
recovery_estumated_ios - > O número de operações de i/o nos datafiles que seriam necessárias para a   recuperação se a instância falhasse.
actual_redo_blocks - > O número de blocos de redo do sistema operacional que se precisariam ser aplicados aos datafiles para a recuperaçõ se a intância falhasse agora.
estimated_mttr - > O número de segundos necessários para abrir o banco de dados caso ele falhasse agora.
writes_mttr -> O número de vezes que o DBWn teve de gravar, além das gravações que ele normalmente faria, para atingir a meta do mttr.
Enfim uma mão na roda......

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.