Esta página mostra a documentação da versão 15.5.2 do AlloyDB Omni. Para conferir a documentação da versão mais recente do AlloyDB Omni, clique aqui.

Esta página foi traduzida pela API Cloud Translation.

Gerenciar e monitorar o AlloyDB Omni

Esta página descreve como gerenciar as funções de usuário do AlloyDB Omni, monitorar a atividade do servidor do AlloyDB Omni e atualizar ou remover a instalação do AlloyDB Omni.

Gerenciar funções do usuário

O AlloyDB Omni usa o mesmo conjunto de funções de usuário PostgreSQL predefinidas que o AlloyDB inclui, com as seguintes diferenças:

O AlloyDB Omni não tem um papel alloydbiamuser.
O AlloyDB Omni inclui uma função de superusuário chamada alloydbadmin.

Assim como no AlloyDB, é recomendável seguir estas etapas ao configurar um banco de dados:

Defina ou importe seus bancos de dados usando a função do usuário postgres. Em uma nova instalação, essa função tem privilégios de criação de banco de dados e de função, e não tem senha.
Crie novas funções de usuário com o nível de acesso correto às tabelas do seu aplicativo, usando novamente a função do usuário postgres.
Configure seu aplicativo para se conectar ao banco de dados usando essas novas funções de acesso limitado.

É possível criar e definir quantas funções de usuário novas forem necessárias. Não modifique nem exclua nenhuma das funções de usuário com que o AlloyDB Omni é enviado.

Para mais informações, consulte Gerenciar funções de usuário do AlloyDB.

Monitorar o AlloyDB Omni

Monitorar a instalação do AlloyDB Omni significa ler e analisar os arquivos de registro.

O AlloyDB Omni executado no Kubernetes também tem um conjunto de métricas básicas disponíveis como endpoints do Prometheus. Para uma lista de métricas disponíveis, consulte Métricas do AlloyDB Omni.

Servidor único

O AlloyDB Omni registra a atividade em dois locais:

O AlloyDB Omni registra a atividade do banco de dados em data/log/postgres, em relação ao diretório que você definiu no arquivo de configuração dataplane.conf.

É possível personalizar o nome e o formato desse arquivo de registro usando as várias diretivas log_* definidas em /var/alloydb/config/postgresql.conf. Para mais informações, consulte Relatórios e registros de erros.
O AlloyDB Omni registra a atividade de instalação, inicialização e desligamento em /var/alloydb/logs/alloydb.log.

Para verificar o status de execução imediato do servidor, consulte Verificar o status do AlloyDB Omni.

Kubernetes

Encontrar os arquivos de registro do cluster do banco de dados

Os arquivos postgresql.audit e postgresql.log podem ser encontrados no sistema de arquivos do pod do banco de dados. Para acessar esses arquivos, siga estas etapas:

Defina uma variável de ambiente que contenha o nome do pod do banco de dados.
```
export DB_POD=`kubectl get pod -l alloydbomni.internal.dbadmin.goog/dbcluster=DB_CLUSTER_NAME,alloydbomni.internal.dbadmin.goog/task-type=database -o jsonpath='{.items[0].metadata.name}'`
```
Substitua DB_CLUSTER_NAME pelo nome do cluster do banco de dados. É o mesmo nome do cluster de banco de dados que você declarou ao criar o cluster.
Execute um shell no pod do banco de dados como raiz.
```
kubectl exec ${DB_POD} -it -- /bin/bash
```
Encontre os arquivos de registro no diretório /obs/diagnostic/:
- /obs/diagnostic/postgresql.audit
- /obs/diagnostic/postgresql.log

Listar serviços de monitoramento

v1.0

Quando você cria um cluster de banco de dados, o AlloyDB Omni cria o seguinte serviço de monitoramento para cada instância CR do cluster de banco de dados no mesmo namespace:

al-INSTANCE_NAME-monitoring-system

Para listar os serviços de monitoramento, execute o seguinte comando.

kubectl get svc -n NAMESPACE | grep monitoring

Substitua NAMESPACE por um namespace ao qual o cluster pertence.

