Início / dba / Perguntas / 331765
Accepted
Daniel Benzie
Asked: 2023-10-02 21:09:41 +0800 CST

Bloqueio/Isolamento - MariaDB

  • 772

No MariaDB, o nível de isolamento padrão é leitura repetível. Entendo que isso significa que quando abro uma transação não verei nenhuma gravação simultânea no banco de dados.

Também tenho uma situação em que preciso garantir que alterações simultâneas não sejam feitas nas linhas. Para isso posso adquirir um cadeado exclusivo. Minha pergunta é realmente sobre como os dois funcionam em conjunto.

Se eu adquirir o bloqueio dentro da minha transação de atualização, significa que é possível que eu abra a transação e seja bloqueado porque outro processo possui o bloqueio exclusivo, quando eu obtiver o bloqueio, alterações podem ter sido feitas na linha que eu não veria, mas poderia precisar estar ciente de.

Estou hesitante em alterar o nível de isolamento, pois este é um cenário específico.

No momento, decidi adquirir o bloqueio antes de iniciar minha transação de atualização, mas isso torna a liberação do bloqueio mais problemática, pois ele não seria liberado depois que minha transação fosse confirmada. Estou perdendo algo óbvio? Então basicamente eu abro uma transação SELECT FOR UPDATE. Em seguida, abra uma segunda transação para fazer a atualização.

Semi-relacionado: O que foi dito acima significa que o bloqueio otimista quando o nível da transação é de leitura repetível é algo impossível? O bloqueio otimista envolve a verificação de uma versão/timestamp para garantir que nenhuma outra transação o tenha modificado desde que foi lido inicialmente. Com leituras repetíveis, não teríamos visibilidade de outras transações até que nossa transação fosse concluída, o que vai contra o propósito. Ou significa apenas que devo adquirir bloqueios fora das transações?

mysql

2 respostas

  1. Quando abro uma transação, não vejo nenhuma gravação simultânea no banco de dados.

    Mas sua transação pode estar bloqueada.

    Quando há um bloqueio, uma de duas coisas acontece:

    • Um “impasse”. E uma das duas transações é encerrada. (Normalmente, a reação apropriada é executar novamente a transação eliminada.)
    • Um tempo limite. (Veja innodb_lock_wait_timeout.) Neste caso, a segunda transação a ser bloqueada irá parar até que a primeira libere algum bloqueio. Você não terá consciência disso e tudo ficará bem (embora com atraso).
    • Se o bloqueio durar mais do que essa configuração (o padrão é ridiculamente longo, 50 segundos), ele será eliminado.

    Certifique-se de usar FOR UPDATEem qualquer um SELECTsque busque dados que possam ser alterados posteriormente nessa transação. Isso permite que outros threads saibam que você não deseja que o valor seja alterado inesperadamente.

    Siga os conselhos acima e talvez você nunca precise alterar o nível de isolamento.

    "Bloqueio otimista" - O código é otimizado para COMMIT; ROLLBACKdá mais trabalho.

    “Leituras sujas” são mais rápidas do que “leituras repetíveis”, mas você perde a maior parte dos benefícios do ACID das transações.

    "adquirir bloqueios fora da transação" - Não é realmente possível. Você deve minimizar a quantidade de trabalho dentro de uma transação.

    • Nunca interaja com o usuário dentro de uma transação; você não tem controle sobre quanto tempo durará o intervalo para o café.
    • Se algo puder ser facilmente obtido em uma transação, faça-o.

    Independentemente de como você o expresse, tudo envolve uma transação. autocommit=ONsem BEGIN...COMMITfaz de cada declaração uma transação em si.

    Preciso garantir que alterações simultâneas não sejam feitas nas linhas. --

    BEGIN;
SELECT ... FOR UPDATE;
...
UPDATE/INSERT/...
COMMIT;

    Os bloqueios necessários serão retirados e honrados.

    No momento, decidi adquirir o bloqueio antes de iniciar uma transação

    • Isso é essencialmente impossível no InnoDB.
    • Não use a LOCKdeclaração; provavelmente não tem praticamente nenhum lugar nas tabelas do InnoDB.

    Observe como eu evitei que você insistisse em "bloqueios" e "níveis de isolamento".

    Outra maneira de ver isso...

    Quando você COMEÇA uma transação (e assumindo uma 'leitura repetível'), uma câmera gigante tira uma foto de todos os dados. Sua transação prossegue usando os dados da imagem. E até UPDATEingvalores na foto. Quando você COMMIT, todas as alterações feitas na imagem são instantaneamente copiadas para o disco para que outras pessoas possam ver.

    O que está faltando nessa visão simplista é se algum outro processo estiver tentando alterar os mesmos valores que você está atualizando. É aí que os “bloqueios” são comunicados entre os processos. Então as regras detalhadas (leitura compartilhada, exclusiva, etc.) entram em jogo. Isso leva à continuação, atraso ou bloqueio de um processo para resolver os bloqueios.

    A "câmera gigante" é implementada tendo um número de sequência (a la timestamp) conectado a cada valor em cada coluna de cada tabela.
    Quando BEGINacontece, o número de sequência é capturado; é usado para dizer "Consigo ver apenas os valores mais recentes antes desse número". Quando uma coluna é UPDATEd, existem [temporariamente] dois valores, cada um com um número de sequência diferente. Depois COMMIT, todas as cópias extras dos valores das colunas são limpas [em segundo plano]. (cf. "história")

    De volta ao "otimista" - observe como os novos valores estão preparados para serem armazenados permanentemente, enquanto ROLLBACKhá uma limpeza mais complicada a ser feita.

    Voltar para “leitura repetível” – Observe como a imagem gigante continua mostrando apenas um valor; portanto, o mesmo SELECTobterá os mesmos resultados, independentemente do que outros processos estejam tentando mudar.

    A "leitura suja" não se preocupa com a repetibilidade; portanto, pode evitar o bloqueio e correr mais rápido. "Serializable" não se preocupa com coisas transacionais, mas fica mais lento por não ser capaz de executar vários processos simultaneamente.

    Espero que esse visual simplista ajude. Isso me ajuda a entender a complexidade do InnoDB. Também espero que outros apontem quaisquer falhas importantes nele.

    • 1
  2. Best Answer

    Então basicamente eu abro uma transação SELECT FOR UPDATE. Em seguida, abra uma segunda transação para fazer a atualização.

    Você quer dizer uma segunda afirmação ?

    Se você estiver realmente iniciando uma segunda transação, os bloqueios adquiridos por você SELECT FOR UPDATEserão liberados. A START TRANSACTIONinstrução causa um commit implícito , que libera quaisquer bloqueios mantidos pela transação anterior.

    Normalmente você usaria SELECT FOR UPDATEpara adquirir alguns bloqueios quando estiver se preparando para UPDATEa mesma transação.

    Não é imediatamente óbvio, mas no InnoDB, as instruções de bloqueio (incluindo SELECT FOR UPDATEor SELECT FOR SHARE) sempre bloqueiam a versão confirmada mais recentemente de uma linha, como se você estivesse usando o nível de isolamento confirmado por leitura, mesmo que uma leitura sem bloqueio não possa visualizar isso versão dessa linha. Isso é surpreendente para algumas pessoas, mas ajuda porque evita algumas atualizações fantasmas.

    • 1

relate perguntas