בדף הזה מתועדת גרסה 16.8.0 של AlloyDB Omni באמצעות אפשרות הפריסה Kubernetes. בוחרים אפשרות פריסה אחרת.

Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

יצירה של משבצת שכפול ופרסום

בוחרים גרסה של מאמר העזרה:

במאמר הזה נסביר איך ליצור משבצות רפליקציה לוגית ב-AlloyDB Omni. ב-PostgreSQL, ‏ שכפול לוגי הוא שיטה להעתקת שינויים בנתונים ממסד נתונים של מפרסם למנוי אחד או יותר, שיכולים להיות מסדי נתונים או אפליקציות אחרות. אפשר להפעיל ולהגדיר שכפול לוגי באשכולות שיוצרים באמצעות AlloyDB Omni Kubernetes Operator.

השינויים שמוזרמים יכולים להיות עדכונים, הוספות או מחיקות של שורות בודדות. המשתמשים שנרשמו לערוץ מתחברים לבעל התוכן הדיגיטלי דרך משבצת שכפול ייחודית שמבטיחה חיבור קבוע. חיבור קבוע שומר על מצב הזרמת הנתונים, כך שאם מתרחשת הפרעה, ההזרמה מתחדשת מהמקום שבו היא נעצרה.

מידע נוסף על רפליקציה לוגית ב-PostgreSQL זמין במאמר Logical Replication.

קטעי הקוד בדף הזה הם דוגמאות שאפשר להשתמש בהן כמודלים, ולהחליף את הערכים בערכים של משאבי AlloyDB Omni.

לפני שמתחילים

איך מתקינים את Omni Operator ב-Kubernetes

יצירת אשכול של בעלי אפליקציות

לפני שיוצרים את מיקומי השכפול, צריך ליצור את אשכול השרתים המפרסם עם שכפול לוגי מופעל. צריך להגדיר את הפרמטר wal_level לערך logical במניפסט DBCluster.

כדי ליצור אשכול של מסד נתונים של בעל תוכן דיגיטלי עם הפעלה של שכפול לוגי, צריך להחיל את המניפסט הבא:

  apiVersion: v1
  kind: Secret
  metadata:
    name: db-pw-DB_CLUSTER_NAME
    namespace: DB_CLUSTER_NAMESPACE
  type: Opaque
  data:
    DB_CLUSTER_NAME: "ENCODED_PASSWORD"
  ---
  apiVersion: alloydbomni.dbadmin.goog/v1
  kind: DBCluster
  metadata:
    name: DB_CLUSTER_NAME
    namespace: DB_CLUSTER_NAMESPACE
  spec:
    databaseVersion: "ALLOYDB_OMNI_VERSION"
    spec:
    availability:
      numberOfStandbys: 1
    primarySpec:
      parameters:
        wal_level: "logical"
      adminUser:
        passwordRef:
          name: db-pw-DB_CLUSTER_NAME
      resources:
        cpu: CPU_COUNT
        memory: MEMORY_SIZE
        disks:
        - name: DataDisk
          size: DISK_SIZE

מחליפים את מה שכתוב בשדות הבאים:

‫DB_CLUSTER_NAME: השם של אשכול מסד הנתונים הזה, למשל publisher.
‫DB_CLUSTER_NAMESPACE (אופציונלי): מרחב השמות שבו רוצים ליצור את אשכול מסדי הנתונים – למשל, publisher-namespace.
‫ENCODED_PASSWORD: הסיסמה להתחברות למסד הנתונים עבור תפקיד המשתמש postgres שמוגדר כברירת מחדל, בקידוד base64. לדוגמה, Q2hhbmdlTWUxMjM= עבור ChangeMe123.
‫ALLOYDB_OMNI_VERSION: גרסת AlloyDB Omni‏, 15.7.0 ואילך.
‫CPU_COUNT: מספר המעבדים הזמינים לכל מופע של מסד נתונים באשכול מסדי הנתונים הזה.
‫MEMORY_SIZE: כמות הזיכרון לכל מופע של מסד נתונים באשכול מסדי הנתונים הזה. מומלץ להגדיר את הערך הזה ל-8 גיגה-בייט לכל מעבד. לדוגמה, אם הגדרתם את cpu ל-2 קודם במניפסט הזה, מומלץ להגדיר את memory ל-16Gi.
‫DISK_SIZE: גודל הדיסק לכל מופע של מסד נתונים, לדוגמה 10Gi.

יצירת משבצת שכפול

אחרי שיוצרים את אשכול בעלי התוכן הדיגיטלי, אפשר ליצור משבצת שכפול לוגית באמצעות משאב Replication באשכול בעלי התוכן הדיגיטלי. כל משאב Replication משויך למשאב מקביל של אשכול מסדי נתונים. יכולים להיות כמה משאבים של שכפול לוגי שמשויכים לאותו אשכול של מסדי נתונים.

