Início / dba / Perguntas / 16206
Accepted
Bruno Reis
Asked: 2012-04-08 10:56:47 +0800 CST

Como fazer com que a conexão MySQL 5.1 ignore kills?

  • 772

De acordo com o manual do MySQL 5.1, seção 13.7.6.4 Sintaxe KILL , quando você faz killuma conexão, um sinalizador de interrupção específico da thread é definido para a thread . O sinalizador será verificado de tempos em tempos, mesmo durante algumas consultas de execução longa, para que possa interromper a consulta.

Existe uma maneira de instruir um thread a não verificar o sinalizador de interrupção enquanto estiver dentro de algum tipo de seção crítica delimitada?

O que estou procurando é algo como:

BEGIN IGNORE_KILLS;
-- if this thread is killed here, it will simply ignore it
END IGNORE_KILLS;
-- here, the thread would be able to tell if someone tried to kill it previously

Supondo que não exista, ou que alguém possa me oferecer uma solução melhor para o meu problema, deixe-me explicar por que eu o desejaria.

Tenho uma aplicação que deve reagir a linhas que são inseridas em uma tabela, e esta deve ser escalável. Segundo o especialista em MySQL Baron Schwartz , não se deve ficar fazendo polling no banco de dados e ele propõe, como alternativa, usar SELECT SLEEP(...)/KILL.

O problema é que depois que a conexão em espera select sleep(...) for notificada (ao ser morta) que tem trabalho a fazer, gostaria de garantir que, durante o seu trabalho (o que chamei de seção crítica acima), ela não vai parar de fazer o que deve funcionar mesmo no caso de o thread assassino enlouquecer e matá-lo novamente.

mysql

2 respostas

  1. Best Answer

    talvez eu tenha resolvido meu problema...

    Eu estava com medo de que 2 threads assassinos diferentes pudessem: (1) show processlist, (2) escolher a mesma conexão para matar, (3) então ambos o fariam kill.

    A primeira morte desencadearia a execução de tudo o que eu quisesse, enquanto a segunda morte poderia explodir as coisas.

    A solução mais fácil e quase óbvia que eu perdi é olhar para o outro lado do problema: em vez de tornar o thread de trabalho unkillable , os threads assassinos devem cooperar: os threads assassinos fariam (1) select get_lock('killer_thread'), somente depois de adquirir o bloqueio seriam (2) show processlist, (3) killos fios escolhidos e por fim (4) select release_lock('killer_thread').

    • 2

  2. Presumo que você esteja se referindo a este artigo que Baron escreveu para o blog Engine Yard...

    Embora ele tenha fornecido algumas maneiras de reduzir o trabalho de implementar uma fila em um RDBMS, o verdadeiro argumento deste artigo é não fazer isso. Existem dezenas de produtos disponíveis projetados para serem filas, e os bancos de dados não são um deles. Isso vai te morder no futuro.

    • 1

relate perguntas