Gerenciar funções de usuário
O AlloyDB Omni usa o mesmo conjunto de papéis de usuário predefinidos do PostgreSQL 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 superusuário chamada
alloydbadmin
.
Assim como no AlloyDB, é uma prática recomendada seguir estas etapas ao configurar um banco de dados:
Defina ou importe seus bancos de dados usando a função de 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 correto de acesso às tabelas do aplicativo, usando novamente a função de usuário
postgres
.Configure o aplicativo para se conectar ao banco de dados usando essas novas funções de acesso limitado.
Você pode criar e definir quantas funções de usuário forem necessárias. Não modifique nem exclua nenhuma das funções de usuário fornecidas com o AlloyDB Omni.
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 em execução 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 definido no arquivo de configuraçãodataplane.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 Error Reporting e Logging.O AlloyDB Omni registra a atividade de instalação, inicialização e encerramento 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 de banco de dados
Você pode encontrar os arquivos postgresql.audit
e postgresql.log
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 de banco de dados. É o mesmo nome de cluster de banco de dados que você declarou ao criá-lo.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
Ao criar um cluster de banco de dados, o AlloyDB Omni cria o seguinte serviço de monitoramento para cada CR de instância 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 a que seu 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
Ao criar 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 a que seu 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 métricas do Prometheus na linha de comando
A porta 9187
é chamada de 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 a que seu cluster pertence.MONITORING_METRICS_PORT
: uma porta TCP local disponível.
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, você pode acessar as métricas de monitoramento por HTTP na porta especificada. Por exemplo, use
curl
para ver todas as métricas como texto simples:curl http://localhost:MONITORING_METRICS_PORT/metrics
Ver 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. É possível usá-los com um único recurso personalizado ServiceMonitor
para selecionar todos os serviços de todos os namespaces no cluster de banco de dados.
Para mais informações sobre como usar a API Prometheus, consulte a documentação do operador do 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 ao AlloyDB Omni versão 15.2.0 e mais recentes.
Antes de começar
Sua máquina precisa ter a versão 1.2 ou mais recente da CLI do 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 está fazendo upgrade.
Determinar os números da versão atual
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 de cluster de banco de dados que você declarou ao criá-lo.NAMESPACE
: o namespace do Kubernetes do cluster de banco de dados.
Se você estiver executando a versão 1.0.0 ou mais recente do operador do AlloyDB Omni, esse comando vai imprimir a versão do AlloyDB Omni em uso pelo seu cluster de banco de dados.
Para verificar a versão do operador do AlloyDB Omni instalada 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 do AlloyDB Omni, esse comando vai imprimir o número da versão do operador do AlloyDB Omni em execução no cluster do Kubernetes.
Se você estiver executando uma versão do operador do AlloyDB Omni anterior a 1.0.0, não será possível fazer um upgrade local do cluster de banco de dados ou do operador do AlloyDB Omni. Em vez disso, siga as instruções em Fazer upgrade de um operador do 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 operador do AlloyDB Omni 1.0.0 ou mais recente, as próximas etapas vão depender da versão do AlloyDB Omni para a qual você quer fazer upgrade. Isso, por sua vez, exige 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 compatibilidade com PostgreSQL
- O número da versão secundária da compatibilidade com PostgreSQL
- O número da versão de patch desta versão do AlloyDB Omni
Por exemplo, a versão 15.5.2 do AlloyDB Omni é a versão de patch 2 do AlloyDB Omni que oferece suporte à versão 15.5 do PostgreSQL.
Se você quiser fazer upgrade para uma versão do AlloyDB Omni que seja compatível com uma versão mais recente do PostgreSQL, será necessário fazer upgrade do próprio operador do AlloyDB Omni, além do cluster de banco de dados. Cada conjunto de versões do AlloyDB Omni que oferecem suporte a uma versão secundária específica do PostgreSQL tem um número de versão do operador do AlloyDB Omni associado, que pode ser encontrado na nota da versão da versão do AlloyDB Omni.
Se você quiser fazer upgrade apenas para uma versão de patch mais recente do AlloyDB Omni, poderá fazer upgrade apenas do cluster de banco de dados, sem precisar fazer upgrade do próprio operador do AlloyDB Omni. Você pode pular para as instruções em Fazer upgrade do cluster de 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 do 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 do operador mais recente do 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 do AlloyDB Omni:
kubectl apply -f alloydbomni-operator/crds
Faça upgrade do gráfico do Helm do operador do AlloyDB Omni:
helm upgrade alloydbomni-operator alloydbomni-operator-${OPERATOR_VERSION}.tgz \ --namespace alloydb-omni-system \ --atomic \ --timeout 5m
Para concluir o upgrade do operador do AlloyDB Omni, atualize o manifesto do Kubernetes e o 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 de 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 deste cluster de banco de dados.Se você também atualizou o operador do AlloyDB Omni, defina
controlPlaneAgentsVersion
como o número da versão completa do operador do AlloyDB Omni que você atualizou.
Se você estiver fazendo upgrade apenas da versão de patch do AlloyDB Omni, por exemplo, atualizando databaseVersion
de 15.5.1
para 15.5.2
, esta etapa é tudo o que você precisa fazer.
Se você estiver fazendo upgrade da versão secundária da compatibilidade com o 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 extras listadas em Fazer upgrade do operador do AlloyDB Omni.
Por exemplo, o trecho de manifesto a seguir define um cluster de banco de dados
executando a versão 15.5.2
do operador do AlloyDB Omni, com a versão 1.0.0
do operador do AlloyDB Omni:
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 do AlloyDB Omni anterior à versão 1.0.0
Se você estiver executando uma versão do operador do AlloyDB Omni anterior à 1.0.0, a atualização de uma instalação do AlloyDB Omni baseada no Kubernetes envolve desinstalar e reinstalar o operador do AlloyDB Omni depois de fazer backup dos seus 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.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 do 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 ao criar os clusters de banco de dados. Talvez seja necessário atualizar os arquivos para refletir as mudanças na API que a versão 1.0.0 do operador do AlloyDB Omni introduziu, como o atributo
databaseVersion
substituindo o atributoversion
mais antigo.Use
pg_restore
ou o comando\i
empsql
para importar os dados exportados anteriormente para os clusters recriados.
Reverter um upgrade
Estas instruções se aplicam apenas às versões 15.2.1 a 15.5.2 do AlloyDB Omni. Elas não se aplicam a implantações do AlloyDB Omni baseadas no Kubernetes.
Para reverter o AlloyDB Omni para a 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. Você pode mover, arquivar ou excluir esse diretório, dependendo de como quer preservar seus dados depois de desinstalar o AlloyDB Omni.
Kubernetes
Excluir o cluster de banco de dados
Para excluir o cluster de banco de dados, defina isDeleted
como true
no manifesto dele.
Faça isso 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 de banco de dados. É o mesmo nome de cluster de banco de dados que você declarou ao criá-lo.
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 até que o operador do Kubernetes do AlloyDB Omni exclua todos os clusters de banco de dados. Use o comando a seguir para verificar se há recursos de banco de dados restantes:
kubectl get dbclusters.alloydbomni.dbadmin.goog --all-namespaces
Exclua outros recursos criados pelo operador do AlloyDB Omni no 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 do AlloyDB Omni no Kubernetes:
helm uninstall alloydbomni-operator --namespace alloydb-omni-system
Limpe os secrets, as descrições de recursos personalizados e os namespaces relacionados ao operador do Kubernetes do AlloyDB Omni:
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 no 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 do 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 do 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 for compatível com a expansão de volume. - Não é possível diminuir o tamanho de um disco.