terça-feira, 2 de julho de 2013

Entenda seu servidor MySQL

Original post: http://anothermysqldba.blogspot.com/2013/07/understand-your-mysql-server.html

Achei que poderia ser útil para escrever algumas orientações para ajudar todos a compreender diferentes aspectos de sua servidor MySQL.

Estes dados foram recolhidos ao longo do tempo e eu farei o meu melhor para postos de referência. Em geral considera seus melhores fontes de informação para a lista:
Assim, para o propósito deste exemplo, vamos supor que você tenha acabado de assumir a responsabilidade por um servidor MySQL. Qual é a melhor maneira de reunir necessidade válida de saber informações ...

Você sabe a senha para o banco de dados? Se ele não estiver usando o mysql_config_editor (assim pre 5.6) você pode fazer um pouco de escavação para descobrir. Caso contrário, você tem de reiniciá-lo e forçar seu caminho para dentro Vamos supor que você não deseja reiniciá-lo. Se você tem que descobrir como utilizar - skip-grant-tables rever alguns posts anteriores com exemplos: http://anothermysqldba.blogspot.com/search/label/--skip-grant-tables

Então, primeiro colocado algum para procurar a senha. Isto também significa que se você fizer uma dessas pessoas pode encontrar a senha mais tarde.
  • descobrir se alguém usou a senha na linha de comando.
    • história | grep mysql
  • crontab-l
    • Se você ver os scripts de backup ou etc olhar para esses scripts para uma senha
  • localizar. my.cnf
  • . gato Bash_history | grep mysql
  • tentar mysql sem senha, mas, claro, a esperança é a sua caixa é seguro.
  • Com o MySQL 5.6 verificar se você tem uma conta configurada já
    • mysql_config_editor print - tudo
OK, então você tem as informações da conta e você está na caixa.
Antes de saltar para o servidor MySQL conhecer um pouco sobre o seu primeiro servidor.
Algumas dessas informações você pode apenas saber, mas para ser seguro.
Execute o seguinte em um sistema Linux, por exemplo, para obter o OS, Distro, Memória, as informações do disco.
  • cat / etc / *-release
  • uname-a
  • df-ah
  • montar
  • free-m
  • topo
  • Olhar sobre este post para informações Paginação http://www.mysqlplus.net/tag/swappiness/
  • Você tem um arquivo cnf específico que está sendo usado?
    • ps-ef | grep mysql | grep cnf
    • Datadir:
      • ps-ef | grep mysql | grep datadir

Então, agora saltar para o servidor MySQL e começar a recolher alguns dados. Enquanto uma revisão do arquivo my.cnf pode dar-lhe a maioria dessas informações você também pode recolhê-lo a partir do servidor.

show variables like '%log%';


Olhar sobre o seu erro (. Err) arquivo para rever todos os problemas. Este deve ser o primeiro lugar que você olha depois de um erro com o arranque e etc

Então, como é o servidor que está executando? Para reunir rapidamente o seguinte executar o comando status.
  • Versão
  • Threads
  • Perguntas
  • Consultas lentas
  • Abre
  • Tabelas de descarga
  • Mesas abertas
  • Consultas por segundo avg

mysql> status


O comando "mysqladmin extended-status" também pode dar-lhe informações para usar o grep com mas dentro do servidor também é válido.

Fique de olho nas informações a seguir.
Alguns destes também é postado aqui http://www.techrepublic.com/blog/opensource/10-mysql-variables-that-you-should-monitor/56

Você pode rever o post mencionado para ver uma bela tabela que explica alguns desses valores. Estes são os que eu acho que você deve ficar de olho no entanto.

> show status like 'Handler_read_first';
> show status like 'Key_reads';
> show status like 'Select_full_join';


Descubra a percentagem global de suas consultas são lento. Esperemos que este é um número pequeno.
Use as informações de status para preencher essas variáveis ​​para uma verificação rápida.

set @slow_queries=<value in the status output>;
set @questions=<value in the status output>;
SELECT ROUND(100* (@slow_queries / @questions),2) "Slow Query percentage" \G


Aprenda a entender a saída: Show de INNODB STATUS \ G
Fique de olho em informações impasse para que você possa começar a depurar aqueles.

O seu sistema tem gatilhos, eventos, procedimentos armazenados?

