Lock de alteração de schema (DDL) em produção Schema change lock (DDL / metadata lock)
ID da causa db-ddl-lock · Responsável principal Infraestrutura de banco de dados (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento)
Adicionar uma coluna ou um índice a uma tabela com o jogo no ar exige um lock por um instante, e só esse lock pode deixar esperando todas as requisições que usam a tabela.
Por quê Um hotfix adiciona coluna ou índice a uma tabela em produção → Efeito A alteração de schema espera uma transação longa aberta antes dela, e todas as requisições seguintes esperam a alteração de schema → Na tela Os recursos que usam essa tabela (inventário, correio etc.) param por inteiro e dão timeout
Aleatoriamente, de vez em quando, Logo após login ou manutenção
Responsável
Responsável principal Infraestrutura de banco de dados (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Combinar com a infraestrutura de banco de dados o horário dos hotfixes que alteram o schema, fazer primeiro o deploy de um código que funcione mesmo sem a coluna nova.
O que fazer (Equipe de infraestrutura)
Definir um limite curto de espera por lock e tentar de novo se falhar, executar quando não houver transações longas, usar ferramentas de alteração online, deixar tabelas grandes para a janela de manutenção.
No gráfico
Degrau a partir de um momento · Sessões esperando lock, latência das queries daquela tabela
Onde olhar
No MySQL, contar no SHOW PROCESSLIST as sessões com State Waiting for table metadata lock e achar a sessão que está bloqueando (blocking_pid) com sys.schema_table_lock_waits. No PostgreSQL, ver no pg_locks as requisições com granted em false e os AccessExclusiveLock, e achar a sessão que está bloqueando com pg_blocking_pids()
Confirma se
A partir do horário em que a alteração de schema começou, todas as queries que usam aquela tabela se acumulam esperando lock, e na frente da fila há uma transação não terminada ou o próprio comando de alteração de schema
Descarta se
Espera concentrada em linhas específicas, com as outras linhas da mesma tabela processadas normalmente: hot row (db-hot-row)
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Saiba mais
Ao alterar o schema, o MySQL segura por um instante um metadata lock, e o PostgreSQL, o lock de tabela mais forte. Mesmo que a alteração em si seja instantânea, se houver na frente uma transação que ainda não terminou, todas as requisições seguintes ficam esperando.
Fontes
Online DDL Performance and ConcurrencyMySQL Mesmo o DDL online precisa de um metadata lock exclusivo por um instante no final; se houver uma transação longa, ele espera, e o pedido de lock em espera bloqueia todas as transações seguintes
Server System VariablesMySQL lock_wait_timeout: limite de espera por metadata lock, padrão de 31.536.000 segundos (1 ano)