Auf dieser Seite wird die AlloyDB Omni-Version 18.1.0 mit der Bereitstellungsoption RPM-Orchestrator dokumentiert. Wählen Sie eine andere Bereitstellungsoption aus.

Google verwendet KI-Technologie, um Inhalte in Ihre bevorzugte Sprache zu übersetzen. KI-Übersetzungen können Fehler enthalten.

Cluster erstellen

Wählen Sie eine Dokumentationsversion aus:

Erstellen Sie einen Datenbankcluster, um AlloyDB Omni zu verwenden.

Beschränkungen

Es gelten folgende Einschränkungen:

AlloyDB Omni wird auf Port 5432 ausgeführt. Das Konfigurieren eines benutzerdefinierten Ports wird nicht unterstützt.
Achten Sie darauf, dass alle Konfigurationen der Datenbankparameter korrekt sind, bevor Sie den Cluster erstellen. Nachdem der Cluster erstellt wurde, können Sie keine Datenbankparameter mehr ändern.

Hinweis

Führen Sie vor dem Erstellen des Clusters die folgenden Schritte aus:

AlloyDB Omni-Orchestrator installieren
AlloyDB Omni-Komponenten installieren
TLS-Zertifikate konfigurieren
Stellen Sie ein externes Volume (DataDisk) für PG_DATA_DIR auf allen Datenbankknoten bereit, die im Orchestrator bereitgestellt wurden.
Wenn Sie alloydbctl anstelle von Ansible verwenden möchten, muss das erforderliche Paket policycoreutils-python-utils auf allen VMs installiert sein. Führen Sie den folgenden Befehl aus, um dieses Paket zu installieren:
```
sudo dnf install policycoreutils-python-utils
```
Wenn Sie die Google Cloud Umgebung verwenden, legen Sie ENVIRONMENT_TYPE auf gcp fest. Anschließend müssen Sie Ihr gcloud CLI-Konto authentifizieren, indem Sie gcloud auth login als root-Nutzer ausführen. Außerdem muss das authentifizierte Konto die folgenden Berechtigungen haben:
- compute.instances.get
- compute.instances.list
- compute.instances.updateNetworkInterface

Clusterspezifikationen vorbereiten

Damit der Cluster erstellt werden kann, muss AlloyDB Omni wissen, wie er konfiguriert werden soll. Erstellen Sie eine YAML-Datei im Format DBCluster, um die erforderlichen Spezifikationen zu erstellen:

Secret:
  metadata:
    name: db-pw-DBCLUSTER_NAME
  spec:
    type: Opaque
    data:
      DBCLUSTER_NAME: BASE64_PASSWORD
---
DBCluster:
  metadata:
    name: DBCLUSTER_NAME
  spec:
    databaseVersion: 18.1.0
    mode: ""
    availability:
      numberOfStandbys: NUM_STANDBY_NODES
      enableAutoFailover: true
      enableAutoHeal: true
      autoFailoverTriggerThreshold: AUTOFAILOVER_TRIGGER_THRESHOLD
      autoHealTriggerThreshold: AUTOHEAL_TRIGGER_THRESHOLD
      healthcheckPeriodSeconds: HEALTHCHECK_PERIOD
      replayReplicationSlotsOnStandbys: false
    primarySpec:
      adminUser:
        passwordRef:
          name: db-pw-DBCLUSTER_NAME
      resources:
        cpu: CPU_LIMIT
        memory: MEMORY_LIMIT
        disks:
        - name: DataDisk
          path: PG_DATA_DIR
      parameters:
        max_connections: "MAX_CONNECTIONS"
        max_wal_size: "MAX_WAL_SIZE"
        max_worker_processes: "MAX_WORKER_PROCESSES"
        log_connections: "LOG_CONNECTIONS"
        log_disconnections: "LOG_DISCONNECTS"
        log_hostname: "LOG_HOSTNAME"
        log_statement: "LOG_STATEMENT"
        huge_pages: "HUGE_PAGES"
        tcp_keepalives_idle: "TCP_KEEPALIVES_IDLE"
        tcp_keepalives_interval: "TCP_KEEPALIVES_INTERVAL"
        tcp_keepalives_count: "TCP_KEEPALIVES_COUNT"
      dbLoadBalancerOptions:
        DB_LOAD_BALANCER_TYPE:
          loadBalancerIP: "VIRTUAL_IP"
          loadBalancerType: "internal"
          loadBalancerInterface: "VIRTUAL_IP_INTERFACE"

