Collecter des informations de débogage
Ces sections expliquent comment collecter des journaux et des configurations pour le débogage.
Récupérer les journaux des pods de l'opérateur
Pour extraire les journaux des pods de l'opérateur, exécutez les commandes suivantes :
kubectl logs deployments/fleet-controller-manager -c manager -n alloydb-omni-system
kubectl logs deployments/local-controller-manager -c manager -n alloydb-omni-system
Récupérer les journaux des pods de base de données
Pour extraire les journaux du pod de base de données, exécutez les commandes suivantes :
kubectl logs al-<id-instance-name>-0 -n db
kubectl logs -l alloydbomni.internal.dbadmin.goog/dbcluster=dbcluster-name -c database -n db
Les journaux suivants sont des exemples de vérifications de l'état de la base de données réussies :
I1106 16:17:28.826188 30 gateway.go:166] "DatabaseHealthCheck: handling request" log_name="agent" project_ns="dbc-bugbash" dbcluster="dbcluster-sample"
I1106 16:17:28.826295 30 gateway.go:184] "DatabaseHealthCheck: request handled successfully" log_name="agent" project_ns="dbc-bugbash" dbcluster="dbcluster-s
ample"
I1106 16:17:34.810447 30 gateway.go:166] "DatabaseHealthCheck: handling request" log_name="agent" project_ns="dbc-bugbash" dbcluster="dbcluster-sample"
I1106 16:17:34.834844 30 gateway.go:184] "DatabaseHealthCheck: request handled successfully" log_name="agent" project_ns="dbc-bugbash" dbcluster="dbcluster-s
ample"
I1106 16:17:38.825843 30 gateway.go:166] "DatabaseHealthCheck: handling request" log_name="agent" project_ns="dbc-bugbash" dbcluster="dbcluster-sample"
I1106 16:17:38.825959 30 gateway.go:184] "DatabaseHealthCheck: request handled successfully" log_name="agent" project_ns="dbc-bugbash" dbcluster="dbcluster-s
ample"
Récupérer le fichier postgresql.log
Pour récupérer le postgresql.log, exécutez la commande suivante :
kubectl exec -it al-id-instance-name-0 -n db -c database -- cat /obs/diagnostic/postgresql.log
Récupérer le fichier YAML DBInstance
Pour extraire le fichier YAML DBInstance, exécutez la commande suivante :
kubectl get dbclusters.a <dbcluster-name> -n db -o yaml
Récupérer les configurations et les journaux pour les scénarios de haute disponibilité
Pour récupérer les configurations et les journaux spécifiques aux scénarios de haute disponibilité (HA), exécutez les commandes suivantes :
kubectl get replicationconfig -n <namespace>
kubectl get deletestandbyjobs.alloydbomni.internal -n <namespace> -o yaml
kubectl get createstandbyjobs.alloydbomni.internal -n <namespace> -o yaml
kubectl get failovers.alloydbomni.dbadmin.goog -n <namespace> -o yaml
Récupérer l'état des pods et du STS
Pour récupérer l'état des pods et des StatefulSets (STS), exécutez les commandes suivantes :
kubectl describe pod -n <namespace> <pod-name>
kubectl describe statefulset -n <namespace> al-<id-instance-name>
Identifier les erreurs
Ces sections expliquent comment identifier les erreurs.
Recherchez l'état et les codes d'erreur.
Pour identifier le code d'erreur, consultez le fichier YAML DBCluster sous l'état. Pour en savoir plus, consultez la documentation sur les codes d'erreur.
Pour extraire le fichier YAML DBCluster, exécutez la commande suivante :
kubectl get dbclusters.a <dbcluster-name> -n <dbcluster-namespace> -o yaml
Recherchez criticalIncidents. Cette section contient le code d'erreur et une trace de pile.
Voici quelques exemples de criticalIncidents :
status:
certificateReference:
certificateKey: ca.crt
secretRef:
name: dbs-al-cert-dr-mce
namespace: dr
conditions:
- lastTransitionTime: "2024-10-07T22:46:03Z"
...
criticalIncidents:
- code: DBSE0304
createTime: "2024-10-03T11:50:54Z"
message: 'Healthcheck: Health check invalid result.'
resource:
component: healthcheck
location:
group: alloydbomni.internal.dbadmin.goog
kind: Instance
name: bc0f-dr-mce
namespace: dr
version: v1
stackTrace:
- component: healthcheck
message: 'DBSE0304: Healthcheck: Health check invalid result. rpc error: code
= Code(10304) desc = DBSE0304: Healthcheck: Health check invalid result.
dbdaemon/healthCheck: invalid timestamp read back from the healthcheck table.
Lag is 384837.296269 seconds, wanted 35 seconds'
Vous pouvez également récupérer l'état en extrayant des champs spécifiques au format JSON :
kubectl get dbcluster.${DBTYPE:?} -n "${PROJECT:?}" "${DBCLUSTER:?}" -o json -o jsonpath='{.status.criticalIncidents}' | jq
Le résultat ressemble à ce qui suit :
[
{
"code": "DBSE0085",
"createTime": "2024-03-14T05:41:37Z",
"message": "Platform: Pod is unschedulable.",
"resource": {
"component": "provisioning",
"location": {
"group": "alloydb.internal.dbadmin.goog",
"kind": "Instance",
"name": "b55f-testdbcluster",
"namespace": "dbs-system",
"version": "v1"
}
},
"stackTrace": [
{
"component": "provisioning",
"message": "DBSE0085: Platform: Pod is unschedulable. 0/16 nodes are available: pod has unbound immediate PersistentVolumeClaims. preemption: 0/16 nodes are available: 16 No preemption victims found for incoming pod..: Pod is unschedulable"
}
]
}
]
Si le message d'erreur fait référence au pod de base de données, vérifiez les instances et les ressources de pod dans le même espace de noms :
kubectl get instances.a dbcluster_name -n dbcluster_namespace -o yaml
kubectl get pods -l alloydbomni.internal.dbadmin.goog/dbcluster=dbcluster_name -l alloydbomni.internal.dbadmin.goog/task-type=database -n dbcluster_namespace
Déboguer les problèmes de mémoire
Ces sections décrivent comment déboguer les problèmes de mémoire.
Exécuter et effectuer un vidage du tas
N'activez cette fonctionnalité que pour résoudre des problèmes. N'oubliez pas de le désactiver ensuite.
Pour effectuer un vidage du tas, procédez comme suit :
- Modifiez le déploiement de l'opérateur sous l'espace de noms
alloydb-omni-systemavec les nomsfleet-controller-manageretlocal-controller-manager. - Ajoutez l'argument suivant au
--pprof-address=:8642du pod ou à tout autre port disponible. - Attendez que le pod du contrôleur redémarre.
Transférez le port précédent. Exemple :
kubectl port-forward -n alloydb-omni-system fleet-controller-manager-pod-name 8642:8642Dans un autre terminal, exécutez
go tool pprof http://localhost:8642/debug/pprof/heap. Si vous n'utilisez pas8642, modifiez le port pour qu'il corresponde au port précédent.Connectez-vous à l'adresse et exécutez les commandes de dépannage. Exemple :
top.Une fois le dépannage terminé, annulez l'étape 1 en supprimant l'argument et en attendant le redémarrage du pod.
Déterminer le nombre de ressources que l'opérateur surveille
Pour comprendre les ressources utilisées, exécutez les commandes suivantes :
kubectl get backuprepositories -A | wc -l
kubectl get failovers -A | wc -l
kubectl get instancebackupplans -A | wc -l
kubectl get instancebackups -A | wc -l
kubectl get instancerestores -A | wc -l
kubectl get instances -A | wc -l
kubectl get instanceswitchovers -A | wc -l
kubectl get lrojobs -A | wc -l
kubectl get replicationconfigs -A | wc -l
kubectl get sidecars -A | wc -l
kubectl get deployments -A | wc -l
kubectl get statefulsets -A | wc -l
kubectl get certificates.cert-manager.io -A | wc -l
kubectl get issuers.cert-manager.io -A | wc -l
kubectl get configmaps -A | wc -l
kubectl get persistentvolumeclaims -A | wc -l
kubectl get persistentvolumes -A | wc -l
kubectl get pods -A | wc -l
kubectl get secrets -A | wc -l
kubectl get services -A | wc -l
kubectl get storageclasses.storage.k8s.io -A | wc -l
Par exemple, si le nombre de secrets est élevé, cela peut entraîner une erreur de mémoire insuffisante (OOM).
kubectl get secrets -A | wc -l
Débogage avancé de la haute disponibilité
Cette section fait référence à des ressources qui sont des implémentations internes. Elles peuvent être modifiées à tout moment et ne sont pas rétrocompatibles. N'appliquez des corrections manuelles qu'aux problèmes liés aux bases de données hors production. Cette procédure peut rendre la base de données irrécupérable.
La configuration de la haute disponibilité AlloyDB Omni comporte trois phases :
- Configurez l'instance principale pour qu'elle reçoive une connexion de l'instance de secours.
- Initialisez l'instance de secours et connectez-la à l'instance principale.
- Définissez les paramètres principaux pour rendre la connexion synchrone.
L'étape 2 est généralement la plus lente. Selon la taille de la base de données, cela peut prendre plusieurs heures.
Chaque instance de réplication doit être associée à un replicationconfig. Exemple : bash
❯ k get replicationconfigs.alloydbomni.internal.dbadmin.goog
NAME PARENT TYPE ROLE READY HEALTHY
9f47-dbcluster-sample--7576-dbcluster-sample 9f47-dbcluster-sample Physical Upstream True True
ds-7576-dbcluster-sample 7576-dbcluster-sample Physical Downstream True True.
Dans cet exemple :
- L'instance
9f47-dbcluster-sampleest configurée en tant qu'upstream physique. - L'instance
7576-dbcluster-sampleest configurée en tant que serveur physique en aval.
La spécification de la configuration de la réplication indique les paramètres prévus, tandis que l'état reflète l'état réel tel qu'il est lu dans la base de données. En cas d'incohérence entre la spécification et l'état, le contrôleur tente toujours d'appliquer la modification ou une erreur empêche l'application de la modification. Cela se reflétera dans les champs d'état.
Tâches en veille
Deux ensembles de jobs internes doivent suivre le workflow d'une instance de secours :
createstandbyjobs.alloydbomni.internal.dbadmin.googdeletestandbyjobs.alloydbomni.internal.dbadmin.goog
Si la configuration semble bloquée, consultez les tâches liées au cluster de base de données (DBC). La tâche peut contenir des messages d'erreur expliquant l'état de la configuration. Les jobs sont automatiquement nettoyés quelque temps après leur fin. Il est donc possible que vous n'en voyiez aucun si aucun n'est en cours.
k get createstandbyjob
Le résultat ressemble à ce qui suit :
apiVersion: alloydbomni.dbadmin.gdc.goog/v1
kind: CreateStandbyJob
metadata:
creationTimestamp: "2024-11-05T03:34:26Z"
finalizers:
- createstandbyjob.dbadmin.goog/finalizer
generation: 1804
labels:
dbs.internal.dbadmin.goog/dbc: foo-ha-alloydb1-clone1
name: foo-ha-alloydb1-clone1--ac00-foo-ha-alloydb1-clone1--6036-foo-ha-alloydb1-clone1-1730777666
namespace: db
resourceVersion: "11819071"
uid: 1f24cedf-b326-422f-9405-c96c8720cd90
spec:
attempt: 3
cleanup: false
currentStep: SetupSynchronous
currentStepTime: "2024-11-05T03:45:31Z"
metadata:
dbc: foo-ha-alloydb1-clone1
primaryInstance: ac00-foo-ha-alloydb1-clone1
retryError: 'etcdserver: leader changed'
standbyInstance: 6036-foo-ha-alloydb1-clone1
requeueTime: "2024-11-05T18:33:03Z"
startTime: "2024-11-05T03:36:56Z"
Validation principale
La première chose à vérifier est que l'instance principale est correctement configurée. Il doit exister un profil de réplication pour chaque serveur de secours. Si isSynchronous est défini sur "true" dans la spécification et l'état, la configuration doit être terminée. Si isSynchronous est défini sur "false" dans la spécification et l'état, cela signifie que l'étape 3 n'a pas encore été atteinte. Affichez les jobs en veille pour voir s'il y en a en cours d'exécution et s'ils comportent des messages d'erreur.
replication:
profiles:
- isActive: true
isSynchronous: true
name: ha:4c82-dbcluster-sample::d85d-dbcluster-sample
password:
name: ha-rep-pw-dbcluster-sample
namespace: default
passwordResourceVersion: "896080"
role: Upstream
type: Physical
username: alloydbreplica
Vérifiez que l'annotation disableHealthcheck est définie sur "false". Il ne doit être désactivé que lors d'un basculement ou d'une commutation.
apiVersion: alloydbomni.internal.dbadmin.goog/v1
kind: Instance
metadata:
annotations:
dbs.internal.dbadmin.goog/consecutiveHealthcheckFailures: "0"
dbs.internal.dbadmin.goog/disableHealthcheck: "false"
dr-secondary: "false"
forceReconcile: "1730414498"
Requêtes
Pour vérifier que les ressources du pod de base de données sont correctement configurées, connectez-vous à la base de données en tant qu'utilisateur administrateur alloydbadmin. Exécutez ensuite les requêtes suivantes :
Emplacement de réplication
alloydbadmin=# select * from pg_replication_slots;
-[ RECORD 1 ]-------+---------------------------------------------
slot_name | d85d_dbcluster_sample
plugin |
slot_type | physical
datoid |
database |
temporary | f
active | t
active_pid | 250
xmin | 16318
catalog_xmin |
restart_lsn | 0/CA657F0
confirmed_flush_lsn |
wal_status | reserved
safe_wal_size |
two_phase | f
Un état correct correspond à la présence d'un emplacement de réplication portant le même nom que l'instance de secours. L'absence d'emplacement de réplication indique que la première étape de configuration n'a pas été effectuée correctement.
Si active == t n'est pas vrai, cela signifie que le standby ne se connecte pas pour une raison quelconque (réseau, configuration du standby non terminée, etc.). Le débogage devra probablement se poursuivre du côté du standby.
Statistiques de réplication
alloydbadmin=# select * from pg_stat_replication;
-[ RECORD 1 ]----+----------------------------------------------------------------
pid | 250
usesysid | 16385
usename | alloydbreplica
application_name | d85d_dbcluster_sample
client_addr | 10.54.79.196
client_hostname | gke-samwise-default-pool-afaf152d-8197.us-central1-a.c.foo
client_port | 24914
backend_start | 2024-10-30 21:44:26.408261+00
backend_xmin |
state | streaming
sent_lsn | 0/CA64DA8
write_lsn | 0/CA64DA8
flush_lsn | 0/CA64DA8
replay_lsn | 0/CA64DA8
write_lag |
flush_lag |
replay_lag |
sync_priority | 2
sync_state | sync
reply_time | 2024-11-04 22:08:04.370838+00
Si elle n'existe pas, cela signifie qu'aucune connexion n'est active. sync_state doit être défini sur sync. Si ce n'est pas le cas, cela signifie que la dernière étape de la configuration n'a pas été effectuée.sync Consulter les journaux / jobs devrait fournir plus de détails.
Validation de secours
L'instance de secours doit avoir un profil de réplication identique à celui de l'instance principale :
replication:
profiles:
- host: 10.54.79.210
isActive: true
isSynchronous: true
name: ha:4c82-dbcluster-sample::d85d-dbcluster-sample
passwordResourceVersion: "896080"
port: 5432
role: Downstream
type: Physical
username: alloydbreplica
Si aucune connexion n'est établie entre l'instance de secours et l'instance principale, deux possibilités courantes peuvent se présenter :
- La configuration de la veille est toujours en cours.
- Le standby rencontre une erreur lors de la configuration ou de la tentative de connexion.
Pour vérifier si l'option 1 est en cours, récupérez les journaux de pod de la base de données et recherchez les instructions de journal nommées dbdaemon/setupPhysicalReplicationDownstream. Voici des exemples de journaux de configuration réussie :
I1104 22:42:42.604871 103 replication.go:107] "dbdaemon/setupPhysicalReplicationDownstream: begin setup" log_name="agent" project_ns="default" dbcluster="dbcluster-sample"
2024-11-04 22:42:42,605 INFO waiting for postgres to stop
2024-11-04 22:42:43,566 INFO stopped: postgres (exit status 0)
I1104 22:42:43.567590 103 replication.go:131] "dbdaemon/setupPhysicalReplicationDownstream: about to call pg_basebackup" log_name="agent" project_ns="default" dbcluster="dbcluster-sample" cmd=["-h","10.54.79.210","-D","/mnt/disks/pgsql/pg_basebackup_data","-U","alloydbreplica","-v","-P","-p","5432","-w","-c","fast"]
I1104 22:42:44.206403 103 replication.go:139] "dbdaemon/setupPhysicalReplicationDownstream: pg_basebackup finished" log_name="agent" project_ns="default" dbcluster="dbcluster-sample"
I1104 22:42:44.206440 103 replication.go:141] "dbdaemon/setupPhysicalReplicationDownstream: replacing data directory with pg_basebackup data directory" log_name="agent" project_ns="default" dbcluster="dbcluster-sample"
I1104 22:42:44.244749 103 replication.go:148] "dbdaemon/setupPhysicalReplicationDownstream: replaced data directory with pg_basebackup data directory" log_name="agent" project_ns="default" dbcluster="dbcluster-sample"
I1104 22:42:44.244783 103 replication.go:150] "dbdaemon/setupPhysicalReplicationDownstream: Creating config files" log_name="agent" project_ns="default" dbcluster="dbcluster-sample"
I1104 22:42:44.251565 103 replication.go:155] "dbdaemon/setupPhysicalReplicationDownstream: removing postgresql config file for log archiving" log_name="agent" project_ns="default" dbcluster="dbcluster-sample"
I1104 22:42:44.251621 103 replication.go:160] "dbdaemon/setupPhysicalReplicationDownstream: removing postgresql auto config file" log_name="agent" project_ns="default" dbcluster="dbcluster-sample"
I1104 22:42:44.251689 103 replication.go:165] "dbdaemon/setupPhysicalReplicationDownstream: Successfully wrote to config file" log_name="agent" project_ns="default" dbcluster="dbcluster-sample"
2024-11-04 22:42:44,256 INFO spawned: 'postgres' with pid 271
2024-11-04 22:42:45,469 INFO success: postgres entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
I1104 22:42:45.469838 103 replication.go:174] "dbdaemon/setupPhysicalReplicationDownstream: backup replication configuration after changing replication config" log_name="agent" project_ns="default" dbcluster="dbcluster-sample"
I1104 22:42:45.476732 103 replication.go:179] "dbdaemon/setupPhysicalReplicationDownstream: finished standby setup" log_name="agent" project_ns="default" dbcluster="dbcluster-sample"
En cas d'erreur de connexion, consultez les journaux du pod de base de données ainsi que le fichier journal de la base de données à l'adresse /obs/diagnostic/postgresql.log pour identifier l'erreur lors de la tentative de connexion. Une erreur fréquente est l'absence de connectivité réseau entre le nœud de secours et le nœud principal.
Corrections manuelles
Le moyen le plus simple de résoudre les problèmes de haute disponibilité consiste à désactiver puis à réactiver la haute disponibilité en définissant numberOfStandbys sur 0, puis en le réinitialisant sur le nombre de votre choix. Si les serveurs de secours sont bloqués et désactivés, procédez comme suit pour réinitialiser manuellement la configuration HA et la vider :
- Supprimez manuellement les instances de secours.
Connectez-vous à la base de données principale. Interrogez les emplacements de réplication actuels et supprimez ceux des standby que vous souhaitez supprimer :
select pg_drop_replication_slot('<replication_slot_name_here>');Supprimez tous les profils de réplication de l'instance principale que vous souhaitez supprimer.
Si une instance n'a pas été réconciliée récemment, vous pouvez modifier la valeur de l'annotation forceReconcile. Définissez-le sur n'importe quelle valeur numérique, qui correspond au code temporel de la dernière mise à jour de l'annotation. La seule finalité de cette annotation est de fournir un champ que nous pouvons mettre à jour pour forcer une nouvelle réconciliation.
apiVersion: alloydbomni.internal.dbadmin.goog/v1
kind: Instance
metadata:
annotations:
dbs.internal.dbadmin.goog/consecutiveHealthcheckFailures: "0"
dbs.internal.dbadmin.goog/disableHealthcheck: "false"
dr-secondary: "false"
forceReconcile: "1730414498"
Collecter les journaux du moteur de base de données et les journaux d'audit
Les journaux du moteur de base de données et les journaux d'audit sont disponibles sous forme de fichiers dans le pod de base de données (accès root requis) :
obs/diagnostic/postgresql.logobs/diagnostic/postgresql.audit
export NAMESPACE=dbcluster-namespace
export DBCLUSTER=dbcluster-sample
export DBPOD=`kubectl get pod -n ${NAMESPACE} -l alloydbomni.internal.dbadmin.goog/dbcluster=${DBCLUSTER} -l alloydbomni.internal.dbadmin.goog/task-type=database -o jsonpath='{.items[0].metadata.name}'`
kubectl exec -n ${NAMESPACE} ${DBPOD} -it -- /bin/bash
$ ls -la /obs/diagnostic/
-rw------- 1 postgres postgres 98438 Sep 25 20:15 postgresql.audit
-rw------- 1 postgres postgres 21405058 Sep 25 20:24 postgresql.log
Collecter les métriques de la base de données et du pod de base de données
L'opérateur AlloyDB Omni fournit un ensemble de métriques de base pour le moteur AlloyDB Omni et le pod qui l'héberge. Les métriques sont disponibles en tant que points de terminaison Prometheus sur le port 9187. Pour accéder aux points de terminaison, vous devez identifier les noms de pods pour le pod de base de données et le pod de surveillance de base de données, en utilisant les libellés DBCluster et task-type comme suit.
export NAMESPACE=default
export DBCLUSTER=dbcluster-sample
export DBPOD=`kubectl get pod -n ${NAMESPACE} -l alloydbomni.internal.dbadmin.goog/dbcluster=${DBCLUSTER},alloydbomni.internal.dbadmin.gdc.goog/task-type=database -o jsonpath='{.items[0].metadata.name}'`
export MONITORINGPOD=`kubectl get pod -n ${NAMESPACE} -l alloydbomni.internal.dbadmin.goog/dbcluster=${DBCLUSTER},alloydbomni.internal.dbadmin.gdc.goog/task-type=monitoring -o jsonpath='{.items[0].metadata.name}'`
Accéder aux métriques de base de données AlloyDB Omni
kubectl port-forward -n ${NAMESPACE} ${MONITORINGPOD} 9187:9187
curl http://localhost:9187/metrics | grep HELP
Accéder aux métriques des pods de base de données
kubectl port-forward -n ${NAMESPACE} ${DBPOD} 9187:9187
curl http://localhost:9187/metrics | grep HELP
Vous pouvez également configurer Prometheus pour extraire les métriques de votre cluster Kubernetes. Pour en savoir plus, consultez la configuration de la détection de services Kubernetes pour Prometheus.