O exemplo de resposta a seguir mostra os serviços al-1060-dbc-monitoring-system, al-3de6-dbc-monitoring-system e al-4bc0-dbc-monitoring-system. Cada serviço corresponde a uma instância.

al-1060-dbc-monitoring-system   ClusterIP   10.0.15.227   <none>        9187/TCP   7d20h
al-3de6-dbc-monitoring-system   ClusterIP   10.0.5.205    <none>        9187/TCP   7d19h
al-4bc0-dbc-monitoring-system   ClusterIP   10.0.15.92    <none>        9187/TCP   7d19h

Versão < 1.0

Quando você cria um cluster de banco de dados, o AlloyDB Omni cria os seguintes serviços de monitoramento no mesmo namespace do cluster de banco de dados:

DB_CLUSTER-monitoring-db
DB_CLUSTER-monitoring-system

Para listar os serviços de monitoramento, execute o seguinte comando.

kubectl get svc -n NAMESPACE | grep monitoring

Substitua NAMESPACE por um namespace ao qual o cluster pertence.

O exemplo de resposta a seguir mostra o al-2953-dbcluster-foo7-monitoring-system e o serviço al-2953-dbcluster-foo7-monitoring-db.

al-2953-dbcluster-foo7-monitoring-db           ClusterIP   10.36.3.243    <none>        9187/TCP   44m
al-2953-dbcluster-foo7-monitoring-system       ClusterIP   10.36.7.72     <none>        9187/TCP   44m

Conferir as métricas do Prometheus na linha de comando

A porta 9187 é nomeada como metricsalloydbomni para todos os serviços de monitoramento.

Configure o encaminhamento de portas do seu ambiente local para o serviço de monitoramento.
```
kubectl port-forward service/MONITORING_SERVICE -n NAMESPACE MONITORING_METRICS_PORT:metricsalloydbomni
```
Substitua:
- MONITORING_SERVICE: o nome do serviço de monitoramento que você quer encaminhar. Por exemplo, al-1060-dbc-monitoring-system.
- NAMESPACE: o namespace ao qual o cluster pertence.
- MONITORING_METRICS_PORT: uma porta TCP disponível localmente.
A resposta a seguir mostra que os serviços estão sendo encaminhados.
```
Forwarding from 127.0.0.1:9187 -> 9187
Forwarding from [::1]:9187 -> 9187
```
Enquanto o comando anterior é executado, é possível acessar as métricas de monitoramento por HTTP na porta especificada. Por exemplo, você pode usar curl para conferir todas as métricas como texto simples:
```
curl http://localhost:MONITORING_METRICS_PORT/metrics
```

Conferir métricas usando a API Prometheus

A chave de rótulo alloydbomni.internal.dbadmin.goog/task-type e a porta metricsalloydbomni estão disponíveis como padrão para todos os serviços de monitoramento no AlloyDB Omni. Eles podem ser usados com um único recurso personalizado serviceMonitor para selecionar todos os serviços de todos os namespaces no cluster do banco de dados.

Para mais informações sobre o uso da API Prometheus, consulte a documentação do Operador Prometheus.

Confira a seguir um exemplo de campo spec do recurso personalizado serviceMonitor que inclui a chave de rótulo alloydbomni.internal.dbadmin.gdc.goog/task-type e a porta metricsalloydbomni. O recurso personalizado serviceMonitor monitora e coleta todos os serviços do Kubernetes em todos os namespaces.

Para mais informações sobre a definição completa de ServiceMonitor, consulte a definição de recurso personalizado ServiceMonitor .

v1.0

    spec:
      selector:
        matchLabels:
          alloydbomni.internal.dbadmin.goog/task-type: monitoring
      namespaceSelector:
        any: true
      endpoints:
        - port: metricsalloydbomni

Versão < 1.0

    spec:
      selector:
        matchExpressions:
        - key: alloydbomni.internal.dbadmin.gdc.goog/task-type
          operator: Exists
          values: []
      namespaceSelector:
        any: true
      endpoints:
      - port: metricsalloydbomni

Fazer upgrade do AlloyDB Omni

Servidor único

Estas instruções se aplicam apenas à versão 15.2.0 e mais recentes do AlloyDB Omni.