Ersetzen Sie die folgenden Variablen:

DBCLUSTER_NAME: Name des Datenbankclusters. Beispiel: my-dbcluster.
BASE64_PASSWORD: base64-codiertes Passwort für den Administratornutzer postgres.
NUM_STANDBY_NODES: Anzahl der Standby-Knoten im Cluster. Beispiel: 2.
(Optional) AUTOFAILOVER_TRIGGER_THRESHOLD: Anzahl der Male, die die Systemdiagnose fehlschlagen kann, bevor ein Failover ausgeführt wird. Der Standardwert ist 3. Der Mindestwert ist 0. Wenn der Wert jedoch auf 0 gesetzt ist, verwendet AlloyDB Omni den Standardwert.

Ein automatisches Failover wird ausgeführt, wenn die Systemdiagnose AUTOFAILOVER_TRIGGER_THRESHOLD -mal fehlschlägt oder wenn die kumulative Dauer der Systemdiagnose HEALTHCHECK_PERIOD * AUTOFAILOVER_TRIGGER_THRESHOLD Sekunden erreicht.
(Optional) AUTOHEAL_TRIGGER_THRESHOLD: Anzahl der Male, die die Systemdiagnose fehlschlagen kann, bevor die automatische Reparatur beginnt. Der Standardwert ist 3. Der Mindestwert ist 0. Wenn der Wert jedoch auf 0 gesetzt ist, verwendet AlloyDB Omni den Standardwert.

