Skip to main content

Visualizando Extensões Instaladas

Consulte as extensões instaladas usando a view INFORMATION_SCHEMA:
Saída:
Uso:
  • Use tanto em sessões interativas quanto em scripts
  • Interface SQL padrão compatível com ferramentas do MySQL

Verificando Funções de Extensão

Verifique se as funções da extensão funcionam após a instalação:

Diretório de Extensões

Verifique onde o VillageSQL procura por arquivos .veb:
Liste as extensões disponíveis:

Configurando o veb_dir

Para alterar o local do diretório de extensões, defina veb_dir no seu arquivo de configuração do MySQL: my.cnf / my.ini:
Requisitos:
  • O caminho deve ser absoluto (não relativo)
  • O diretório deve existir antes da inicialização do servidor
  • O usuário do MySQL deve ter permissões de leitura no diretório
  • Apenas um veb_dir é compatível (não é possível ter múltiplos caminhos)
  • As alterações exigem a reinicialização do servidor para entrarem em vigor
Verifique após a reinicialização:

Solução de Problemas

Referência Rápida

Extensão Não Encontrada

Erro: Extension 'my_extension' not found Passos de depuração:

Função Indisponível Após a Instalação

Erro: FUNCTION my_func does not exist Passos de depuração:

A Extensão Apresenta Comportamento Antigo Após a Atualização

Sintoma: Após substituir um arquivo .veb e reinstalar, a extensão ainda executa o código antigo. Causa: O VillageSQL expande os arquivos .veb em {datadir}/.veb_expansion_cache/ no primeiro carregamento. Se você copiar um novo .veb sem antes executar UNINSTALL EXTENSION, o servidor continua usando o .so previamente expandido que já está carregado na memória. Solução: Sempre siga o ciclo completo UNINSTALL → substituir → INSTALL:
Em seguida, substitua o arquivo .veb em veb_dir e reinstale:
Se a extensão ainda apresentar comportamento antigo, limpe o cache de expansão antes de reinstalar:

Não é Possível Desinstalar a Extensão

Erro: Cannot uninstall extension: types in use Solução:

Erros de Carregamento de Biblioteca

Erro: Cannot load library: undefined symbol Causas:
  • Dependências de biblioteca ausentes
  • Incompatibilidade de ABI
  • Versão incorreta do MySQL
Depuração:

Erros de Validação de Nome de Extensão

Erro: Failed to load VEF extension 'extension_name' com a mensagem de log Extension name mismatch Causa: O nome da extensão em manifest.json não corresponde ao nome do arquivo VEB. Passos de depuração:
  1. Verifique se o nome do arquivo VEB corresponde ao manifest:
  2. Verifique o campo name em manifest.json:
Solução: Ambos os nomes devem ser idênticos, usando underscores (consulte Convenções de Nomenclatura de Extensões):
  • Nome do arquivo VEB: my_extension.veb
  • manifest.json: "name": "my_extension"
Erros comuns:
  • Usar hífens no manifest: "name": "my-extension"
  • O nome do arquivo VEB não corresponde: my-extension.veb vs "name": "my_extension"
Exemplo correto:

Erros de Comparação de Tipos Personalizados

Erro: Cannot compare types X and Y in = Causa: Ambos os lados da comparação são tipos personalizados, mas de tipos ou extensões diferentes.
Solução: Garanta que ambos os lados de uma comparação usem o mesmo tipo personalizado. Se você precisar comparar entre tipos, converta um dos lados explicitamente usando a função de conversão de tipo apropriada.
Erro: Unable to implicitly cast a non-custom type during compare with a custom type in = Causa: Um dos lados da comparação é uma coluna de tipo personalizado e o outro é um valor (literal ou coluna) que não pode ser convertido automaticamente para esse tipo.
Solução: Literais de string são convertidos automaticamente para o tipo personalizado usando a função de encode do tipo. Para outros tipos (inteiros, floats), use uma função de conversão explícita:

Monitorando o Uso de Extensões

Desempenho de Consultas

Acompanhe os tempos de execução de VDF usando o performance_schema:

Uso de Tipos Personalizados

Acompanhe quais tabelas usam tipos personalizados:

Atualizando Extensões

Para alterar uma extensão instalada para uma versão diferente, use ALTER EXTENSION. Ele valida a nova versão em relação aos seus dados existentes e aplica a alteração na próxima vez que o servidor for reiniciado. Uma desinstalação e reinstalação manuais continuam disponíveis como alternativa.

Alterando a Versão de uma Extensão

ALTER EXTENSION altera uma extensão instalada para uma versão diferente, aplicada na próxima reinicialização do servidor:
O VillageSQL resolve a versão de destino no disco e executa uma verificação prévia de compatibilidade antes de aceitar a alteração. O VEB de destino deve existir no diretório de extensões como <name>-<version>.veb (aqui, update_test-1.2.0.veb); um arquivo ausente é rejeitado:
A verificação prévia procura por incompatibilidades conhecidas que quebrariam os dados armazenados, por exemplo, uma alteração no comprimento persistido de um tipo personalizado:
Uma vez aceita, a alteração é aplicada na próxima reinicialização. Até lá, INFORMATION_SCHEMA.EXTENSIONS informa a versão atual junto com a versão de destino para a qual ela mudará:
INFORMATION_SCHEMA.EXTENSIONS informa uma alteração agendada em quatro colunas: Uma alteração agendada é rastreada por vez:
  • Cancele uma alteração agendada solicitando novamente a versão atual:
  • Solicitar a versão atual quando nada está agendado não faz nada:
  • Um destino diferente é recusado enquanto uma alteração está agendada, portanto, cancele a existente primeiro:
