Rolling upgrade do Elasticsearch (minor 8.x ou 8.19 → 9.x)

Não é uma instalação: leva um cluster Elasticsearch em execução para uma nova versão sem interrupção, atualizando os nodes um a um (minor dentro da 8.x ou versão principal 8.19 → 9.x). Verificações prévias (versão, saúde, deprecation API, system feature migration), snapshot antes do upgrade, limitação do shard allocation a primaries e flush, atualização da versão e dos plugins em cada node, reabertura do allocation e espera pela saúde do cluster, atualização do Kibana e, se necessário, retorno a partir do snapshot são feitos passo a passo. Ao final, todos os nodes e o Kibana estão na versão de destino e o cluster fica green. Se você vai sair de uma 8.x anterior à 8.19 para a 9.x, aplique primeiro este guia com a opção 'dentro da mesma versão principal' para chegar à 8.19; se não houver repositório de snapshot, abra antes o guia de snapshot.

Topologia: Cluster existente com 3+ nodes (+ Kibana)

Cenários

• Dentro da mesma versão principal (ex.: 8.18 → 8.19, 9.1 → 9.2) — Dentro da mesma versão principal (8.18 → 8.19, 9.1 → 9.2): o repositório não muda, mas a verificação de deprecation é feita do mesmo jeito. Pular minors intermediárias é suportado.
• Versão principal: 8.19.x → 9.x — O cluster de origem deve ter sido atualizado antes para a 8.19.x (último patch). As verificações prévias incluem os passos do Upgrade Assistant / deprecation API e da system feature migration.

Antes de começar

• Todos os nodes estão na mesma versão: …. …Para migrar para a 9.x, a versão de origem deve ser 8.19.x (exceto 8.18 → 9.0); caso contrário, aplique antes este guia com a opção "Dentro da mesma versão principal" e vá para a 8.19.…A versão de destino … deve ser mais nova que a atual; pular versões minor intermediárias (8.17 → 8.19) é suportado.…
• Cluster green; nenhum shard relocating/initializing; ocupação de disco abaixo de 75% em todos os nodes (durante o upgrade os shards são reconstruídos).
• Os clientes da aplicação, Logstash, Beats/Elastic Agent e APM são compatíveis com a versão de destino. …Para a 9.x, as bibliotecas cliente precisam estar na versão 9.x (ou 8.x com cabeçalhos de compatibilidade); leia as breaking changes nas notas de versão.…
• O repositório de snapshot … está registrado e verificado, com espaço livre suficiente para o snapshot. Um node já atualizado não pode voltar à versão antiga; a única forma de retorno é este snapshot.
• Os servidores acessam artifacts.elastic.co (ou o mirror interno) e … está disponível no repositório.
• Janela de manutenção aprovada; durante o upgrade, a carga de escrita foi reduzida se possível (não obrigatório). …Todos os avisos críticos da tela Stack Management → Upgrade Assistant do Kibana foram resolvidos.…

Fases do guia

• Preparação — Criar o arquivo temporário de credenciais para acesso à API · Fazer backup da configuração · Listar os plugins existentes
• Verificações prévias — Verificar a versão e os papéis · Verificar a saúde do cluster · Fazer a verificação de deprecation (API do Upgrade Assistant) · Executar a system feature migration · Listar as versões de destino disponíveis
• Mudar o repositório para 9.x — Definir o repositório Elastic 9.x · Definir o repositório Elastic 9.x · Verificar a versão de destino
• Ponto de retorno: snapshot — Fazer o snapshot pré-upgrade · Ativar o ML upgrade mode
• Verificação — Confirmar que todos os nodes estão na versão de destino · Verificar se a configuração de allocation foi removida de forma permanente · Desativar o ML upgrade mode · Verificar se há erros nos logs
• Atualizar o Kibana — Parar o Kibana · Atualizar o Kibana para a versão … · Iniciar o Kibana e verificar o status
• Pós-instalação — Fazer o snapshot pós-upgrade · Apagar o arquivo temporário de credenciais
• Retorno (somente se o upgrade falhar) — Parar o serviço em todos os nodes · Instalar a versão antiga · Mover o diretório de dados e criar um diretório vazio · Gravar a configuração initial_master_nodes para o novo cluster · Iniciar os serviços · Definir a senha temporária do elastic …