Eine automatische Wiederherstellung wird ausgeführt, wenn die Systemdiagnose AUTOHEAL_TRIGGER_THRESHOLD -mal fehlschlägt oder wenn die kumulative Dauer der Systemdiagnose HEALTHCHECK_PERIOD * AUTOHEAL_TRIGGER_THRESHOLD Sekunden erreicht.
(Optional) HEALTHCHECK_PERIOD: Anzahl der Sekunden, die zwischen den einzelnen Systemdiagnosen gewartet werden soll. Der Standardwert ist 30. Der Mindestwert ist 1. Der Höchstwert ist 86400 (ein Tag).
CPU_LIMIT: Anzahl der CPUs, die dem Datenbankcontainer zugewiesen werden sollen. Beispiel: 4.
MEMORY_LIMIT: Menge an Arbeitsspeicher, die dem Datenbankcontainer zugewiesen werden soll. Beispiel: 32Gi, 500Mi.
PG_DATA_DIR: Hostpfad zum Verzeichnis, in dem die Datenbankdaten gespeichert werden.
(Optional) MAX_CONNECTIONS: maximale Anzahl gleichzeitiger Verbindungen zur PostgreSQL-Datenbank. Der Standardwert ist 50. Der unterstützte Mindestwert ist ebenfalls 50. Weitere Informationen finden Sie in der PostgreSQL max_connections Referenz.
(Optional) MAX_WAL_SIZE: maximale Größe, auf die das Write-Ahead-Log (WAL) während automatischer Prüfpunkte wachsen darf. Der Standardwert ist 1GB. Weitere Informationen finden Sie in der PostgreSQL-Referenzmax_wal_size.
MAX_WORKER_PROCESSES: maximale Anzahl von Worker-Prozessen, die von einem einzelnen Gather oder Gather Merge gestartet werden können. Der Standardwert ist 64. Weitere Informationen finden Sie in der PostgreSQL-max_worker_processesReferenz.
(Optional) LOG_CONNECTIONS: bestimmt, ob Verbindungen zu Ihrem PostgreSQL-Server protokolliert werden. Der Standardwert ist on. Weitere Informationen finden Sie in der PostgreSQL-log_connectionsReferenz.
(Optional) LOG_DISCONNECTS: bestimmt, ob PostgreSQL-Sitzungsbeendigungen protokolliert werden. Der Standardwert ist on. Weitere Informationen finden Sie in der PostgreSQL log_disconnections Referenz.
(Optional) LOG_HOSTNAME: bestimmt, ob zusätzlich zur IP-Adresse des verbindenden Hosts auch der Hostname protokolliert wird. Der Standardwert ist on. Weitere Informationen finden Sie unter der PostgreSQL-log_hostnameReferenz.
(Optional) LOG_STATEMENT: bestimmt, welche SQL-Anweisungen protokolliert werden. Der Standardwert ist none. Weitere Informationen finden Sie in der PostgreSQL log_statement Referenz.
(Optional) HUGE_PAGES: bestimmt, ob für den Hauptbereich des gemeinsamen Arbeitsspeichers Huge Pages angefordert werden. Der Standardwert ist off. Weitere Informationen finden Sie in der PostgreSQL-huge_pagesReferenz.
(Optional) TCP_KEEPALIVES_IDLE: Zeit in Sekunden ohne Netzwerkaktivität, bevor das Betriebssystem versucht, eine TCP-keepalive-Nachricht an den Client zu senden. Der Standardwert ist 10. Weitere Informationen finden Sie in der PostgreSQL-tcp_keepalives_idleReferenz.
(Optional) TCP_KEEPALIVES_INTERVAL: Zeit in Sekunden, bevor eine TCP-keepalive-Nachricht, die vom Client nicht bestätigt wurde, noch einmal gesendet werden soll. Der Standardwert ist 10. Weitere Informationen finden Sie in der PostgreSQL-tcp_keepalives_intervalReferenz.
(Optional) TCP_KEEPALIVES_COUNT: Anzahl der TCP-keepalive-Nachrichten, die verloren gehen können, bevor die Verbindung des Servers zum Client als inaktiv gilt. Der Standardwert ist 10. Weitere Informationen finden Sie in der PostgreSQL-tcp_keepalives_count Referenz.
(Optional) ENVIRONMENT_TYPE: bestimmt die Umgebung, in der der Cluster eingerichtet wird: onprem oder gcp.
(Optional) VIRTUAL_IP: virtuelle IP-Adresse, die vom Load-Balancer verwendet wird. Wenn Sie dbLoadBalancerOptions definieren, ist dies erforderlich. Weitere Informationen finden Sie unter Hochverfügbarkeit verwalten.
VIRTUAL_IP_INTERFACE: Netzwerkschnittstelle, auf der VIRTUAL_IP konfiguriert ist. Der Standardwert ist eth0.

Cluster erstellen

Wählen Sie den Tab aus, der Ihrer Umgebung entspricht, und folgen Sie der Anleitung, um den Cluster zu erstellen.

Ansible

Führen Sie die folgenden Schritte aus, um den Cluster zu erstellen:

