Capítulo 14. Estendendo o MySQL
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!
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”.
|