Faça a gestão e a monitorização do AlloyDB Omni

Selecione uma versão da documentação:

Esta página descreve como gerir as funções de utilizador do AlloyDB Omni, monitorizar a atividade do seu servidor AlloyDB Omni e atualizar ou remover a sua instalação do AlloyDB Omni.

Faça a gestão das funções de utilizador

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

  • O AlloyDB Omni não tem uma função alloydbiamuser.

  • O AlloyDB Omni inclui uma função de superutilizador denominada alloydbadmin.

Tal como no AlloyDB, é uma prática recomendada seguir estes passos quando configurar uma base de dados:

  1. Defina ou importe as suas bases de dados com a postgres função de utilizador. Numa nova instalação, esta função tem privilégios de criação de bases de dados e de funções, e não tem palavra-passe.

  2. Crie novas funções de utilizador com o nível de acesso correto às tabelas da sua aplicação, novamente através da função de utilizador postgres.

  3. Configure a sua aplicação para se ligar à base de dados através destas novas funções de acesso limitado.

Pode criar e definir todas as novas funções de utilizador de que precisar. Não modifique nem elimine nenhuma das funções de utilizador com as quais o AlloyDB Omni é fornecido.

Para mais informações, consulte o artigo Gerir funções de utilizador do AlloyDB.

Monitorize o AlloyDB Omni

A monitorização da instalação do AlloyDB Omni implica a leitura e a análise dos respetivos ficheiros de registo.

O AlloyDB Omni em execução no Kubernetes também tem um conjunto de métricas básicas disponíveis como pontos finais do Prometheus. Para ver uma lista das métricas disponíveis, consulte Métricas do AlloyDB Omni.

Servidor único

O AlloyDB Omni regista a sua atividade em duas localizações:

  • O AlloyDB Omni regista a atividade da base de dados em data/log/postgres, relativamente ao diretório que definiu no seu ficheiro de configuração dataplane.conf.

    Pode personalizar o nome e o formato deste ficheiro de registo através das várias diretivas log_* definidas em /var/alloydb/config/postgresql.conf. Para mais informações, consulte o artigo Relatórios de erros e registo.

  • O AlloyDB Omni regista a respetiva atividade de instalação, arranque e encerramento em /var/alloydb/logs/alloydb.log.

Para verificar o estado de execução imediato do seu servidor, consulte o artigo Verifique o estado do AlloyDB Omni.

Kubernetes

Encontre os ficheiros de registo do cluster da base de dados

Pode encontrar os ficheiros postgresql.audit e postgresql.log no sistema de ficheiros do pod da base de dados. Para aceder a estes ficheiros, siga estes passos:

  1. Defina uma variável de ambiente que contenha o nome do pod da base 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 da base de dados. É o mesmo nome do cluster da base de dados que declarou quando o criou.

  2. Execute um shell no pod da base de dados como raiz.

    kubectl exec ${DB_POD} -it -- /bin/bash
  3. Encontre os ficheiros de registo no diretório /obs/diagnostic/:

    • /obs/diagnostic/postgresql.audit
    • /obs/diagnostic/postgresql.log

Apresente serviços de monitorização

v1.0

Quando cria um cluster de base de dados, o AlloyDB Omni cria o seguinte serviço de monitorização para cada CR de instância do cluster de base de dados no mesmo espaço de nomes:

al-INSTANCE_NAME-monitoring-system

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

kubectl get svc -n NAMESPACE | grep monitoring

Substitua NAMESPACE por um espaço de nomes ao qual o seu cluster pertence.

A resposta de exemplo seguinte 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 cria um cluster de base de dados, o AlloyDB Omni cria os seguintes serviços de monitorização no mesmo espaço de nomes que o cluster de base de dados:

  • DB_CLUSTER-monitoring-db

  • DB_CLUSTER-monitoring-system

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

kubectl get svc -n NAMESPACE | grep monitoring

Substitua NAMESPACE por um espaço de nomes ao qual o seu cluster pertence.

A resposta de exemplo seguinte mostra o serviç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

Veja métricas do Prometheus a partir da linha de comandos

A porta 9187 é denominada metricsalloydbomni para todos os serviços de monitorização.

  1. Configure o encaminhamento de portas do seu ambiente local para o serviço de monitorização.

    kubectl port-forward service/MONITORING_SERVICE -n NAMESPACE MONITORING_METRICS_PORT:metricsalloydbomni
    

    Substitua o seguinte:

    • MONITORING_SERVICE: o nome do serviço de monitorização que quer encaminhar, por exemplo, al-1060-dbc-monitoring-system.

    • NAMESPACE: o espaço de nomes ao qual o cluster pertence.

    • MONITORING_METRICS_PORT: Uma porta TCP disponível local.

    A resposta seguinte mostra que os serviços estão a ser encaminhados.

    Forwarding from 127.0.0.1:9187 -> 9187
    Forwarding from [::1]:9187 -> 9187
    
  2. Enquanto o comando anterior é executado, pode aceder às métricas de monitorização através de HTTP na porta que especificou. Por exemplo, pode usar curl para ver todas as métricas como texto simples:

    curl http://localhost:MONITORING_METRICS_PORT/metrics
    