Erstellen Sie ein Playbook für die Spezifikationen des Datenbankclusters.
```
- name: Create DBCluster
  hosts: localhost
  vars:
    ansible_user: ANSIBLE_USER
    ansible_ssh_private_key_file: ANSIBLE_SSH_PRIVATE_KEY_FILE
  roles:
  - role: google.alloydbomni_orchestrator.bootstrap
```
Ersetzen Sie die folgenden Variablen:
- ANSIBLE_USER: Betriebssystemnutzer, mit dem sich Ansible in Ihren AlloyDB Omni-Knoten anmeldet.
- ANSIBLE_SSH_PRIVATE_KEY_FILE: privater Schlüssel, mit dem Ansible eine Verbindung zu Ihren AlloyDB Omni-Knoten über SSH herstellt.
Führen Sie das Playbook aus.
```
ansible-playbook DBCLUSTER_PLAYBOOK -i "DEPLOYMENT_SPEC" \
      -e resource_spec="DBCLUSTER_SPECIFICATIONS"
```
Ersetzen Sie die folgenden Variablen:
- DBCLUSTER_PLAYBOOK: Pfad zum Playbook, das Sie für den Datenbankcluster erstellt haben.
- DEPLOYMENT_SPEC: Pfad zur Bereitstellungsspezifikation, die Sie unter AlloyDB Omni-Komponenten installieren erstellt haben.
- DBCLUSTER_SPECIFICATIONS: Pfad zu den Clusterspezifikationen.

`alloydbctl`

Führen Sie den folgenden Befehl aus, um den Cluster zu erstellen:

alloydbctl apply -d "DEPLOYMENT_SPEC" -r "DBCLUSTER_SPECIFICATIONS"

Ersetzen Sie die folgenden Variablen:

DEPLOYMENT_SPEC: Pfad zur Bereitstellungsspezifikation, die Sie unter AlloyDB Omni-Komponenten installieren erstellt haben.
DBCLUSTER_SPECIFICATIONS: Pfad zu den Clusterspezifikationen.

Cluster löschen

Wählen Sie den Tab aus, der Ihrer Umgebung entspricht, und folgen Sie der Anleitung, um den Cluster zu löschen.

Ansible

Führen Sie die folgenden Schritte aus, um den Cluster mit Ansible zu löschen:

Erstellen Sie ein Playbook mit dem Namen teardown.yaml:

- name: Tear down AlloyDB Omni cluster
  hosts: localhost
  vars:
    ansible_user: ANSIBLE_USER
    ansible_ssh_private_key_file: ANSIBLE_SSH_PRIVATE_KEY_FILE
  roles:
  - role: google.alloydbomni_orchestrator.delete

Führen Sie das Playbook mit ansible-playbook aus. Sie müssen DBCluster als resource_type und den Namen des zu löschenden Clusters als resource_name angeben.
```
ansible-playbook -i "DEPLOYMENT_SPEC" teardown.yaml \
  -e `resource_type`=`DBCluster` -e `resource_name`="DBCLUSTER_NAME"
```

Wenn der Teardown-Prozess aufgrund von Inkonsistenzen im Clusterstatus fehlschlägt (z. B. wenn ein Knoten nicht erreichbar ist), können Sie versuchen, das Löschen des Clusters zu erzwingen, indem Sie dem Befehl -e force=true hinzufügen. Dadurch wird der Orchestrator angewiesen, Fehler während des Teardown-Prozesses zu ignorieren und so viele Ressourcen wie möglich zu entfernen.

  ansible-playbook -i "DEPLOYMENT_SPEC" teardown.yaml \
    -e resource_type=DBCluster -e resource_name="DBCLUSTER_NAME" -e force=true

`alloydbctl`

Führen Sie den folgenden Befehl aus, um den Cluster mit alloydbctl zu löschen:

alloydbctl delete -d "DEPLOYMENT_SPEC" \
      --resource_type DBCluster --resource_name "DBCLUSTER_NAME"

Ersetzen Sie die folgenden Variablen:

DEPLOYMENT_SPEC: Pfad zur Bereitstellungsspezifikation, die Sie unter AlloyDB Omni-Komponenten installieren erstellt haben.
DBCLUSTER_NAME: Name des Datenbankclusters. Beispiel: my-dbcluster.

Cluster erstellen Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Beschränkungen

Hinweis

Clusterspezifikationen vorbereiten

Cluster erstellen

Ansible

alloydbctl

Cluster löschen

Ansible

alloydbctl

Cluster erstellen

`alloydbctl`

`alloydbctl`