Configura il cluster sottoscrittore per la replica logica

Seleziona una versione della documentazione: Corrente (16.8.0)keyboard_arrow_down

• Attuale (16.8.0)
• 16.8.0
• 16.3.0
• 15.12.0
• 15.7.1
• 15.7.0
• 15.5.5
• 15.5.4
• 15.5.2

Questo documento fornisce esempi che mostrano come creare e configurare manualmente un cluster di sottoscrittori. Un cluster sottoscrittore è un cluster di database che riceve i dati replicati da un cluster publisher.

Gli snippet di codice in questa pagina sono esempi che puoi utilizzare come modelli, sostituendo i valori con quelli delle tue risorse AlloyDB Omni.

Prima di iniziare

• Installa Omni Operator su Kubernetes.
• Assicurati di creare uno slot di replica, un cluster publisher e una pubblicazione. Per saperne di più, consulta Creare slot di replica e pubblicazione.

Crea e configura il cluster sottoscrittore

1. Crea un cluster di iscritti.

   $ cat << EOF | kubectl apply -f -
   apiVersion: v1
   kind: Secret
   metadata:
     name: db-pw-DB_CLUSTER_NAME
   type: Opaque
   data:
     DB_CLUSTER_NAME: "ENCODED_PASSWORD" # Password is odspassword
   ---
   apiVersion: alloydbomni.dbadmin.goog/v1
   kind: DBCluster
   metadata:
     name: subscriber
   spec:
     databaseVersion: "16.8.0"
     primarySpec:
       adminUser:
         passwordRef:
           name: db-pw-DB_CLUSTER_NAME
       resources:
         memory: MEMORY_SIZE
         cpu: CPU_COUNT
         disks:
         - name: DataDisk
           size: DISK_SIZE
   EOF
   

   Sostituisci quanto segue:

   • DB_CLUSTER_NAME: il nome di questo cluster di database, ad esempio subscriber-cluster.

   • ENCODED_PASSWORD: la password di accesso al database per il ruolo utente postgres predefinito, codificata come stringa base64, ad esempio Q2hhbmdlTWUxMjM= per ChangeMe123.

   • CPU_COUNT: il numero di CPU disponibili per ogni istanza di database in questo cluster di database.

   • MEMORY_SIZE: la quantità di memoria per istanza di database di questo cluster di database. Ti consigliamo di impostare questo valore su 8 gigabyte per CPU. Ad esempio, se hai impostato cpu su 2 in precedenza in questo manifest, ti consigliamo di impostare memory su 16Gi.

   • DISK_SIZE: le dimensioni del disco per istanza di database, ad esempio 10Gi.

2. Trova il pod che ti serve.

   $ kubectl get pod -l "alloydbomni.internal.dbadmin.goog/dbcluster=DB_CLUSTER_NAME, alloydbomni.internal.dbadmin.goog/task-type=database, dbs.internal.dbadmin.goog/ha-role=Primary"
   

3. Accedi al pod del database del cluster di abbonati.

   $ kubectl get pod
   NAME                                          READY   STATUS    RESTARTS   AGE
   al-2bce-publisher-0                           3/3     Running   0          20h
   
   $ kubectl exec -ti SUBSCRIBER_POD_NAME  -- /bin/bash
   Defaulted container "database" out of: database, logrotate-agent, memoryagent, dbinit (init)
   postgres@al-3513-subscriber-0:/$
   

   Sostituisci SUBSCRIBER_POD_NAME con il nome del pod abbonato.

4. Trova l'indirizzo IP del bilanciatore del carico sul cluster DB dell'editore, ad esempio 10.116.14.190

   $ kubectl get service
   NAME                     TYPE           CLUSTER-IP      EXTERNAL-IP    PORT(S)          AGE
   al-publisher-rw-ilb      ClusterIP      10.116.14.190   <none>         5432/TCP         21h
   

5. Esegui un backup dello schema dall'editore come copia iniziale dei dati pubblicati nel database dell'editore. La replica logica non supporta la replica DDL. Uno schema o una tabella che prevedi di replicare deve esistere nella destinazione (cluster abbonato) prima dell'inizio della replica logica.

   postgres@al-3513-subscriber-0:/$ pg_dump -h PUBLISHER_IP_ADDRESS -U postgres --create --schema-only customer > /tmp/customer.schema-only.sql
   

   Sostituisci PUBLISHER_IP_ADDRESS con l'indirizzo IP del bilanciatore del carico sul DBcluster del publisher.

6. Applica il backup nel database degli abbonati.

   postgres@al-3513-subscriber-0:/$ psql -h localhost -U postgres < /tmp/customer.schema-only.sql
   

