segunda-feira, 9 de agosto de 2010

Manutenção em Tabelas no MySQL - Parte II

Continuando o post anterior hoje vou falar das ferramentas utilizadas para a manutenção de tabelas do MySQL.

CHECK TABLE

A instrução CHECK TABLE executa uma verificação de integridade de conteúdo e estrutura da tabela. Ele funciona para tabelas MyISAM e InnoDB,ARCHIVE, and CSV. Para tabelas MyISAM, ele também atualiza as estatísticas de índice. Se a tabela é uma view, CHECK TABLE verifica a definição da view. Se a saída de CHECK TABLE indica que uma tabela possui problemas, a tabela deve ser reparada.

mysql> check tables action;
+---------------------+-------+----------+----------+
| Table | Op | Msg_type | Msg_text |
+---------------------+-------+----------+----------+
| qb3_migracao.action | check | status | OK |
+---------------------+-------+----------+----------+
1 row in set (15.93 sec)


Para maiores informações consulte o link :
http://dev.mysql.com/doc/refman/5.5/en/check-table.html

REPAIR TABLE

O REPAIR TABLE corrige problemas em uma tabela que foi corrompida.
Ele só funciona para tabelas MyISAM,ARCHIVE, and CSV.
Para executa-lo é necessário ter privilégios de Select e insert sobre a tabela.
È extremamente importante antes de executar um repair table, que seja feito um backup dos dados.
Se o servidor falhar durante a execução do REPAIR TABLE, é essencial depois de reiniciá-lo de que você execute imediatamente outro REPAIR TABLE na tabela antes de executar quaisquer outras operações sobre ela. Na pior das hipóteses, você pode ter um novo arquivo de índice limpo sem informações sobre o arquivo de dados e, em seguida, a próxima operação de executar poderia substituir o arquivo de dados. Este é um cenário improvável, mas possível que ressalta o valor de fazer um backup primeiro.

Obs: O Comando Repair table por default escreve no log binario e se for um servidor master de uma replicação, vai replicar a instrução para todos os slaves, então nesse caso é necessario que se rode a opção NO_WRITE_TO_BINLOG.

Maiores informações acesse :
http://dev.mysql.com/doc/refman/5.5/en/repair-table.html

ANALYZE TABLE

O ANALYZE TABLE atualiza a tabela com as informações sobre a distribuição das chaves da tabela. Essas informações são usadas pelo optmizador para fazer melhores escolhas sobre os planos de execução das consultas SQL.
Para executa-lo é necessário ter privilégios de Select e insert sobre a tabela.
Obs: O Analyze table por default escreve no log binario e se for um servidor master de uma replicação, vai replicar a instrução para todos os slaves, então nesse caso é necessario que se rode a opção NO_WRITE_TO_BINLOG.
O MySQL utiliza a distribuição de chaves para decidir a ordem em que as tabelas devem ser unidas quando você executar um join em alguma coisa que não seja uma constante. Além disso, a distribuição das chaves podem ser usadas para decidir quais os índices de uma tabela será utilizado dentro de uma consulta.

mysql> analyze table action;
+---------------------+---------+----------+----------+
| Table | Op | Msg_type | Msg_text |
+---------------------+---------+----------+----------+
| qb3_migracao.action | analyze | status | OK |
+---------------------+---------+----------+----------+
1 row in set (0.00 sec) 

Maiores informações acesse :
http://dev.mysql.com/doc/refman/5.5/en/analyze-table.html

OPTIMIZE TABLE

A instrução optimize table efetua a desfragmentação de uma tabela MyISAM. Ela recupera o espaço não utilizado, causado pela fragmentação das operações delete e update. Optimize table table classifica as paginas e as estatisticas do indices.
Optimize table também funciona em tabelas innodb, porém não efetua a desfragmentação das tabelas, para isso é necessario que se execute um ALTER TABLE nome_da_tabela engine=innodb;
È interessante ressaltar que essa operação é extremamente custosa, bloqueia as tabelas, e se for feita em produção, é necessario que seja realizado em um horário que que não seja o de pico.
Obs: O optimize Table por default escreve no log binario e se for um servidor master de uma replicação, vai replicar a instrução para todos os slaves, então nesse caso é necessario que se rode a opção NO_WRITE_TO_BINLOG.


