[Bug] Cut-over may self-deadlock (Error 1205) behind Cloud Proxy / ProxySQL due to session-level lock visibility inconsistency

Aberta
  • Algo errado?
#1,659 1 comentário 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 10 dias

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
5/5
Tempo estimado
Mais de uma semana
Facilidade para iniciantes
42/100
Tipo de issue
Bug
Clareza
Razoavelmente clara
Status de atividade
Pouca atividade
Stack de tecnologia
go, mysql
Domínio
databases

Direção de pesquisa

Comece com a orquestração do lock de cut-over e o gerenciamento de sessões/conexões do gh-ost e, em seguida, reproduza Error 1205 por meio de um proxy ProxySQL-like ou cloud com tráfego zero. Defina e teste um modo opcional de cut-over de sessão única, verificando que o rename atômico seja concluído sem timeout enquanto o comportamento existente permanece inalterado.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

Environment

MySQL: 8.0+ (Cloud RDS: Tencent Cloud / Alibaba Cloud)
gh-ost: 1.0.49
Topology: MySQL accessed through cloud proxy / load balancer (e.g. ProxySQL-like architecture)
Description In a cloud-native deployment where MySQL is accessed via a proxy layer, gh-ost repeatedly fails during cut-over with:

Error 1205: Lock wait timeout exceeded

This occurs even under very low or zero application traffic, and with no observable long-running transactions.

Under the same zero-traffic conditions, a manual atomic RENAME TABLE old TO old_del, ghost TO old succeeds immediately.

Observed Behavior

gh-ost enters cut-over
lock orchestration retries/yields
eventually exits with lock wait timeout (1205)
Expected Behavior Cut-over should complete successfully under no-contention conditions, similar to the manual atomic RENAME TABLE.

Hypothesis / Possible Root Cause gh-ost cut-over uses multiple sessions (e.g. one session holding LOCK TABLES WRITE, another issuing RENAME TABLE).

When routed through a proxy, these sessions may not share lock state/ordering semantics exactly as expected (session split-brain / lock visibility inconsistency), causing the RENAME session to wait on locks effectively held by gh-ost’s own companion session.

This can look like a self-deadlock pattern and ends in timeout/yield.

Suggested Improvement Add an optional mode for proxy/cloud-RDS environments, e.g.:

--single-session-cut-over

that executes cut-over lock + atomic rename in a single session/connection, avoiding multi-session lock orchestration dependency.

Linguagem predominante
Go
Estrelas
13.6k
Forks
1.4k
Merge médio
9d 19h
PRs com merge (30d)
1

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de github/gh-ost

Todas as issues de github/gh-ost

Issues semelhantes

Mais issues de Go

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.