Antes de começar

Sua máquina precisa ter a versão 1.2 ou mais recente da CLI AlloyDB Omni instalada.

Faça upgrade

Para fazer upgrade da instalação do AlloyDB Omni, execute o seguinte comando:

sudo alloydb database-server upgrade

Kubernetes

As etapas para fazer upgrade do AlloyDB Omni no Kubernetes dependem da versão do AlloyDB Omni que você está executando e da versão para a qual você está fazendo upgrade.

Determinar os números de versão atuais

Para verificar a versão do AlloyDB Omni usada pelo cluster de banco de dados, execute este comando:

kubectl get dbclusters.alloydbomni.dbadmin.goog DB_CLUSTER_NAME -n NAMESPACE -o jsonpath='{.status.primary.currentDatabaseVersion}'

Substitua:

DB_CLUSTER_NAME: o nome do cluster de banco de dados. É o mesmo nome do cluster de banco de dados que você declarou ao criar o cluster.
NAMESPACE: o namespace do Kubernetes do cluster do banco de dados.

Se você estiver executando a versão 1.0.0 ou mais recente do operador AlloyDB Omni, esse comando imprimirá a versão do AlloyDB Omni em uso pelo cluster de banco de dados.

Para verificar a versão do operador AlloyDB Omni instalado no cluster do Kubernetes, execute este comando:

kubectl get dbclusters.alloydbomni.dbadmin.goog DB_CLUSTER_NAME -n NAMESPACE -o jsonpath='{.status.primary.currentControlPlaneAgentsVersion}'

Se você estiver executando a versão 1.0.0 ou mais recente do operador AlloyDB Omni, esse comando vai imprimir o número da versão do operador AlloyDB Omni executado no cluster do Kubernetes.

Se você estiver executando uma versão do AlloyDB Omni Operator anterior à 1.0.0, não será possível fazer um upgrade no local do cluster de banco de dados ou do AlloyDB Omni Operator. Em vez disso, siga as instruções em Upgrade de um operador AlloyDB Omni anterior à versão 1.0.0.

Caso contrário, continue para a próxima seção.

Determinar os números de versão de destino

Se você estiver executando uma versão do AlloyDB Omni Operator 1.0.0 ou mais recente, as próximas etapas dependerão da versão do AlloyDB Omni para a qual você quer fazer upgrade. Isso, por sua vez, exige o entendimento do número da versão do AlloyDB Omni.

O número da versão do AlloyDB Omni tem três partes:

O número da versão principal da compatibilidade com o PostgreSQL
O número da versão secundária da compatibilidade com o PostgreSQL
O número da versão do patch desta versão do AlloyDB Omni

Por exemplo, a versão 15.5.2 do AlloyDB Omni é a versão 2 do patch do AlloyDB Omni que oferece suporte à versão 15.5 do PostgreSQL.

Se você quiser fazer upgrade para uma versão do AlloyDB Omni compatível com uma versão mais recente do PostgreSQL, atualize o operador do AlloyDB Omni junto com o cluster de banco de dados. Cada conjunto de versões do AlloyDB Omni que oferece suporte a uma versão secundária específica do PostgreSQL tem seu próprio número de versão associado do AlloyDB Omni Operator, que pode ser encontrado nas notas da versão do AlloyDB Omni.

Se você quiser fazer upgrade apenas para uma versão mais recente do patch do AlloyDB Omni, poderá fazer upgrade apenas do cluster do banco de dados, sem precisar fazer upgrade do operador do AlloyDB Omni. Você pode pular para as instruções em Fazer upgrade do cluster do banco de dados.

Caso contrário, continue para a próxima seção.

Fazer upgrade do operador do AlloyDB Omni

Para fazer upgrade do operador AlloyDB Omni, faça o seguinte:

Defina as variáveis de ambiente necessárias:
```
export GCS_BUCKET=alloydb-omni-operator
export OPERATOR_VERSION=OPERATOR_VERSION
export HELM_PATH=$OPERATOR_VERSION/alloydbomni-operator-$OPERATOR_VERSION.tgz
```
Substitua OPERATOR_VERSION pela versão do operador do AlloyDB Omni para a qual você está fazendo upgrade, por exemplo, 1.1.0.

