XOOPS Brasil

 

Capítulo 14. Estendendo o MySQL

14.1. MySQL Internals

Este capítulo descreve várias coisas que você precisa saber ao trabalhar no código do MySQL. Se você planeja contribuir com o desenvolvimento do MySQL, quiser ter acesso ao código entre versões, ou apenas deseja acompanhar o desenvolvimento, siga as instruções em Seção 2.3.4, “Instalando pela árvore de fontes do desenvolvimento”. Se você está interessada nos MySQL internals, você também deve se inscrever na nossa lista de emails internals. Esta lista é relativamente de baixo tráfico. Para detalhes de como se inscrever, por favor veja Seção 1.7.1.1, “As Listas de Discussão do MySQL”. Todos os desenvolvedores na MySQL AB estão na lista internals e nós ajudamos outras pessoal que estão trabalhando no código MySQL. Esteja a vontade de utilizar esta tanto para perguntas sobre o código qunato para enviar patches com os auqis você gostaria de contribui no projeto MySQL!

14.1.1. Threads MySQL

O servidor MySQL cria as seguintes threads:

  • A thread da conexão TCP/IP trata todas as requisições de conexão e cria uma nova thread dedicada para tratar a autenticação e consulta SQL processada por cada conexão.

  • No Windows NT existe um thread que trata named pipe que fazem o mesmo trabalho que as threads da conexão TCP/IP em pedidos de conexão de named pipe.

  • A thread de sinal trata todos os sinais. Esta thread também trata normalmente de alarmes e chamadas process_alarm() para forçar um tempo limite em conexões que têm estado parados por um tempo grande.

  • Se o mysqld é compilado com -DUSE_ALARM_THREAD, uma thread dedicada que trata dos alarmes é criada. Ela só é utilizadas em alguns sistemas onde há problemas com sigwait() ou se deseja utilizar o código thr_alarm() em aplicações sem uma thread dedicada para tratar sianis.

  • Se é utilizada a opção --flush_time=#, uma thread dedicada é criada para descarregar todas as tabelas em um dado intervalo.

  • Cada conexão tem a sua própria thread.

  • Cada tabela diferente na qual é utilizada INSERT DELAYED tem sua própria thread.

  • Se você quiser utilizar --master-host, uma thread de replicação slave será iniciada para ler e aplicar atualizações do master.

mysqladmin processlist mostra apenas a thread da conexão, do INSERT DELAYED, e da replicação.

14.1.2. Pacotes de Teste do MySQL

Até pouco tempo, o nosso principal pacote de teste com cobertura total era baseado em dados proprietários de clientes e por esta razão não era disponível publicamente. A única parte disponível publicamente de nosso processo de teste consistia de um teste crash-me, um benchamrk Perl DBI/DBD encontrado no diretório sql-bench e testes variadaos localizadaos no diretório tests. A falta de um um pacote de teste padronizado disponível publicamente tem criado dificuldade para nosso utilizadores e para nossos desenvolvedores de fazer teste de regressão no código do MySQL. Para resolver este problema, nós criamos um novo sistema de teste que é incluído nas distribuições fonte e binária do Unix a partir da versão 3.23.29. Os testes podem ser executados no Unix ou no Windows usando um ambiente Cygwin. Eles não podem ser executados em um ambiente Windows nativo.

O conjunto de testes de atual não testa tudo no MySQL, mas deve pegar os bugs mais óbvios no código de processamento SQL, detalhes de SO/biblioteca, e é bem compleo em teste de replicações. Nosso objetivo eventual é ter os testes cobrindo 100% do código. Contibuições para o nosso pacote de teste são benvindas. Você pode desejar contribuir com testes que examinam a funcionalidade critica ao seu sistema, o que irá assegurar que todas as futuras versões do MySQL irão funcionar bem com suas aplicações.

14.1.2.1. Executando o Pacote de Testes do MySQL

O sistema de teste consiste de um interpretador de linguagem de teste (mysqltest), um script shell para executar todos os testes (mysql-test-run), os casos de teste atual escritos em uma linguagem de teste especial e seus resultados esperados. Para executar o pacote de teste em seu sistema depois de uma construção, digite make test ou mysql-test/mysql-test-run da raiz do fonte. Se você tiver uma distribuição binária instalada, digite cd para a raíz de instalação. (ex. /usr/local/mysql), e faça scripts/mysql-test-run. Todos os testes devem dar certo. Se não, você deve tentar encontrar o porque e relatar o problema se este é um bug n MySQL. Veja mais informações sobre isto na Seção 14.1.2.3, “Relatando Bugs no Pacote de Teste do MySQL”.

Se você tiver uma cópia de mysqld executando ná máquina onde você deseja executar o teste, você não tem de pará-lo, desde que não esteja usando as portas 9306 e 9307. Se uma destas portas forem tomadas, você deve editar mysql-test-run e alterar os valores da porta do master e/ou slave para uma disponível.

Você pode executar um cado de teste individual com mysql-test/mysql-test-run test_name.

Se um teste falhar, você de testar executando mysql-test-run com a opção --force para verificar se nenhum outro teste falhou.

14.1.2.2. Extendendo o Pacote de Teste do MySQL

