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:
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.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
.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çãodataplane.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:
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.Execute um shell no pod da base de dados como raiz.
kubectl exec ${DB_POD} -it -- /bin/bash
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.
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
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:
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
.Transfira o operador do AlloyDB Omni mais recente:
gcloud storage cp gs://$GCS_BUCKET/$HELM_PATH ./ --recursive
tar -xvzf alloydbomni-operator-${OPERATOR_VERSION}.tgz
Aplique as definições de recursos personalizados do AlloyDB Omni Operator mais recentes:
kubectl apply -f alloydbomni-operator/crds
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:
Liste todos os clusters de base de dados:
kubectl get dbclusters.alloydbomni.dbadmin.goog --all-namespaces
Para cada cluster de base de dados, use o comando
pg_dumpall
para exportar todos os respetivos dados.Desinstale o AlloyDB Omni Operator. Isto inclui a eliminação de todos os clusters da base de dados.
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.
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 atributoversion
mais antigo.Use
pg_restore
ou o comando\i
empsql
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:
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
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
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
Desinstale o operador do Kubernetes do AlloyDB Omni:
helm uninstall alloydbomni-operator --namespace alloydb-omni-system
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.