mysql> OPTIMIZE TABLE action;
+---------------------+----------+----------+----------+
| Table | Op | Msg_type | Msg_text |
+---------------------+----------+----------+----------+
| qb3_migracao.action | optimize | status | OK |
+---------------------+----------+----------+----------+
1 row in set (0.04 sec)

Maiores informações acesse :
http://dev.mysql.com/doc/refman/5.5/en/optimize-table.html

Agora que falei das ferramentas vou mostrar uma procedure para automatizar esses recursos:
A procedure abaixo realiza um optimize em todas as tabelas do banco que você especificar, e dependendo da sua demanda você pode transforma-la em um evento do mysql, ou ainda criar um script para chama-la de tempo em tempo.

DELIMITER &&
CREATE PROCEDURE OPTIMIZE_TABLES()
BEGIN
DECLARE v_nome_table varchar(60);
DECLARE done INT DEFAULT 0;
DECLARE cur1 CURSOR FOR select table_name from information_schema.columns where table_schema='NOME_DO_BANCO' ;
DECLARE CONTINUE HANDLER FOR NOT FOUND SET done = 1;
OPEN cur1;
REPEAT
FETCH cur1 INTO v_nome_table;
IF NOT done THEN
SET @v_comando := concat("OPTIMIZE TABLES nome_do_banco.", v_nome_table, ";");
PREPARE stmt FROM @v_comando;
EXECUTE stmt;
DEALLOCATE PREPARE stmt;
end if;
UNTIL done END REPEAT;
CLOSE cur1;
END
&&
DELIMITER ;

terça-feira, 3 de agosto de 2010

Manutenção em Tabelas no MySQL - Parte I


Hoje eu vou falar sobre operações que fazem parte da vida de um DBA MySQL, que são as manutenções de tabelas, que é um processo extremamente necessário para o desempenho e integridade do seu banco de dados, dividi esse assunto em dois posts no qual vou explicar cada processo de manutenção com suas suas devidas observações e scripts para automatizar esse processo.

Manutenção nas tabelas do mysql são necessarias para identificar e corrigir problemas de integridade, ocasionados por diversos fatores como bugs, problemas no disco e no servidor e também para fornecer mais velocidade ao MySQL, veremos o porquê, a seguir os tipos de manutenção que podemos realizar: 

  • A Ferramenta check realiza uma verificação de integridade para se certificar de que a estrutura da tabela e o conteúdo não têm problemas. Esta operação poderá ser realizada em tabelas MyISAM e InnoDB. 
  • A Ferramenta repair corrige problemas de integridade para restaurar a tabela para um estado conhecido utilizável. Esse comando só tem suporte para tabelas MyISAM. 
  • A Ferramenta analyze, atualiza as estatísticas sobre a distribuição dos valores de índice de chave. Esta é uma informação que o otimizador pode usar para gerar melhores planos de execução para consultas sobre as tabelas .Esse comando pode ser feito tanto em tabelas MyISAM como em tabelas InnoDB. 
  • A Ferramenta optimize reorganiza uma tabela para que seu conteúdo pode ser acessado de forma mais eficiente. Esse comando pode ser feito em tabelas MyISAM ,InnoDB e Archive, mas com limitações que variam entre essas storages engines. 
As Ferramentas analyze e optimize são operações que você pode executar periodicamente para manter suas tabelas com sua melhor performance:
  • Quando o MySQL analisa uma tabela MyISAM ou InnoDB, ele atualiza as estatísticas de índice. O otimizador usa essas estatísticas ao processar consultas para tomar melhores decisões sobre a melhor forma de procurar registros na tabela e na ordem em que ele precisa ler tabelas em um join.
  • Quando o MySQL Otimiza uma tabela MyISAM, ele desfragmenta o datafile para recuperar o espaço não utilizado, classifica os índices e atualiza as estatísticas de índice. Periódicamente a desfragmentação é necessária para acelerar o acesso as tabelas que contêm colunas de comprimento variável como VARCHAR, VARBINARY, BLOB, ou TEXT. Inserções e exclusões podem resultar em muitas lacunas em tais tabelas, particularmente aqueles que são modificados com freqüência. Desfragmentando elimina essas lacunas.
No próximo post vou falar detalhadamente das ferramentas, com exemplos e scripts de automação.

 

segunda-feira, 19 de julho de 2010

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 !




quarta-feira, 23 de junho de 2010

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!!

domingo, 13 de junho de 2010

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 !!

quarta-feira, 2 de junho de 2010

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......

domingo, 30 de maio de 2010

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.