A cláusula AT RESTART aplica a alteração durante a próxima inicialização do servidor.

Após uma Reinicialização Bem-Sucedida

Na próxima reinicialização, a alteração pendente é aplicada: EXTENSION_VERSION torna-se a versão de destino e PENDING_VERSION é limpo. Para a alteração agendada acima (update_test 1.0.0 → pendente 1.2.0):
Quaisquer linhas de custom_columns e de parâmetros de stored procedures que referenciam a versão antiga são reescritas durante a mesma reinicialização, para que as tabelas e rotinas dependentes continuem funcionando sem migração manual.
A alteração é aplicada durante a reinicialização, não em uma conexão ativa, sendo que os valores acima são o estado pós-reinicialização.

Recuperando de uma Alteração de Versão Pendente na Inicialização

Uma alteração de versão agendada é aplicada durante a próxima inicialização do servidor. Se uma ação pendente não puder ser aplicada, o servidor pode falhar ao iniciar enquanto persiste suas decisões de atualização pendentes. Use --villagesql-skip-extension-updates quando um ALTER EXTENSION ... AT RESTART enfileirado estiver bloqueando a inicialização e você precisar do servidor no ar antes de poder limpá-lo. --villagesql-skip-extension-updates é uma flag de inicialização do mysqld. Quando definida, o servidor ignora o processamento de ações ALTER EXTENSION ... AT RESTART pendentes: cada extensão carrega em sua versão atualmente instalada, e sua ação pendente é mantida intacta no disco. A flag por si só não muda nada; ela apenas ignora a aplicação das ações pendentes naquela inicialização. Quando a flag está definida e pelo menos uma extensão tem uma ação pendente, o servidor registra um único aviso na inicialização informando quantas foram ignoradas:
1

Inicie o servidor com a flag

Em produção, passe-a como uma opção normal de linha de comando do mysqld ou adicione-a em [mysqld] no my.cnf:
No dev harness, passe-a com --:
Sinal de sucesso: o servidor inicia e o log de erros contém o aviso bypassing N pending extension update(s) mostrado acima.
2

Identifique as ações pendentes

Sinal de sucesso: o PENDING_VERSION de cada linha é o destino que você precisa limpar; PENDING_LAST_ERROR mostra por que falhou ao aplicar.
3

Limpe cada ação pendente

Para cada extensão retornada acima, solicite sua versão atual para cancelar a alteração enfileirada (o mecanismo de cancelamento descrito em Alterando a Versão de uma Extensão):
Sinal de sucesso: uma nota Cleared pending update for extension '<name>' (target matches current version '<current>') é retornada, e executar novamente a consulta anterior mostra que PENDING_VERSION é NULL.
4

Reinicie sem a flag

Reinicie o servidor normalmente, omitindo --villagesql-skip-extension-updates.Sinal de sucesso: o servidor inicia e o aviso bypassing N pending extension update(s) não aparece mais no log.

Processo de Atualização Manual

  1. Desinstale a versão atual:
  2. Substitua o arquivo .veb:
  3. Instale a nova versão:
  4. Verifique a atualização:
Segurança de Dados: Se as tabelas usarem tipos personalizados da extensão, você deve remover ou alterar essas tabelas antes de desinstalar. Faça backup dos seus dados primeiro.
Exemplo:

Limpeza

Remover Diretórios de Expansão Órfãos

O VillageSQL expande os arquivos .veb em {datadir}/.veb_expansion_cache/{name}/{sha256}/. Versões antigas se acumulam ao longo do tempo.
A reinicialização do servidor limpa automaticamente os diretórios de expansão órfãos.

Replicação

Tipos personalizados exigem o binlog no formato ROW. Os modos STATEMENT e MIXED não são compatíveis com tabelas com colunas de tipo personalizado. Operações de INSERT, UPDATE, DELETE e ALTER TABLE em colunas de tipo personalizado replicam corretamente no formato ROW. INSTALL EXTENSION não é replicado; cada servidor gerencia suas próprias extensões. Instale a extensão em cada réplica antes de a replicação começar, usando a mesma versão da origem. O servidor impõe a correspondência exata de versão; uma incompatibilidade de versão interrompe a replicação. Se uma réplica encontrar um tipo personalizado que não reconhece, a replicação para na instrução DDL, seja em CREATE TABLE ou ALTER TABLE, antes que qualquer DML dependente seja aplicado. Instale a versão correta da extensão e depois retome:
O mysqldump preserva os nomes de tipo personalizado totalmente qualificados na saída. As restaurações lógicas funcionam desde que a extensão esteja instalada no servidor de destino antes de importar o dump.
O comportamento com o plugin Clone, o XtraBackup e o InnoDB Cluster / Group Replication ainda não foi testado. Teste seu caminho de restauração antes de confiar nele em produção.

Usando Extensões com Docker

Ao executar o VillageSQL no Docker, monte um diretório local como veb_dir para poder adicionar arquivos .veb a partir do host sem recompilar o contêiner. Exemplo de Docker Compose:
Copie um arquivo .veb para ./extensions/ no host e depois instale via SQL:
Para verificar o diretório que o servidor em execução está usando:

Obtendo Ajuda

Se você encontrar problemas não abordados aqui:
  1. Verifique o Log de Erros: A maioria dos erros de extensão é registrada com detalhes
  2. Revise a Documentação da Extensão: Pode existir uma solução de problemas específica da extensão
  3. Pergunte no Discord: Entre no Discord do VillageSQL
  4. Registre um Issue: Reporte bugs no GitHub Issues

Próximos Passos

Referência do Sistema

Consulte tabelas e views do sistema

Desinstalando Extensões

Remova extensões com segurança

Arquitetura de Extensões

Entenda os detalhes internos