כדי להגדיר משבצת שכפול באשכול של השרת הראשי, צריך להחיל את המניפסט הבא:

$ cat << EOF | kubectl apply -f -
apiVersion: v1
kind: Secret
metadata:
  name: USER_PASSWORD_SECRET_NAME
  namespace: USER_PASSWORD_SECRET_NAMESPACE
type: Opaque
---
apiVersion: alloydbomni.dbadmin.goog/v1
kind: Replication
metadata:
  name: REPLICATION_NAME
  namespace: NAMESPACE
spec:
  dbcluster:
    name: DB_CLUSTER_NAME
  upstream:
    logicalReplication:
      pluginName: DECODER_PLUGIN
      databaseName: DATABASE_NAME
    applicationName: APPLICATION_NAME
    replicationSlotName: REPLICATION_SLOT_NAME
    synchronous: "REPLICATION_MODE"
    username: APPLICATION_USER
    password:
      name: USER_PASSWORD_SECRET_NAME
      namespace: USER_PASSWORD_SECRET_NAMESPACE
EOF

מחליפים את מה שכתוב בשדות הבאים:

‫REPLICATION_NAME: שם למשאב Replication הזה, לדוגמה replication-1.
‫NAMESPACE: מרחב השמות של Kubernetes עבור משאב Replication. הוא חייב להיות זהה למרחב השמות של אשכול מסד הנתונים.
‫DB_CLUSTER_NAME: השם של אשכול מסד הנתונים שהקציתם לו כשנוצר.
‫DECODER_PLUGIN: מוגדר לפלאגין הפענוח, כמו pgoutput, שרוצים להשתמש בו לשכפול לוגי. מידע נוסף על פלאגינים שונים של פענוח זמין במאמר בנושא פלאגינים של פלט.
‫DATABASE_NAME: מוגדר לשם של מסד הנתונים שאת השינויים בו רוצים להזרים למקום השכפול. מוודאים שמסד הנתונים כבר נוצר באשכול של בעל התוכן הדיגיטלי.
‫APPLICATION_NAME (אופציונלי): מגדירים את שם האפליקציה שתתחבר למיקום השכפול. חובה למלא את השדה הזה כשמצב הסטרימינג מוגדר לסינכרוני.
‫REPLICATION_MODE (אופציונלי): מגדירים ל-false לשכפול אסינכרוני. אם רוצים להפעיל שכפול סינכרוני, אבל מוכנים להתפשר על המהירות, צריך להגדיר את הערך הזה כ-true. ערך ברירת המחדל הוא false, אם לא הוגדר ערך באופן מפורש.
‫REPLICATION_SLOT_NAME: השם של משבצת השכפול שתיצור המערכת ושמשמשת את המינוי – לדוגמה, logicalrepltestslot.
‫REPLICATION_USER (אופציונלי): שם המשתמש שמתחבר למקום השכפול. אם מגדירים את משתמש השכפול, צריך להגדיר את שם הסוד, מרחב השמות והסיסמה.
‫USER_PASSWORD_SECRET_NAME (אופציונלי): השם של סוד Kubernetes של משתמש האפליקציה. חובה, אם משתמש האפליקציה מוגדר.
‫USER_PASSWORD_SECRET_NAMESPACE (אופציונלי): מרחב השמות שבו נמצא הסוד של Kubernetes עבור משתמש האפליקציה. חובה, אם הוגדר משתמש באפליקציה.

הצגת סטטוס משבצת הרפליקציה

כדי לראות את הסטטוס של משבצות השכפול, מריצים את הפקודה הבאה:

kubectl get replication.alloydbomni.dbadmin.goog REPLICATION_NAME -n NAMESPACE -oyaml

התשובה כוללת את השדה status ופרטים נוספים:

apiVersion: alloydbomni.dbadmin.goog/v1
kind: Replication
metadata:
  name: REPLICATION_NAME
  namespace: NAMESPACE
...
...
status:
  conditions:
  - lastTransitionTime: "2025-01-25T06:49:25Z"
    message: Ready for replication
    reason: Ready
    status: "True"
    type: Ready
  - lastTransitionTime: "2025-01-25T06:49:25Z"
    message: Replication slot is not being used
    reason: Unhealthy
    status: "False"
    type: Healthy
  observedGeneration: 2
  upstream:
    host: DATABASE_ENDPOINT
    password:
      name: USER_PASSWORD_SECRET_NAME
      namespace: USER_PASSWORD_SECRET_NAMESPACE
    port: DATABASE_PORT
    replicationSlotName: REPLICATION_SLOT_NAME
    username: APPLICATION_USER