7. (Facoltativo) Verifica che la tabella non contenga dati.

   # There is no data in table company
   customer=# select * from company;
   id | name | age | salary
   ----+------+-----+--------
   (0 rows)
   

8. Crea una sottoscrizione per il database. Assicurati che la pubblicazione sia già stata creata nel DBCluster dell'editore.

   postgres@al-3513-subscriber-0:/$ CREATE SUBSCRIPTION sub_customer CONNECTION 'host=PUBLISHER_IP_ADDRESS port=5432 user=REPLICATION_USER dbname=DATABASE_NAME password=PUBLISHER_CLUSTER_PASSWORD sslmode=require' PUBLICATION PUBLICATION_NAME WITH (slot_name='REPLICATION_SLOT_NAME');
   

   Sostituisci quanto segue:

   • REPLICATION_USER: il nome dell'utente che si connette allo slot di replica.
   • DATABASE_NAME: impostato sul nome del database di cui vuoi trasmettere in streaming le modifiche dallo slot di replica.
   • PUBLISHER_CLUSTER_PASSWORD: la password di accesso al database per l'utente postgres di DBCluster del publisher.
   • PUBLICATION_NAME: il nome della pubblicazione a cui si abbona l'abbonato.
   • REPLICATION_SLOT_NAME: il nome dello slot di replica creato nel DBCluster del publisher.

9. (Facoltativo) Verifica la replica sul cluster di abbonamento.

   postgres@al-3513-subscriber-0:/$ psql -h localhost -U postgres DATABASE_NAME
   customer=# select * from public.company;
   id | name  | age | salary
   ----+-------+-----+--------
     1 | Quinn |  25 |  65000
     2 | Kim   |  22 |  72250
     3 | Bola  |  31 |  53000
     4 | Sasha |  33 | 105000
     5 | Yuri  |  27 |  85000
   (5 rows)
   

10. Nel cluster dell'editore, aggiungi una riga alla tabella.

    # On the publisher database
    $ kubectl exec -ti al-2bce-publisher-0  -- /bin/bash
    Defaulted container "database" out of: database, logrotate-agent, memoryagent, dbinit (init)
    postgres@al-2bce-publisher-0:/$ psql -h localhost -U postgres DATABASE_NAME
    customer=# insert into TABLE_NAME (id, name, age, salary) values (6, 'Alex', 39, 100000);
    

    Sostituisci TABLE_NAME con il nome della tabella nel DBCluster del publisher a cui è iscritto il sottoscrittore.

11. Nel cluster del sottoscrittore, verifica che la riga aggiunta alla tabella nel cluster del publisher sia stata replicata nella tabella del cluster del sottoscrittore.

    # On the subscriber database, data is synced.
    postgres@al-3513-subscriber-0:/$ psql -h localhost -U postgres DATABASE_NAME
    customer=# select * from TABLE_NAME;
    id | name  | age | salary
    ----+-------+-----+--------
      1 | Quinn |  25 |  65000
      2 | Kim   |  22 |  72250
      3 | Bola  |  31 |  53000
      4 | Sasha |  33 | 105000
      5 | Yuri  |  27 |  85000
      6 | Alex  |  39 | 100000
    (6 rows)
    

Creare manualmente tabelle aggiuntive

La replica logica non sincronizza automaticamente le modifiche DDL, a differenza di replicate_ddl_command in pglogical. Sebbene lo strumento open source pgl_ddl_deploy offra una soluzione, puoi anche eseguire manualmente i comandi DDL sul sottoscrittore.

1. Per illustrare questo concetto, crea una nuova tabella denominata finance nel database customer sul cluster publisher.

   # On the publisher database
   $ kubectl exec -ti al-2bce-publisher-0  -- /bin/bash
   Defaulted container "database" out of: database, logrotate-agent, memoryagent, dbinit (init)
   postgres@al-2bce-publisher-0:/$ psql -h localhost -U postgres customer
   customer=# create table finance (row text);
   CREATE TABLE
   customer=# insert into finance values ('critical data');
   INSERT 0 1
   customer=# ALTER PUBLICATION pub_customer ADD TABLE finance;
   ALTER PUBLICATION
   

2. Quando viene aggiunta una nuova tabella al cluster publisher, devi applicare manualmente il DDL (creazione della tabella) nel sottoscrittore, quindi verificare la replica eseguendo il seguente comando nel cluster sottoscrittore.

   postgres@al-3513-subscriber-0:/$ psql -h localhost -U postgres customer
   customer=# create table finance (row text);
   CREATE TABLE
   customer=# ALTER SUBSCRIPTION sub_customer REFRESH PUBLICATION;
   ALTER SUBSCRIPTION
   customer=# select * from finance;
         row
   ---------------
   critical data
   (1 row)
   

Passaggi successivi

• Gestire l'alta disponibilità (HA) in Kubernetes