Veja métricas através da API Prometheus

A chave de etiqueta alloydbomni.internal.dbadmin.goog/task-type e a porta metricsalloydbomni estão disponíveis por predefinição para todos os serviços de monitorização no AlloyDB Omni. Pode usá-los em conjunto com um único recurso personalizado ServiceMonitor para selecionar todos os serviços para todos os espaços de nomes no cluster da base de dados.

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

Segue-se um exemplo do campo spec do recurso personalizado ServiceMonitor que inclui a chave da etiqueta alloydbomni.internal.dbadmin.gdc.goog/task-type e a porta metricsalloydbomni. O recurso personalizado ServiceMonitor monitoriza e recolhe todos os serviços do Kubernetes em todos os espaços de nomes

Para mais informações sobre a definição completa de ServiceMonitor, consulte a definição de recursos personalizados de 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

Atualize o AlloyDB Omni

Servidor único

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

Antes de começar

A sua máquina tem de ter a versão 1.2 ou posterior da CLI do AlloyDB Omni instalada.

Faça a atualização

Para atualizar a instalação do AlloyDB Omni, execute o seguinte comando:

sudo alloydb database-server upgrade

Kubernetes

Os passos que segue para atualizar o AlloyDB Omni no Kubernetes dependem da versão do AlloyDB Omni que está a executar e da versão para a qual está a fazer a atualização.

Determine os números da sua versão atual

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

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

Substitua o seguinte:

  • DB_CLUSTER_NAME: o nome do cluster da base de dados. É o mesmo nome do cluster da base de dados que declarou quando o criou.

  • NAMESPACE: o namespace do Kubernetes do cluster da base de dados.

Se estiver a executar a versão 1.0.0 ou posterior do AlloyDB Omni Operator, este comando imprime a versão do AlloyDB Omni em utilização pelo seu cluster de base de dados.

Para verificar a versão do AlloyDB Omni Operator instalada no seu cluster do Kubernetes, execute este comando:

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

Se estiver a executar a versão 1.0.0 ou posterior do AlloyDB Omni Operator, este comando imprime o número da versão do AlloyDB Omni Operator em execução no seu cluster do Kubernetes.

Se estiver a executar uma versão do AlloyDB Omni Operator anterior a 1.0.0, não pode fazer uma atualização no local do cluster de base de dados nem do AlloyDB Omni Operator. Em alternativa, tem de seguir as instruções em Atualize a partir de um AlloyDB Omni Operator anterior à versão 1.0.0.

Caso contrário, avance para a secção seguinte.

Determine os números das versões de destino

Se estiver a executar uma versão do AlloyDB Omni Operator 1.0.0 ou posterior, os passos seguintes dependem da versão do AlloyDB Omni para a qual quer fazer a atualização. Isto, por sua vez, requer a compreensão 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 respetiva compatibilidade com o PostgreSQL
  • O número da versão secundária da respetiva compatibilidade com o PostgreSQL
  • O número da versão do patch deste lançamento do AlloyDB Omni

Por exemplo, a versão 15.5.2 do AlloyDB Omni é a versão de patch 2 do AlloyDB Omni que suporta a versão 15.5 do PostgreSQL.

Se quiser atualizar para uma versão do AlloyDB Omni que suporte uma versão mais recente do PostgreSQL, tem de atualizar o próprio operador do AlloyDB Omni, juntamente com o cluster da base de dados. Cada conjunto de lançamentos do AlloyDB Omni que suporta uma versão secundária específica do PostgreSQL tem o seu próprio número de versão do operador do AlloyDB Omni associado, que pode encontrar na nota de lançamento da versão do AlloyDB Omni.

Se quiser atualizar apenas para uma versão de patch mais recente do AlloyDB Omni, pode atualizar apenas o cluster da base de dados, sem necessidade de atualizar o próprio operador do AlloyDB Omni. Pode avançar para as instruções em Atualize o cluster da base de dados.

Caso contrário, avance para a secção seguinte.

Atualize o operador do AlloyDB Omni

Para atualizar o AlloyDB Omni Operator, faça o seguinte:

  1. 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 AlloyDB Omni Operator para a qual está a fazer a atualização, por exemplo, 1.1.0.

  2. Transfira o operador do AlloyDB Omni mais recente:

    gcloud storage cp gs://$GCS_BUCKET/$HELM_PATH ./ --recursive
    tar -xvzf alloydbomni-operator-${OPERATOR_VERSION}.tgz
  3. Aplique as definições de recursos personalizados do AlloyDB Omni Operator mais recentes:

    kubectl apply -f alloydbomni-operator/crds
  4. Atualize o gráfico Helm do operador AlloyDB Omni:

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

Para dar seguimento à atualização do operador do AlloyDB Omni, atualize o manifesto do Kubernetes e o cluster da base de dados. Siga as instruções na secção seguinte imediatamente após concluir os passos anteriores.