mysql> SELECT db, name FROM mysql.proc;
mysql> SELECT TRIGGER_SCHEMA , TRIGGER_NAME FROM information_schema.TRIGGERS ;
mysql> SELECT EVENT_NAME FROM information_schema.EVENTS ;


Conheça as suas variáveis ​​de servidor

show variables like '%innodb%';
show variables like '%thread%';
show variables like '%table%';
show variables like '%buffer%';
show variables like '%cache%';


Verifique suas contas de usuário.
Será que todos eles têm senhas válidas.

SELECT Host, User ,
CASE
WHEN CHARACTER_LENGTH(Password) = 16 THEN 'Pre-4.1 I should update this'
WHEN CHARACTER_LENGTH(Password) > 16 THEN 'Valid password'
WHEN CHARACTER_LENGTH(Password) =0 THEN ' BLANK PASSWORD so I just do not care if people steal my stuff'
END as Password
FROM mysql.user;


Entenda o seu arquivo de log InnoDB e descobrir um bom tampão tamanho da piscina.
Baron postou sobre isso aqui: http://www.mysqlperformanceblog.com/2008/11/21/how-to-calculate-a-good-innodb-log-file-size/
Leia o post para entender mais sobre isso. Abaixo está um exemplo de como usar essas informações também. I usou seus números para o exemplo para ajudar. Como disse Baron, execute este quando o tráfego é pesado para obter informações válidas.

mysql>pager grep sequence; show engine innodb status\G select sleep(60); show engine innodb status\G pager;
mysql>SET @sequence1= 3836410803;
mysql>SET @sequence2= 3838334638;
mysql>select ( ( (@sequence2 - @sequence1) / 1024 / 1024 )* 60 ) /2 as innodb_log_file_size_used ;
mysql>select (@@innodb_log_file_size / 1024) / 1024 as current_log_file_MB_size;


Tamanho do buffer de piscina.
Enquanto a consulta a seguir é postado em torno da rede e dá um ponto de partida válido para uma área de buffer, também tenho visto alguns números inválidos ou irrealista baseados no servidor que tinha. Pessoalmente, rever os resultados da consulta abaixo. Reveja os resultados de pico de tráfego e os dados de quantidade que você está enviando para os logs por post do Barão. Em seguida, levar em conta o quanto de memória você tem no servidor. Quanto mais o seu banco de dados é executado na memória, mais rápido é para obter resultados, mas você tem que levar em conta o que mais é o banco de dados fazendo. Então você tem que usar seu próprio julgamento e pesquisa para obter um bom valor para o tamanho do buffer. Outra opção seria usar o tools.percona.com , responda às perguntas e ver o que ele vos disser.


mysql>select ( ( (@sequence2 - @sequence1) / 1024 / 1024 )* 60 ) *2 as innodb_buffer_pool_GB_test ;

mysql>SELECT CONCAT(ROUND(KBS/POWER(1024,
IF(PowerOf1024<0,0,IF(PowerOf1024>3,0,PowerOf1024)))+0.49999),
SUBSTR(' KMG',IF(PowerOf1024<0,0,
IF(PowerOf1024>3,0,PowerOf1024))+1,1)) recommended_innodb_buffer_pool_size
FROM (SELECT SUM(data_length+index_length) KBS FROM information_schema.tables
WHERE engine='InnoDB') A,
(SELECT 3 PowerOf1024) B \G



Em seguida, você deve rever esta arca blog aberto a cavar em seus índices e etc muito mais. Muita informação sobre esse post e local em geral.
http://code.openark.org/blog/mysql/useful-database-analysis-queries-with-information_schema


Para cavar mais dados sobre o servidor ....


Quais são os quadros mais antigos, talvez necessidade de arquivo desses?

SELECT CONCAT(`TABLE_SCHEMA`, "." , `TABLE_NAME`) as name , `UPDATE_TIME`
FROM information_schema.TABLES
WHERE TABLE_SCHEMA NOT IN ('information_schema','mysql','test','performance_schema') AND `UPDATE_TIME` IS NOT NULL ORDER BY `UPDATE_TIME` LIMIT 25;



O que está tomando mais espaço?

SELECT concat(table_schema,'.',table_name) table_name,
concat(round(data_length/(1024*1024),2),'M') data_length
FROM information_schema.TABLES
ORDER BY data_length DESC LIMIT 5;


Este é apenas um ponto de partida para que você possa entender o que está acontecendo com o seu servidor. Use os sites listados neste site para saber mais.