Faça o download da versão mais recente do operador AlloyDB Omni:

gcloud storage cp gs://$GCS_BUCKET/$HELM_PATH ./ --recursive
tar -xvzf alloydbomni-operator-${OPERATOR_VERSION}.tgz

Aplique as definições de recurso personalizado mais recentes do operador AlloyDB Omni:
```
kubectl apply -f alloydbomni-operator/crds
```

Faça upgrade do gráfico Helm do operador do AlloyDB Omni:

helm upgrade alloydbomni-operator alloydbomni-operator-${OPERATOR_VERSION}.tgz \
--namespace alloydb-omni-system \
--atomic \
--timeout 5m

Para acompanhar o upgrade do operador AlloyDB Omni fazendo upgrade do manifesto do Kubernetes e do cluster de banco de dados, siga as instruções na próxima seção imediatamente após concluir as etapas anteriores.

Fazer upgrade do cluster do banco de dados

Para fazer upgrade do cluster de banco de dados, atualize os seguintes campos na seção spec do manifesto que o define:

Defina databaseVersion como o número da versão completa do AlloyDB Omni para o qual você quer fazer upgrade desse cluster de banco de dados.
Se você também tiver atualizado o operador AlloyDB Omni, defina controlPlaneAgentsVersion como o número da versão completa do operador AlloyDB Omni que você atualizou.

Se você estiver fazendo upgrade apenas da versão do patch do AlloyDB Omni, por exemplo, atualizando databaseVersion de 15.5.1 para 15.5.2, essa etapa é tudo o que você precisa fazer.

Se você estiver fazendo upgrade da versão secundária da compatibilidade do PostgreSQL, por exemplo, atualizando databaseVersion de 15.4.1 para 15.5.2, também será necessário atualizar controlPlaneAgentsVersion. Nesse caso, siga as etapas adicionais listadas em Fazer upgrade do operador AlloyDB Omni.

Como exemplo, o trecho de manifesto a seguir define um cluster de banco de dados com a versão 15.5.2 do AlloyDB Omni Operator e a versão 1.0.0 do AlloyDB Omni Operator:

apiVersion: alloydbomni.dbadmin.goog/v1 
kind: DBCluster
metadata:
  name: dbcluster-sample
spec:
  databaseVersion: 15.5.2
  controlPlaneAgentsVersion: 1.0.0

Neste exemplo, para fazer upgrade do cluster de banco de dados para executar a versão 15.5.3 do AlloyDB Omni, mude databaseVersion: 15.5.2 para databaseVersion: 15.5.3.

Fazer upgrade de um operador AlloyDB Omni anterior à versão 1.0.0

Se você estiver executando uma versão do AlloyDB Omni Operator anterior à 1.0.0, o upgrade de uma instalação do AlloyDB Omni baseada no Kubernetes envolve desinstalar e reinstalar o AlloyDB Omni Operator após fazer backup dos dados. Siga estas etapas:

Liste todos os clusters de banco de dados:

kubectl get dbclusters.alloydbomni.dbadmin.goog --all-namespaces

Para cada cluster de banco de dados, use o comando pg_dumpall para exportar todos os dados.

Aviso: não pule esta etapa. Se você não exportar seus dados, a próxima etapa vai apagar os dados de forma irreversível.
Desinstale o operador do AlloyDB Omni. Isso inclui a exclusão de todos os clusters de banco de dados.
Reinstale o operador do AlloyDB Omni. Você pode usar os mesmos comandos usados para instalar a versão anterior do operador AlloyDB Omni, sem precisar especificar um novo número de versão.
Recrie os clusters de banco de dados. É possível adaptar os mesmos arquivos de manifesto usados na criação dos clusters de banco de dados. Talvez seja necessário atualizar os arquivos para refletir as mudanças na API que foram introduzidas na versão 1.0.0 do AlloyDB Omni Operator, como o atributo databaseVersion que substitui o atributo version mais antigo.
Use pg_restore ou o comando \i em psql para importar os dados exportados anteriormente nos clusters recriados.