Você pode utilizar a linguagem mysqltest para escrever o seu próprio caso de teste. Infelizmente nós ainda não escrevemos a documentação completa para ela. Você pode, no entanto, olhar os nosso casos de teste atuais e usá-los como um exemplo. O seguintes pontos devem ajudá-lo a começar:

  • Os teste estão localizados em mysql-test/t/*.test

  • Um caso de teste consiste de instruções terminadas em ; e é similar a entrada do cliente de linha de comando mysql. Uma instrução por padrão é uma consulta a ser enviada ao servidor MySQL, a menos que ele seja reconhecido como um comando insterno (ex. sleep).

  • Todas as consultas que produzem resultados¯ex., SELECT, SHOW, EXPLAIN, etc., devem ser precedidas com @/path/to/result/file. O arquivo deve conter os resultados esperados. Um modo fácil de gerar o arquivo resultante é executar mysqltest -r < t/test-case-name.test do diretório mysql-test, e então editar o arquivo resultante gerado e, se necessário, ajustá-los a saída esperada. Neste caso, tenha cuidado de não adicionar ou deletar quaisquer caracteres invisíveis - tenha certeza de apenas alterar o texto e/ou adicionar linhas deletadas. Se você tiver que inserir uma linha, esteja certo que os campos são separados com tabulação e que há uma tabulação no final. Você pode querer utilizar od -c para ter certeza que seu editor de texto não bagunçõu nada durante a edição. Nós, é claro, esperamos que você nunca tenha que editar a saída de mysqltest -r já que você só deverá fazê-lo quando encontra um bug.

  • Para estar consistente com a nossa configuração, você deve colocar seus arquivos de resultados no diretório mysql-test/r e o nomeie como test_name.result. Se o teste produzir mais de um resultado, você deve usar test_name.a.result, test_name.b.result, etc.

  • Se uma instrução retornar um erro, você eve espacificar na linha anterior a instrução com --error error-number. O número do erro pode ser uma lista de números de erros possíveis separados com ','.

  • Se você estiver escrevendo em teste de replicação, você deve coloca source include/master-slave.inc; na primeira linha do arquivo. Para trocar entre master e slave, utilize connection master; e connection slave;. se você precisar fazer alguma coisa em uma conexão alternativa, você pode fazer connection master1; para o master e connection slave1; para o slave.

  • Se você precisar fazer alguma coisa em um loop, você pode usar algo assim:

    let $1=1000;
    while ($1)
    {
    # do your queries here
    dec $1;
    }
    

  • Para 'dormir' entre consultas, use o comando sleep. Ele suporta frações de um segundo, assim você pode fazer sleep 1.3;, por exemplo, para dormir 1.3 segundos.

  • Para executar o slave com opções adicionais para o seu caso de teste, coloque-os na formato de linha de comando mysql-test/t/test_name-slave.opt. Para o master, coloque-os em mysql-test/t/test_name-master.opt.

  • Se você tiver uma questão sobre o pacote de testes, ou tiver um caso de teste para contribuir, envie um e-mail para lista de email ``internals'' do MySQL. Veja mais informações sobre isto na Seção 1.7.1.1, “As Listas de Discussão do MySQL”. Como a lista não aceita anexos, você deve utilizar o ftp para enviar os arquivos relevantes: ftp://support.mysql.com/pub/mysql/Incoming/

14.1.2.3. Relatando Bugs no Pacote de Teste do MySQL

Se a sua versão não passar no pacote de teste você deve fazer o seguinte:

  • Não envie um relatório de bug antes de ter feito tudo possível para encontrar o que esta errado! Quando o fizer, por favor, utilize o script mysqlbug assim podemoster informações sobre o seu sistema e a versão do MySQL. Veja mais informações sobre isto na Seção 1.7.1.3, “Como relatar erros ou problemas”.

  • Esteja certo de inluir a saída de mysql-test-run, assim como o conteúdoi de todos os arquivos .reject no diretório mysql-test/r.

  • Se um pacote de teste falhar, verifique se o teste também falha quando executado sozinho:

    cd mysql-test
    mysql-test-run --local test-name
    

    Se falhar, você deve configurar o MySQL com --with-debug e executar mysql-test-run com a opção --debug. Se into também falhar envie o arquivo de rastreamento var/tmp/master.trace para ftp://support.mysql.com/pub/mysql/secret assim nós podemos examiná-los. Por favor, se lembre de também incluir uma descrição completa do seu sistema, a versão do binário do mysqld e como você o compilou.

  • Tente também executar mysql-test-run com a opção --force para ver se há qualquer outro teste que tenha falhado.

  • Se você próprio compilou o MySQL, verifique nosso manual sobre como compilar o MySQL na sua platforma ou, de preferência, use um dos binários que nós compilamos para você no http://www.mysql.com/downloads/. Todos os seus binários padrões devem passar no pacote de teste!

  • Se você obter um erro, como Result length mismatch ou Result content mismatch, significa que a saída do teste não é igual a saída esperada. Este pode ser um bug no MySQL ou que o seu versão do mysqld produz resultados um pouco diferentes sobre certas circuntâncias.

    Resultado de testes que falharam são colocados em um arquivo com o mesmo nome base que o arquivo de resultado com a extensão .reject. Se o seu caso de teste está falhando, você deve fazer um diff nos dois arquivos. Se você não puder ver como els são diferentes, examine ambos com od -c e també verifique os seus tamanhos.

  • Se um teste falhar totalmente, você deve verificar os arquivos de log no diretório mysql-test/var/log para avisos sobre o que deu errado.

  • Se você tiver compilado o MySQL com depuração você pode tentar depurá-lo executando mysql-test-run com a opções --gdb e/ou --debug. Veja mais informações sobre isto na Seção E.1.2, “Criando Arquivos Trace (Rastreamento)”.

    Se você não tiver compilado o MySQL com depuração você deve, provavelmente, fazê-lo. Apenas especifique a opção --with-debug no configure! Veja mais informações sobre isto na Seção 2.3, “Instalando uma distribuição com fontes do MySQL”.