Atualize o cluster da base de dados

Para atualizar o cluster da base de dados, atualize os seguintes campos na secção spec do manifesto que o define:

  • Defina databaseVersion para o número da versão completo do AlloyDB Omni para o qual quer atualizar este cluster de base de dados.

  • Se também atualizou o AlloyDB Omni Operator, defina controlPlaneAgentsVersion para o número da versão completa do AlloyDB Omni Operator que atualizou.

Se estiver a atualizar apenas a versão de patch do AlloyDB Omni, por exemplo, a atualizar de databaseVersion para 15.5.1, este passo é tudo o que tem de fazer.15.5.2

Se estiver a atualizar a versão secundária da compatibilidade com o PostgreSQL, por exemplo, a atualizar o databaseVersion de 15.4.1 para 15.5.2, também tem de atualizar o controlPlaneAgentsVersion. Nesse caso, certifique-se de que seguiu os passos adicionais indicados no artigo Atualize o operador do AlloyDB Omni.

Por exemplo, o excerto do manifesto seguinte define um cluster de base de dados com a versão 15.5.2 do AlloyDB Omni Operator, com 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 atualizar o cluster da base de dados para executar a versão do AlloyDB Omni 15.5.3, altere databaseVersion: 15.5.2 para databaseVersion: 15.5.3.

Atualize a partir de um AlloyDB Omni Operator anterior à versão 1.0.0

Se estiver a executar uma versão do AlloyDB Omni Operator anterior à 1.0.0, a atualização de uma instalação do AlloyDB Omni baseada no Kubernetes implica desinstalar e, em seguida, reinstalar o AlloyDB Omni Operator depois de fazer uma cópia de segurança dos seus dados. Siga estes passos:

  1. Liste todos os clusters de base de dados:

    kubectl get dbclusters.alloydbomni.dbadmin.goog --all-namespaces
  2. Para cada cluster de base de dados, use o comando pg_dumpall para exportar todos os respetivos dados.

  3. Desinstale o AlloyDB Omni Operator. Isto inclui a eliminação de todos os clusters da base de dados.

  4. Reinstale o operador AlloyDB Omni. Pode usar os mesmos comandos que usou para instalar a versão anterior do AlloyDB Omni Operator, sem necessidade de especificar um novo número de versão.

  5. Recrie os clusters da base de dados. Pode adaptar os mesmos ficheiros de manifesto que usou quando criou anteriormente os clusters da base de dados. Pode ter de atualizar os ficheiros para refletir as alterações da API que a versão 1.0.0 do AlloyDB Omni Operator introduziu, como o atributo databaseVersion que substitui o atributo version mais antigo.

  6. Use pg_restore ou o comando \i em psql para importar os dados exportados anteriormente para os clusters recriados.

Reverta uma atualização

Estas instruções aplicam-se apenas à versão 15.2.1 a 15.5.2 do AlloyDB Omni. Não se aplicam a implementações baseadas em Kubernetes do AlloyDB Omni.

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

sudo alloydb database-server rollback

Desinstale 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 seu sistema de ficheiros depois de desinstalar o AlloyDB Omni. Pode mover, arquivar ou eliminar este diretório, consoante pretenda ou não preservar os seus dados após a desinstalação do AlloyDB Omni.

Kubernetes

Elimine o cluster da base de dados

Para eliminar o cluster da base de dados, defina isDeleted como true no respetivo manifesto. Pode fazê-lo com o seguinte comando.

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

Substitua DB_CLUSTER_NAME pelo nome do cluster da base de dados. É o mesmo nome do cluster da base de dados que declarou quando o criou.

Desinstale o AlloyDB Omni Operator

Para desinstalar o operador do Kubernetes do AlloyDB Omni do seu cluster do Kubernetes, siga estes passos:

  1. Elimine todos os clusters de base 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
  2. Aguarde que o operador do Kubernetes do AlloyDB Omni elimine todos os clusters de base de dados. Use o seguinte comando para verificar se restam recursos da base de dados:

    kubectl get dbclusters.alloydbomni.dbadmin.goog --all-namespaces
  3. Elimine outros recursos que o operador do Kubernetes do AlloyDB Omni criou:

    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
  4. Desinstale o operador do Kubernetes do AlloyDB Omni:

    helm uninstall alloydbomni-operator --namespace alloydb-omni-system
  5. Limpe os segredos, as descrições de recursos personalizados e os espaços de nomes relacionados com o AlloyDB Omni Kubernetes Operator:

    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

Redimensione o cluster de base de dados baseado no Kubernetes

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

Para mais informações sobre a sintaxe do manifesto do operador AlloyDB Omni, consulte o artigo Crie um cluster de base de dados.

Aplicam-se as seguintes restrições à modificação dos recursos de um cluster de base de dados em execução:

  • Só pode aumentar o tamanho de um disco se o storageClass especificado suportar a expansão do volume.
  • Não pode diminuir o tamanho de um disco.