Reverter um upgrade

Estas instruções se aplicam apenas à versão 15.2.1 a 15.5.2 do AlloyDB Omni. Elas não se aplicam a implantações baseadas em Kubernetes do AlloyDB Omni.

Para reverter o AlloyDB Omni à versão instalada anteriormente, execute este comando:

sudo alloydb database-server rollback

Desinstalar o AlloyDB Omni

Servidor único

Para desinstalar o AlloyDB Omni, execute o seguinte comando:

sudo alloydb database-server uninstall

O diretório de dados permanece no sistema de arquivos depois que você desinstala o AlloyDB Omni. É possível mover, arquivar ou excluir esse diretório, dependendo de como e se você quer preservar seus dados após a desinstalação do AlloyDB Omni.

Kubernetes

Excluir o cluster do banco de dados

Para excluir o cluster de banco de dados, defina isDeleted como true no manifesto. Você pode fazer isso com o comando a seguir.

kubectl patch dbclusters.alloydbomni.dbadmin.goog DB_CLUSTER_NAME -p '{"spec":{"isDeleted":true}}' --type=merge

Substitua DB_CLUSTER_NAME pelo nome do cluster do banco de dados. É o mesmo nome do cluster de banco de dados que você declarou ao criar o cluster.

Desinstalar o operador do AlloyDB Omni

Para desinstalar o operador do Kubernetes do AlloyDB Omni do cluster do Kubernetes, siga estas etapas:

Exclua todos os clusters de banco de dados:

for ns in $(kubectl get dbclusters.alloydbomni.dbadmin.goog --all-namespaces -o=jsonpath='{range .items[*]}{.metadata.namespace}{"\n"}{end}'); do
for cr in $(kubectl get dbclusters.alloydbomni.dbadmin.goog -n $ns -o=jsonpath='{range .items[*]}{.metadata.name}{"\n"}{end}'); do
kubectl patch dbclusters.alloydbomni.dbadmin.goog $cr -n $ns --type=merge -p '{"spec":{"isDeleted":true}}'
done
done

Aguarde o operador AlloyDB Omni Kubernetes excluir todos os clusters de banco de dados. Use o comando a seguir para verificar se há recursos de banco de dados:
```
kubectl get dbclusters.alloydbomni.dbadmin.goog --all-namespaces
```

Exclua outros recursos criados pelo operador AlloyDB Omni Kubernetes:

kubectl delete failovers.alloydbomni.dbadmin.goog --all --all-namespaces
kubectl delete restores.alloydbomni.dbadmin.goog --all --all-namespaces
kubectl delete switchovers.alloydbomni.dbadmin.goog --all --all-namespaces

Desinstale o operador AlloyDB Omni no Kubernetes:

helm uninstall alloydbomni-operator --namespace alloydb-omni-system

Limpe os segredos, as descrições de recursos personalizados e os namespaces relacionados ao operador AlloyDB Omni no Kubernetes:

kubectl delete certificate -n alloydb-omni-system --all
kubectl get secrets --all-namespaces -o custom-columns=NAMESPACE:.metadata.namespace,NAME:.metadata.name,ANNOTATION:.metadata.annotations.cert-manager\.io/issuer-name | grep -E 'alloydbomni|dbs-al' | awk '{print $1 " " $2}' | xargs -n 2 kubectl delete secret -n
kubectl delete crd -l alloydb-omni=true
kubectl delete ns alloydb-omni-system

Redimensionar o cluster de banco de dados baseado em Kubernetes

Para redimensionar a CPU, a memória ou o armazenamento do cluster de banco de dados baseado no Kubernetes, atualize o campo resources dos manifestos que definem o pod. O operador AlloyDB Omni aplica as novas especificações ao pod do banco de dados imediatamente.

Para mais informações sobre a sintaxe do manifesto do operador AlloyDB Omni, consulte Criar um cluster de banco de dados.

As restrições a seguir se aplicam à modificação dos recursos de um cluster de banco de dados em execução:

Só é possível aumentar o tamanho de um disco se o storageClass especificado oferecer suporte à expansão de volume.
Não é possível diminuir o tamanho de um disco.