בDATABASE_ENDPOINT מוצגת כתובת ה-IP שבה אתם משתמשים כדי להתחבר למסד הנתונים. הסטטוס TRUE בעמודה READY מציין שהמשבצת מוכנה להפעלה. כשהמנוי DBCluster או האפליקציה מתחברים למקום השכפול, הסטטוס בעמודה HEALTHY משתנה ל-TRUE.

הגדרת אשכול השרתים של המוציא לאור

מאתרים את הפוד הרצוי.

$ 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"

מתחברים ל-pod הראשי באשכול של בעל האתר באמצעות psql:
```
psql -h IP_ADDRESS -U USERNAME -d DATABASE_NAME
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫IP_ADDRESS: כתובת ה-IP של הפוד הראשי של אשכול השרתים של האתר.
- ‫USERNAME: משתמש postgres של מסד הנתונים.
- ‫DATABASE_NAME: מסד הנתונים שהמנוי רוצה להירשם אליו.
אם מסד הנתונים DATABASE_NAME שצוין במשאב השכפול לא קיים, צריך ליצור מסד נתונים.
```
CREATE DATABASE DATABASE_NAME;
```

אופציונלי: למטרות בדיקה, מוסיפים טבלה למסד הנתונים ומזינים בה נתונים. אפשר להשתמש בנתונים האלה כדי לצפות בשכפול הנתונים מהאתר של בעל התוכן הדיגיטלי אל האתר של המנוי.

$ psql -h localhost -U postgres DATABASE_NAME
customer=# CREATE TABLE TABLE_NAME(
customer(#    ID INT PRIMARY KEY     NOT NULL,
customer(#    NAME           TEXT    NOT NULL,
customer(#    AGE            INT     NOT NULL,
customer(#    SALARY         REAL
customer(# );
CREATE TABLE
customer=# INSERT INTO TABLE_NAME (ID,NAME,AGE,SALARY) VALUES
customer-# (1, 'Quinn', 25, 65000.00),
customer-# (2, 'Kim', 22, 72250.00),
customer-# (3, 'Bola', 31, 53000.00),
customer-# (4, 'Sasha', 33, 105000.00),
customer-# (5, 'Yuri', 27, 85000.00);
INSERT 0 5
customer=# \dt
          List of relations
Schema |  Name   | Type  |  Owner
--------+---------+-------+----------
public | company | table | postgres
(1 row)

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
(5 rows)

מחליפים את TABLE_NAME בטבלה שבה רוצים לאחסן את הנתונים, והמנוי נרשם אליה.

נותנים את ההרשאות:

GRANT SELECT ON ALL TABLES IN SCHEMA public TO REPLICATION_USER;
GRANT USAGE ON SCHEMA public TO REPLICATION_USER;
ALTER DEFAULT PRIVILEGES IN SCHEMA public
GRANT SELECT ON TABLES TO REPLICATION_USER;

כדי ליצור פרסום, מריצים את הפקודה הבאה:
```
CREATE PUBLICATION PUBLICATION_NAME;
ALTER PUBLICATION PUBLICATION_NAME ADD TABLE TABLE_NAME;
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫PUBLICATION_NAME: שם הפרסום שבו המנוי ישתמש כדי להירשם.

אחרי שיוצרים את הפרסום, אפשר להגדיר את אשכול המינויים לשכפול לוגי או להגדיר את האפליקציה כדי להתחיל בשכפול.

מגבלות

אין תמיכה בעדכונים של הגדרת משבצת השכפול. כדי לעדכן את ההגדרה, צריך להפיל את משבצת השכפול וליצור אותה מחדש עם ההגדרה המעודכנת.

כדי להסיר את משבצת השכפול, מריצים את הפקודה הבאה:
```
kubectl delete replication.alloydbomni.dbadmin.goog REPLICATION_NAME -n NAMESPACE
```
אפשר להגדיר את משבצת השכפול הלוגי רק במסד הנתונים של בעל האפליקציה. ה-API לשכפול לא תומך ב-DBCluster או באפליקציות של מנויים לשכפול לוגי.
אם אשכול מסד הנתונים שאליו מפנה אובייקט הרפליקציה מוגדר לזמינות גבוהה, משבצת הרפליקציה הלוגית נוצרת מחדש בגיבוי שהועלה אחרי יתירות כשל. אחרי שמשבט השכפול נוצר מחדש, המיקום של הסטרימינג במשבט כבר לא זמין, וכל האפליקציות שמנויות לסטרימינג צריכות להתחבר מחדש ולהפעיל מחדש את הסטרימינג.

המאמרים הבאים

הגדרת אשכול של מנויים לשכפול לוגי