Datenbankcluster mit Status in GKE bereitstellen

GKE-Cluster erstellen

In diesem Abschnitt erstellen Sie einen regionalen GKE-Cluster. Im Gegensatz zu zonalen Clustern wird die Steuerungsebene regionaler Cluster in mehrere Zonen repliziert. Entsprechen wird die Verbindung zur Steuerungsebene bei einem Ausfall in einer einzelnen Zone nicht unterbrochen.

So erstellen Sie einen GKE-Cluster:

MySQL-StatefulSets bereitstellen

In diesem Abschnitt stellen Sie einen MySQL-StatefulSet bereit. Jedes StatefulSet besteht aus drei MySQL-Replikaten.

So stellen Sie das MySQL-StatefulSet bereit:

1. Erstellen Sie einen Namespace für das StatefulSet.

   kubectl create namespace mysql1
   

2. Erstellen Sie das MySQL-Secret:

   apiVersion: v1
   kind: Secret
   metadata:
     name: mysql-secret
   type: Opaque
   data:
     password: UGFzc3dvcmQkMTIzNDU2 # Password$123456
     admin-password: UGFzc3dvcmQkMTIzNDU2 # Password$123456

   kubectl apply -n mysql1 -f secret.yaml
   

   Das Passwort wird mit jedem Pod bereitgestellt. Weiter wird es in dieser Anleitung von Verwaltungsskripts und Befehlen zur Bereitstellung von MySQL-InnoDB-Clustern und ClusterSets verwendet.

3. Erstellen Sie die StorageClass.

   apiVersion: storage.k8s.io/v1
   kind: StorageClass
   metadata:
     name: fast-storageclass
   provisioner: pd.csi.storage.gke.io
   volumeBindingMode: WaitForFirstConsumer
   reclaimPolicy: Retain
   allowVolumeExpansion: true
   parameters:
     type: pd-balanced

   kubectl apply -n mysql1 -f storageclass.yaml
   

   Diese Speicherklasse verwendet den nichtflüchtigen Speichertyp pd-balanced, der eine Balance zwischen Leistung und Kosten bietet. Das volumeBindingMode-Feld ist auf WaitForFirstConsumer gesetzt, was bedeutet, dass GKE die Bereitstellung eines PersistentVolume verzögert, bis der Pod erstellt ist. Diese Einstellung sorgt dafür, dass das Laufwerk in der Zone bereitgestellt wird, in der der Pod geplant ist.

4. StatefulSet der MySQL-Instanz-Pods bereitstellen.

   apiVersion: apps/v1
   kind: StatefulSet
   metadata:
     name: dbc1
     labels:
       app: mysql
   spec:
     replicas: 3
     selector:
       matchLabels:
         app: mysql
     serviceName: mysql
     template:
       metadata:
         labels:
           app: mysql
       spec:
         topologySpreadConstraints:
         - maxSkew: 1
           topologyKey: "topology.kubernetes.io/zone"
           whenUnsatisfiable: DoNotSchedule
           labelSelector:
             matchLabels:
               app: mysql
         affinity:
           podAntiAffinity:
             requiredDuringSchedulingIgnoredDuringExecution:
             - labelSelector:
                 matchExpressions:
                 - key: app
                   operator: In
                   values:
                   - mysql
               topologyKey: "kubernetes.io/hostname"
         containers:
         - name: mysql
           image: mysql/mysql-server:8.0.28
           command:
           - /bin/bash
           args:
           - -c
           - >-
             /entrypoint.sh
             --server-id=$((20 +  $(echo $HOSTNAME | grep -o '[^-]*$') + 1))
             --report-host=${HOSTNAME}.mysql.mysql1.svc.cluster.local
             --binlog-checksum=NONE
             --enforce-gtid-consistency=ON
             --gtid-mode=ON
             --default-authentication-plugin=mysql_native_password
           env:
           - name: MYSQL_ROOT_PASSWORD
             valueFrom:
               secretKeyRef:
                 name: mysql-secret
                 key: password
           - name: MYSQL_ADMIN_PASSWORD
             valueFrom:
               secretKeyRef:
                 name: mysql-secret
                 key: admin-password
           - name: MYSQL_ROOT_HOST
             value: '%'
           ports:
           - name: mysql
             containerPort: 3306
           - name: mysqlx
             containerPort: 33060
           - name: xcom
             containerPort: 33061
           resources:
             limits:
               cpu: "500m"
               ephemeral-storage: "1Gi"
               memory: "1Gi"
             requests:
               cpu: "500m"
               ephemeral-storage: "1Gi"
               memory: "1Gi"
           volumeMounts:
           - name: mysql
             mountPath: /var/lib/mysql
             subPath: mysql
           readinessProbe:
             exec:
               command:
               - bash
               - "-c"
               - |
                 mysql -h127.0.0.1 -uroot -p$MYSQL_ROOT_PASSWORD -e'SELECT 1'
             initialDelaySeconds: 30
             periodSeconds: 2
             timeoutSeconds: 1
           livenessProbe:
             exec:
               command:
               - bash
               - "-c"
               - |
                 mysqladmin -uroot -p$MYSQL_ROOT_PASSWORD ping
             initialDelaySeconds: 30
             periodSeconds: 10
             timeoutSeconds: 5
     updateStrategy:
       rollingUpdate:
         partition: 0
       type: RollingUpdate
     volumeClaimTemplates:
     - metadata:
         name: mysql
         labels:
           app: mysql
       spec:
         storageClassName: fast-storageclass
         volumeMode: Filesystem
         accessModes:
         - ReadWriteOnce
         resources:
           requests:
             storage: 10Gi

   kubectl apply -n mysql1 -f c1-mysql.yaml
   

   Mit diesem Befehl wird das StatefulSet mit drei Replikaten bereitgestellt. In dieser Anleitung wird der primäre MySQL-Cluster über drei Zonen in us-west1 hinweg bereitgestellt. Die Ausgabe sieht in etwa so aus:

   service/mysql created
   statefulset.apps/dbc1 created
   

   In dieser Anleitung sind die Ressourcenlimits und ‑anfragen auf minimale Werte gesetzt, um Kosten zu sparen. Achten Sie bei der Planung einer Produktionsarbeitslast darauf, dass diese Werte den Anforderungen Ihrer Organisation entsprechen.

5. Prüfen Sie, ob das StatefulSet erfolgreich erstellt wurde.

   kubectl get statefulset -n mysql1 --watch
   

   Es kann etwa 10 Minuten dauern, bis das SatefulSet bereit ist.

6. Wenn alle drei Pods bereit sind, beenden Sie den Befehl mit Ctrl+C. Wenn PodUnscheduleable-Fehler aufgrund unzureichender CPU- oder Arbeitsspeicherressourcen auftreten, warten Sie einige Minuten, bis die Steuerungsebene entsprechend der hohen Arbeitslast skaliert wurde.

   Die Ausgabe sieht in etwa so aus:

   NAME   READY   AGE
   dbc1   1/3     39s
   dbc1   2/3     50s
   dbc1   3/3     73s
   

7. Führen Sie das folgende Skript aus, um die Platzierung Ihrer Pods auf den GKE-Clusterknoten zu prüfen:

   bash ../scripts/inspect_pod_node.sh mysql1 mysql
   

   Die Ausgabe enthält den Pod-Namen, den GKE-Knotennamen und die Zone, in der der Knoten bereitgestellt wird. Sie sieht in etwa so aus:

   gke-gkemulti-west-5-default-pool-4bcaca65-jch0 us-west1-b dbc1-0
   gke-gkemulti-west-5-default-pool-1ac6e8b5-ddjx us-west1-c dbc1-1
   gke-gkemulti-west-5-default-pool-1f5baa66-bf8t us-west1-a dbc1-2
   

   Die Spalten in der Ausgabe stellen Hostnamen, Cloudzone und Pod-Namen dar.

   Die topologySpreadConstraints-Richtlinie in der StatefulSet-Spezifikation (c1-mysql.yaml) weist den Planer an, die Pods gleichmäßig in der Fehlerdomain zu platzieren (topology.kubernetes.io/zone).

   Die podAntiAffinity-Richtlinie erzwingt die Einschränkung, dass Pods nicht auf demselben GKE-Clusterknoten platziert werden müssen (kubernetes.io/hostname). Bei MySQL-Instanz-Pods führt diese Richtlinie dazu, dass die Pods gleichmäßig über die drei Zonen der Google Cloud-Region hinweg bereitgestellt werden. Diese Platzierung ermöglicht die hohe Verfügbarkeit des MySQL-InnoDB-Clusters. Dazu wird jede Datenbankinstanz in einer separaten Fehlerdomain platziert.

Primären MySQL-InnoDB-Cluster vorbereiten

So konfigurieren Sie einen MySQL-InnoDB-Cluster:

1. Legen Sie im Cloud Shell-Terminal die Gruppenreplikationskonfigurationen für die MySQL-Instanzen fest, die Ihrem Cluster hinzugefügt werden sollen.

   bash ../scripts/c1-clustersetup.sh
   

   POD_ORDINAL_START=${1:-0}
   POD_ORDINAL_END=${2:-2}
   for i in $(seq ${POD_ORDINAL_START} ${POD_ORDINAL_END}); do
     echo "Configuring pod mysql1/dbc1-${i}"
     cat <<'  EOF' | kubectl -n mysql1 exec -i dbc1-${i} -- bash -c 'mysql -uroot -proot --password=${MYSQL_ROOT_PASSWORD}'
   INSTALL PLUGIN group_replication SONAME 'group_replication.so';
   RESET PERSIST IF EXISTS group_replication_ip_allowlist;
   RESET PERSIST IF EXISTS binlog_transaction_dependency_tracking;
   SET @@PERSIST.group_replication_ip_allowlist = 'mysql.mysql1.svc.cluster.local';
   SET @@PERSIST.binlog_transaction_dependency_tracking = 'WRITESET';
     EOF
   done

   Das Skript stellt eine Remote-Verbindung zu jeder der drei MySQL-Instanzen her, um folgende Umgebungsvariablen festzulegen und beizubehalten:

   • group_replication_ip_allowlist: Ermöglicht der Instanz im Cluster, sich mit einer beliebigen Instanz in der Gruppe verbinden.
   • binlog_transaction_dependency_tracking='WRITESET': Ermöglicht parallele Transaktionen, die keine Konflikte hervorrufen.

   Verwenden Sie in MySQL-Versionen vor 8.0.22 group_replication_ip_whitelist anstelle von group_replication_ip_allowlist.

2. Öffnen Sie ein zweites Terminal, damit Sie nicht für jeden Pod eine Shell erstellen müssen.

3. Stellen Sie eine Verbindung zur MySQL-Shell im Pod her dbc1-0.

   kubectl -n mysql1 exec -it dbc1-0 -- \
       /bin/bash \
       -c 'mysqlsh --uri="root:$MYSQL_ROOT_PASSWORD@dbc1-0.mysql.mysql1.svc.cluster.local"'
   

4. Prüfen Sie die Replikations-Zulassungsliste der MySQL-Gruppen, um eine Verbindung zu anderen Instanzen herzustellen.

   \sql SELECT @@group_replication_ip_allowlist;
   

   Die Ausgabe sieht in etwa so aus:

   +----------------------------------+
   | @@group_replication_ip_allowlist |
   +----------------------------------+
   | mysql.mysql1.svc.cluster.local   |
   +----------------------------------+
   

5. Prüfen Sie, ob server-id pro Instanz einmalig ist.

   \sql SELECT @@server_id;
   

   Die Ausgabe sieht in etwa so aus:

   +-------------+
   | @@server_id |
   +-------------+
   |          21 |
   +-------------+
   

6. Konfigurieren Sie jede Instanz für die Verwendung von MySQL InnoDB Cluster und erstellen Sie auf jeder Instanz ein Administratorkonto.

   \js
   dba.configureInstance('root@dbc1-0.mysql.mysql1.svc.cluster.local', {password: os.getenv("MYSQL_ROOT_PASSWORD"),clusterAdmin: 'icadmin', clusterAdminPassword: os.getenv("MYSQL_ADMIN_PASSWORD")});
   dba.configureInstance('root@dbc1-1.mysql.mysql1.svc.cluster.local', {password: os.getenv("MYSQL_ROOT_PASSWORD"),clusterAdmin: 'icadmin', clusterAdminPassword: os.getenv("MYSQL_ADMIN_PASSWORD")});
   dba.configureInstance('root@dbc1-2.mysql.mysql1.svc.cluster.local', {password: os.getenv("MYSQL_ROOT_PASSWORD"),clusterAdmin: 'icadmin', clusterAdminPassword: os.getenv("MYSQL_ADMIN_PASSWORD")});
   

   Alle Instanzen müssen denselben Nutzernamen und dasselbe Passwort haben, damit der MySQL InnoDB-Cluster ordnungsgemäß funktioniert. Die Ausgabe der einzelnen Befehle sieht in etwa so aus:

   ...
   
   The instance 'dbc1-2.mysql:3306' is valid to be used in an InnoDB cluster.
   
   Cluster admin user 'icadmin'@'%' created.
   The instance 'dbc1-2.mysql.mysql1.svc.cluster.local:3306' is already
   ready to be used in an InnoDB cluster.
   
   Successfully enabled parallel appliers.
   

7. Prüfen Sie, ob die Instanz für die Verwendung in einem MySQL-InnoDB-Cluster bereit ist.

   dba.checkInstanceConfiguration()
   

   Die Ausgabe sieht in etwa so aus:

   ...
   
   The instance 'dbc1-0.mysql.mysql1.svc.cluster.local:3306' is valid to be used in an InnoDB cluster.
   
   {
       "status": "ok"
   }
   

   Optional können Sie eine Verbindung zu den einzelnen MySQL-Instanzen herstellen und diesen Befehl wiederholen. Führen Sie beispielsweise diesen Befehl aus, um den Status der dbc1-1-Instanz zu prüfen:

   kubectl -n mysql1 exec -it dbc1-0 -- \
       /bin/bash \
       -c 'mysqlsh --uri="root:$MYSQL_ROOT_PASSWORD@dbc1-1.mysql.mysql1.svc.cluster.local" \
       --js --execute "dba.checkInstanceConfiguration()"'
   

Primären MySQL-InnoDB-Cluster erstellen

Erstellen Sie als Nächstes den MySQL InnoDB-Cluster mit dem MySQL Admin-Befehl createCluster. Beginnen Sie mit der dbc1-0-Instanz, die die primäre Instanz für den Cluster ist, und fügen Sie dem Cluster dann zwei zusätzliche Replikate hinzu.

So initialisieren Sie den MySQL-InnoDB-Cluster:

1. Erstellen Sie den MySQL-InnoDB-Cluster.

   var cluster=dba.createCluster('mycluster');
   

   Durch Ausführen des Befehls createCluster werden folgende Vorgänge ausgelöst:

   • Bereitstellung des Metadatenschemas.
   • Prüfen, ob die Konfiguration für die Gruppenreplikation korrekt ist.
   • Registrieren der Seed-Instanz des neuen Clusters.
   • Erstellen der erforderlichen internen Konten, z. B. des Nutzerkontos für die Replikation.
   • Start der Gruppenreplikation.

   Dieser Befehl initialisiert einen MySQL-InnoDB-Cluster mit dem Host dbc1-0 als primärem Element. Die Clusterreferenz wird in der Clustervariablen gespeichert.

   Die Ausgabe sieht dann ungefähr so aus:

   A new InnoDB cluster will be created on instance 'dbc1-0.mysql:3306'.
   
   Validating instance configuration at dbc1-0.mysql:3306...
   
   This instance reports its own address as dbc1-0.mysql.mysql1.svc.cluster.local:3306
   
   Instance configuration is suitable.
   NOTE: Group Replication will communicate with other instances using
   'dbc1-0.mysql:33061'. Use the localAddress
   option to override.
   
   Creating InnoDB cluster 'mycluster' on
   'dbc1-0.mysql.mysql1.svc.cluster.local:3306'...
   
   Adding Seed Instance...
   Cluster successfully created. Use Cluster.addInstance() to add MySQL
   instances.
   At least 3 instances are needed for the cluster to be able to withstand
   up to one server failure.
   

2. Fügen Sie dem Cluster die zweite Instanz hinzu.

   cluster.addInstance('icadmin@dbc1-1.mysql', {password: os.getenv("MYSQL_ROOT_PASSWORD"), recoveryMethod: 'clone'});
   

3. Fügen Sie dem Cluster die verbleibende Instanz hinzu.

   cluster.addInstance('icadmin@dbc1-2.mysql', {password: os.getenv("MYSQL_ROOT_PASSWORD"), recoveryMethod: 'clone'});
   

   Die Ausgabe sieht in etwa so aus:

   ...
   The instance 'dbc1-2.mysql:3306' was successfully added to the cluster.
   

4. Prüfen Sie den Clusterstatus.

   cluster.status()
   

   Dieser Befehl zeigt den Status des Clusters an. Die Topologie besteht aus drei Hosts, einer primären und zwei sekundären Instanzen. Optional können Sie auch cluster.status({extended:1}) aufrufen.

   Die Ausgabe sieht in etwa so aus:

   {
       "clusterName": "mysql1",
       "defaultReplicaSet": {
           "name": "default",
           "primary": "dbc1-0.mysql:3306",
           "ssl": "REQUIRED",
           "status": "OK",
           "statusText": "Cluster is ONLINE and can tolerate up to ONE failure.",
           "topology": {
               "dbc1-0.mysql:3306": {
                   "address": "dbc1-0.mysql:3306",
                   "memberRole": "PRIMARY",
                   "mode": "R/W",
                   "readReplicas": {},
                   "replicationLag": null,
                   "role": "HA",
                   "status": "ONLINE",
                   "version": "8.0.28"
               },
               "dbc1-1.mysql:3306": {
                   "address": "dbc1-1.mysql:3306",
                   "memberRole": "SECONDARY",
                   "mode": "R/O",
                   "readReplicas": {},
                   "replicationLag": null,
                   "role": "HA",
                   "status": "ONLINE",
                   "version": "8.0.28"
               },
               "dbc1-2.mysql:3306": {
                   "address": "dbc1-2.mysql:3306",
                   "memberRole": "SECONDARY",
                   "mode": "R/O",
                   "readReplicas": {},
                   "replicationLag": null,
                   "role": "HA",
                   "status": "ONLINE",
                   "version": "8.0.28"
               }
           },
           "topologyMode": "Single-Primary"
       },
       "groupInformationSourceMember": "dbc1-0.mysql:3306"
   }
   

   Optional können Sie cluster.status({extended:1}) anrufen, um weitere Statusdetails zu erhalten.

Beispieldatenbank erstellen

So erstellen Sie eine Beispieldatenbank:

1. Erstellen Sie eine Datenbank und laden Sie Daten in die Datenbank.

   \sql
   create database loanapplication;
   use loanapplication
   CREATE TABLE loan (loan_id INT unsigned AUTO_INCREMENT PRIMARY KEY, firstname VARCHAR(30) NOT NULL, lastname VARCHAR(30) NOT NULL , status VARCHAR(30) );
   

2. Fügen Sie Beispieldaten in die Datenbank ein. Um Daten einzufügen, müssen Sie mit der primären Instanz des Clusters verbunden sein.

   INSERT INTO loan (firstname, lastname, status) VALUES ( 'Fred','Flintstone','pending');
   INSERT INTO loan (firstname, lastname, status) VALUES ( 'Betty','Rubble','approved');
   

3. Prüfen Sie, ob die Tabelle die drei im vorherigen Schritt eingefügten Zeilen enthält.

   SELECT * FROM loan;
   

   Die Ausgabe sieht in etwa so aus:

   +---------+-----------+------------+----------+
   | loan_id | firstname | lastname   | status   |
   +---------+-----------+------------+----------+
   |       1 | Fred      | Flintstone | pending  |
   |       2 | Betty     | Rubble     | approved |
   +---------+-----------+------------+----------+
   2 rows in set (0.0010 sec)
   

MySQL-InnoDB-ClusterSet erstellen

Sie können ein MySQL InnoDB-ClusterSet erstellen, um die Replikation von Ihrem primären Cluster zu Replikatclustern mithilfe eines dedizierten ClusterSet-Replikationskanals zu verwalten.

Ein MySQL-InnoDB-ClusterSet bietet eine Notfalltoleranz für MySQL-InnoDB-Clusterbereitstellungen. Dazu wird ein primärer MySQL-InnoDB-Cluster mit einem oder mehreren Replikaten seiner selbst an alternativen Standorten verknüpft, z. B. in mehreren Zonen und mehreren Regionen.

Wenn Sie MySQL Shell geschlossen haben, erstellen Sie eine neue Shell. Dazu führen Sie diesen Befehl in einem neuen Cloud Shell-Terminal aus:

  kubectl -n mysql1 exec -it dbc1-0 -- \
      /bin/bash -c 'mysqlsh \
      --uri="root:$MYSQL_ROOT_PASSWORD@dbc1-0.mysql.mysql1.svc.cluster.local"'

So erstellen Sie ein MySQL InnoDB ClusterSet:

1. Rufen Sie in Ihrem MySQL Shell-Terminal ein Clusterobjekt ab.

   \js
   cluster=dba.getCluster()
   

   Die Ausgabe sieht in etwa so aus:

   <Cluster:mycluster>
   

2. Initialisieren Sie ein MySQL-InnoDB-ClusterSet mit dem vorhandenen MySQL-InnoDB-Cluster, das im Clusterobjekt als primär gespeichert ist.

   clusterset=cluster.createClusterSet('clusterset')
   

   Die Ausgabe sieht in etwa so aus:

   A new ClusterSet will be created based on the Cluster 'mycluster'.
   
   * Validating Cluster 'mycluster' for ClusterSet compliance.
   
   * Creating InnoDB ClusterSet 'clusterset' on 'mycluster'...
   
   * Updating metadata...
   
   ClusterSet successfully created. Use ClusterSet.createReplicaCluster() to add Replica Clusters to it.
   
   <ClusterSet:clusterset>
   

3. Prüfen Sie den Status Ihres MySQL-InnoDB-Clustersets.

   clusterset.status()
   

   Die Ausgabe sieht in etwa so aus:

   {
       "clusters": {
           "mycluster": {
               "clusterRole": "PRIMARY",
               "globalStatus": "OK",
               "primary": "dbc1-0.mysql:3306"
           }
       },
       "domainName": "clusterset",
       "globalPrimaryInstance": "dbc1-0.mysql:3306",
       "primaryCluster": "mycluster",
       "status": "HEALTHY",
       "statusText": "All Clusters available."
   }
   

   Optional können Sie clusterset.status({extended:1}) aufrufen, um weitere Statusdetails zu erhalten, einschließlich Informationen zum Cluster.

4. Beenden Sie die MySQL-Shell.

   \q
   

Stellen Sie eine MySQL-Router bereit

Sie können einen MySQL-Router bereitstellen, um den Traffic der Clientanwendung an die richtigen Cluster weiterzuleiten. Das Routing basiert auf dem Verbindungsport der Anwendung, die einen Datenbankvorgang ausführt:

• Schreibvorgänge werden an die primäre Clusterinstanz im primären ClusterSet weitergeleitet.
• Lesevorgänge können an jede Instanz im primären Cluster weitergeleitet werden.

Wenn Sie einen MySQL Router starten, wird er per Bootstrapping auf Basis der MySQL-InnoDB-ClusterSet-Bereitstellung ausgeführt. Die mit dem MySQL-InnoDB-ClusterSet verbundenen MySQL-Router-Instanzen erkennen alle kontrollierten Switchover und Failover-Failover und leiten Traffic an den neuen primären Cluster weiter.

So stellen Sie einen MySQL Router bereit:

1. Stellen Sie den MySQL-Router im Cloud Shell-Terminal bereit.

   kubectl apply -n mysql1 -f c1-router.yaml
   

   Die Ausgabe sieht in etwa so aus:

   configmap/mysql-router-config created
   service/mysql-router created
   deployment.apps/mysql-router created
   

2. Prüfen Sie die Bereitschaft der MySQL-Router-Bereitstellung.

   kubectl -n mysql1 get deployment mysql-router --watch
   

   Wenn alle drei Pods bereit sind, sieht die Ausgabe in etwa so aus:

   NAME           READY   UP-TO-DATE   AVAILABLE   AGE
   mysql-router   3/3     3            0           3m36s
   

   Wenn in der Konsole der PodUnschedulable-Fehler angezeigt wird, warten Sie ein bis zwei Minuten, während GKE mehr Knoten bereitstellt. Nach der Aktualisierung sollten Sie 3/3 OK sehen.

3. Starten Sie MySQL Shell auf einem Mitglied des vorhandenen Clusters.

   kubectl -n mysql1 exec -it dbc1-0 -- \
       /bin/bash -c 'mysqlsh --uri="root:$MYSQL_ROOT_PASSWORD@dbc1-0.mysql"'
   

   Dieser Befehl stellt eine Verbindung zum dbc1-0-Pod her und startet dann eine Shell, die mit der MySQL-Instanz dbc1-0 verbunden ist.

4. Prüfen Sie die Routerkonfiguration.

   clusterset=dba.getClusterSet()
   clusterset.listRouters()
   

   Die Ausgabe sieht in etwa so aus:

   {
     "domainName": "clusterset",
     "routers": {
       "mysql-router-7cd8585fbc-74pkm::": {
           "hostname": "mysql-router-7cd8585fbc-74pkm",
           "lastCheckIn": "2022-09-22 23:26:26",
           "roPort": 6447,
           "roXPort": 6449,
           "rwPort": 6446,
           "rwXPort": 6448,
           "targetCluster": null,
           "version": "8.0.27"
       },
       "mysql-router-7cd8585fbc-824d4::": {
         ...
       },
       "mysql-router-7cd8585fbc-v2qxz::": {
         ...
       }
     }
   }
   

5. Beenden Sie die MySQL-Shell.

   \q
   

6. Führen Sie dieses Skript aus, um die Platzierung der MySQL-Router-Pods zu prüfen.

   bash ../scripts/inspect_pod_node.sh mysql1 | sort
   

   Das Skript zeigt die Knoten- und Cloud Zone-Platzierung aller Pods im Namespace mysql1, wobei die Ausgabe in etwa so aussieht:

   gke-gkemulti-west-5-default-pool-1ac6e8b5-0h9v us-west1-c mysql-router-6654f985f5-df97q
   gke-gkemulti-west-5-default-pool-1ac6e8b5-ddjx us-west1-c dbc1-1
   gke-gkemulti-west-5-default-pool-1f5baa66-bf8t us-west1-a dbc1-2
   gke-gkemulti-west-5-default-pool-1f5baa66-kt03 us-west1-a mysql-router-6654f985f5-qlfj9
   gke-gkemulti-west-5-default-pool-4bcaca65-2l6s us-west1-b mysql-router-6654f985f5-5967d
   gke-gkemulti-west-5-default-pool-4bcaca65-jch0 us-west1-b dbc1-0
   

   Sie sehen, dass die MySQL Router-Pods gleichmäßig über die Zonen verteilt sind. Das heißt, sie sind nicht auf demselben Knoten wie ein MySQL-Pod oder auf demselben Knoten wie ein anderer MySQL-Router-Pod platziert.

GKE- und MySQL-InnoDB-Cluster-Upgrades verwalten

Updates für MySQL und Kubernetes werden regelmäßig veröffentlicht. Halten Sie sich an die Best Practices für den Betrieb von Software, um Ihre Softwareumgebung regelmäßig zu aktualisieren. Standardmäßig verwaltet GKE Upgrades für Cluster und Knotenpools. Kubernetes und GKE bieten außerdem zusätzliche Funktionen zur Vereinfachung von MySQL-Software-Upgrades.

GKE-Upgrades planen

Sie können proaktive Schritte ausführen und Konfigurationen festlegen, um Risiken zu minimieren und ein reibungsloseres Clusterupgrade bei der Ausführung zustandsorientierter Dienste zu ermöglichen. Dazu gehören:

• Standardcluster: Folgen Sie den GKE-Best Practices für Cluster-Upgrades. Wählen Sie eine geeignete Upgradestrategie, um sicherzustellen, dass die Upgrades während des Wartungsfensters stattfinden:

  • Wählen Sie Surge-Upgrades aus, wenn eine Kostenoptimierung wichtig ist und Ihre Arbeitslasten ein ordnungsgemäßes Herunterfahren in weniger als 60 Minuten tolerieren können.
  • Wählen Sie Blau/Grün-Upgrades, wenn Ihre Arbeitslasten weniger störungstolerant sind und eine vorübergehende Kostenerhöhung aufgrund einer höheren Ressourcennutzung akzeptabel ist.

  Weitere Informationen finden Sie unter Cluster aktualisieren, in dem eine zustandsorientierte Arbeitslast ausgeführt wird. Autopilot-Cluster werden automatisch aktualisiert, basierend auf der ausgewählten Release-Version.

• Verwenden Sie Wartungsfenster, um dafür zu Sorgen, dass Upgrades plangemäß erfolgen. Prüfen Sie vor dem Wartungsfenster, ob die Datenbanksicherungen erfolgreich waren.

• Bevor Sie Traffic zu den aktualisierten MySQL-Knoten zulassen, sollten Sie Bereitschafts- und Aktivitätsprüfungen verwenden, um sicherzustellen, dass sie für den Traffic bereit sind.

• Erstellen Sie Prüfungen, um zu sehen, ob die Replikation synchron ist, bevor Sie den Traffic akzeptieren. Je nach Komplexität und Umfang Ihrer Datenbank können Sie dafür benutzerdefinierte Skripts verwenden.

Budget für Pod-Störungen (Pod Disruption Budget, PDB) festlegen

Wenn ein MySQL-InnoDB-Cluster in GKE ausgeführt wird, muss jederzeit eine ausreichende Anzahl von Instanzen ausgeführt werden, um die Quorumanforderung zu erfüllen.

Für diese Anleitung müssen bei einem MySQL-Cluster mit drei Instanzen zwei Instanzen verfügbar sein, um ein Quorum zu bilden. Mit einer PodDisruptionBudget-Richtlinie können Sie die Anzahl der Pods begrenzen, die zu einer bestimmten Zeit beendet werden können. Dies ist sowohl dem stabilen Zustand Ihrer zustandsorientierten Dienste als auch den Clusterupgrades zuträglich.

Damit eine begrenzte Anzahl an Pods gleichzeitig unterbrochen wird, legen Sie das PDB für Ihre Arbeitslast auf maxUnavailable: 1 fest. Damit wird gesichert, dass während des Dienstvorgangs nie mehr als ein Pod ausgeführt wird.

Das folgende Richtlinienmanifest PodDisruptionBudget legt die Anzahl der maximal nicht verfügbaren Pods für Ihre MySQL-Anwendung auf "1" fest.

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: mysql-pdb
spec:
  maxUnavailable: 1
  selector:
    matchLabels:
      app: mysql

So wenden Sie die PDB-Richtlinie auf Ihren Cluster an:

1. Wenden Sie die PDB-Richtlinie mit kubectl an.

   kubectl apply -n mysql1 -f mysql-pdb-maxunavailable.yaml
   

2. Rufen Sie den Status des PDB auf.

   kubectl get poddisruptionbudgets -n mysql1 mysql-pdb -o yaml
   

   Im status-Abschnitt der Ausgabe sehen Sie sich die Anzahl der Pods currentHealthy und desiredHealthy an. Die Ausgabe sieht in etwa so aus:

   status:
   ...
     currentHealthy: 3
     desiredHealthy: 2
     disruptionsAllowed: 1
     expectedPods: 3
   ...
   

Upgrade der MySQL-Binärdateien planen

Kubernetes und GKE bieten Features zur Vereinfachung von Upgrades der MySQL-Binärdatei. Sie müssen jedoch einige Vorgänge ausführen, um sich auf die Upgrades vorzubereiten.

Beachten Sie die folgenden Überlegungen, bevor Sie mit dem Upgrade beginnen:

• Upgrades sollten zuerst in einer Testumgebung durchgeführt werden. Für Produktionssysteme sollten Sie weitere Tests in einer Vorproduktionsumgebung machen.
• Bei einigen binären Releases ist kein Downgrade der Version mehr möglich, nachdem ein Upgrade durchgeführt wurde. Nehmen Sie sich die Zeit, um die Auswirkungen eines Upgrades zu verstehen.
• Replikationsquellen können auf eine neuere Version repliziert werden. Das Kopieren von einer neueren Version in eine ältere wird jedoch in der Regel nicht unterstützt.
• Erstellen Sie vor der Bereitstellung der aktualisierten Version eine vollständige Datenbanksicherung.
• Beachten Sie dabei den flüchtigen Charakter von Kubernetes-Pods. Jeder Konfigurationsstatus, der vom Pod gespeichert und nicht im nichtflüchtigen Volume enthalten ist, geht verloren, wenn der Pod noch einmal bereitgestellt wird.
• Verwenden Sie für binäre MySQL-Upgrades dieselbe PDB, eine Aktualisierungsstrategie für Knotenpools und die zuvor beschriebenen Prüfungen.

In einer Produktionsumgebung sollten Sie folgende Best Practices befolgen:

• Erstellen Sie ein Container-Image mit der neuen Version von MySQL.
• Speichern Sie die Anleitung zum Erstellen des Images in einem Quellkontroll-Repository.
• Verwenden Sie eine automatisierte Pipeline zum Erstellen und Testen von Images wie Cloud Build und speichern Sie die Binärdatei des Images in einer Image-Registry, z. B. Artifact Registry.

Zur Vereinfachung dieser Anleitung werden Sie kein Container-Image erstellen und beibehalten, sondern öffentliche MySQL-Images verwenden.

Aktualisierte MySQL-Binärdatei bereitstellen

Zum Upgrade der MySQL-Binärdateien führen Sie einen deklarativen Befehl aus, mit dem die Image-Version der StatefulSet-Ressource geändert wird. GKE führt die erforderlichen Schritte aus, um den aktuellen Pod zu beenden, einen neuen Pod mit dem aktualisierten Binärprogramm bereitzustellen und den nichtflüchtigen Speicher an den neuen Pod anzuhängen.

1. Prüfen Sie, ob das PDB erstellt wurde.

   kubectl get poddisruptionbudgets -n mysql1
   

2. Liste der StatefulSets abrufen

   kubectl get statefulsets -n mysql1
   

3. Rufen Sie die Liste der laufenden Pods mit dem app-Label ab.

   kubectl get pods --selector=app=mysql -n mysql1
   

4. Aktualisieren Sie das MySQL-Image im zustandsorientierten Satz.

   kubectl  -n mysql1 \
       set image statefulset/dbc1 \
       mysql=mysql/mysql-server:8.0.30
   

   Die Ausgabe sieht in etwa so aus:

   statefulset.apps/mysql image updated
   

5. Prüfen Sie den Status der beendeten und der neuen Pods.

   kubectl get pods --selector=app=mysql -n mysql1
   

Upgrade der MySQL-Binärdateien validieren

Während des Upgrades können Sie den Status des Roll-outs, der neuen Pods und des vorhandenen Dienstes prüfen.

1. Bestätigen Sie das Upgrade mit dem Befehl rollout status.

   kubectl rollout status statefulset/dbc1 -n mysql1
   

   Die Ausgabe sieht in etwa so aus:

   partitioned roll out complete: 3 new pods have been updated...
   

2. Um die Image-Version zu prüfen, inspizieren Sie das zustandsorientierte Set.

   kubectl get statefulsets -o wide -n mysql1
   

   Die Ausgabe sieht in etwa so aus:

   NAME   READY   AGE   CONTAINERS   IMAGES
   dbc1   3/3     37m   mysql        mysql/mysql-server:8.0.30
   

3. Prüfen Sie den Clusterstatus.

   kubectl -n mysql1 \
        exec -it dbc1-0 -- \
          /bin/bash \
            -c 'mysqlsh \
            --uri="root:$MYSQL_ROOT_PASSWORD@dbc1-1.mysql.mysql1.svc.cluster.local" \
            --js \
            --execute "print(dba.getClusterSet().status({extended:1})); print(\"\\n\")"'
   

   Suchen Sie bei jeder Clusterinstanz in der Ausgabe nach den Status- und Versionswerten. Die Ausgabe sieht in etwa so aus:

   ...
     "status": "ONLINE",
     "version": "8.0.30"
   ...
   

Letztes App-Bereitstellungs-Rollback durchführen

Wenn Sie die Bereitstellung einer aktualisierten Binärversion wiederherstellen, wird der Rollout-Prozess rückgängig gemacht und es wird eine neue Gruppe von Pods mit der vorherigen Image-Version bereitgestellt.

Verwenden Sie den rollout undo-Befehl, um die Bereitstellung auf die vorherige Arbeitsversion zurückzusetzen:

kubectl rollout undo statefulset/dbc1 -n mysql1

Die Ausgabe sieht in etwa so aus:

statefulset.apps/dbc1 rolled back

Datenbankcluster horizontal skalieren

Um Ihren MySQL-InnoDB-Cluster horizontal zu skalieren, fügen Sie dem GKE-Cluster-Knotenpool zusätzliche Knoten hinzu (nur bei Verwendung von Standard), stellen zusätzliche MySQL-Instanzen bereit und fügen dann die einzelnen Instanzen dem vorhandenen MySQL-InnoDB-Cluster hinzu.

Knoten zum Standardcluster hinzufügen

Dieser Vorgang ist nicht erforderlich, wenn Sie einen Autopilot-Cluster verwenden.

Folgen Sie der nachstehenden Anleitung für Cloud Shell oder für die Google Cloud Console, um Ihrem Standardcluster Knoten hinzuzufügen. Eine detaillierte Anleitung finden Sie unter Größe eines Knotenpools ändern.

gcloud container clusters resize ${CLUSTER_NAME} \
     --node-pool default-pool \
     --num-nodes=8

MySQL-Pods zum primären Cluster hinzufügen

So stellen Sie zusätzliche MySQL-Pods bereit, um Ihren Cluster horizontal zu skalieren:

1. Aktualisieren Sie in Cloud Shell die Anzahl der Replikate im MySQL-Deployment von drei auf fünf Replikate.

   kubectl scale  -n mysql1 --replicas=5 -f c1-mysql.yaml
   

2. Prüfen Sie den Fortschritt der Bereitstellung.

   kubectl -n mysql1 get pods --selector=app=mysql -o wide
   

   Wenn Sie feststellen möchten, ob die Pods bereit sind, überwachen Sie das Deployment mit dem --watch-Flag. Wenn Sie Autopilot-Cluster verwenden und Pod Unschedulable-Fehler angezeigt werden, kann dies darauf hindeuten, dass GKE Knoten bereitstellt, um die zusätzlichen Pods bereitzustellen.

3. Gruppenreplikationseinstellungen für die neuen, dem Cluster hinzuzufügenden MySQL-Instanzen konfigurieren

   bash ../scripts/c1-clustersetup.sh 3 4
   

   Das Skript sendet die Befehle an die Instanzen, die auf den Pods mit den Ordinalzahlen 3 bis 4 ausgeführt werden.

4. Öffnen Sie MySQL Shell.

   kubectl -n mysql1 \
     exec -it dbc1-0 -- \
         /bin/bash \
           -c 'mysqlsh \
           --uri="root:$MYSQL_ROOT_PASSWORD@dbc1-0.mysql"'
   

5. Konfigurieren Sie die beiden neuen MySQL-Instanzen.

   dba.configureInstance('root:$MYSQL_ROOT_PASSWORD@dbc1-3.mysql', {password: os.getenv("MYSQL_ROOT_PASSWORD"),clusterAdmin: 'icadmin', clusterAdminPassword: os.getenv("MYSQL_ADMIN_PASSWORD")});
   dba.configureInstance('root:$MYSQL_ROOT_PASSWORD@dbc1-4.mysql', {password: os.getenv("MYSQL_ROOT_PASSWORD"),clusterAdmin: 'icadmin', clusterAdminPassword: os.getenv("MYSQL_ADMIN_PASSWORD")});
   

   Mit den Befehlen wird geprüft, ob die Instanz für die Verwendung von MySQL InnoDB Cluster richtig konfiguriert ist, und die erforderlichen Konfigurationsänderungen werden vorgenommen.

6. Fügen Sie dem primären Cluster eine der neuen Instanzen hinzu.

   cluster = dba.getCluster()
   cluster.addInstance('icadmin@dbc1-3.mysql', {password: os.getenv("MYSQL_ROOT_PASSWORD"), recoveryMethod: 'clone'});
   

7. Fügen Sie dem primären Cluster eine zweite neue Instanz hinzu.

   cluster.addInstance('icadmin@dbc1-4.mysql', {password: os.getenv("MYSQL_ROOT_PASSWORD"), recoveryMethod: 'clone'});
   

8. Rufen Sie den ClusterSet-Status ab, der auch den Clusterstatus enthält.

   clusterset = dba.getClusterSet()
   clusterset.status({extended: 1})
   

   Die Ausgabe sieht in etwa so aus:

   "domainName": "clusterset",
   "globalPrimaryInstance": "dbc1-0.mysql:3306",
   "metadataServer": "dbc1-0.mysql:3306",
   "primaryCluster": "mycluster",
   "status": "HEALTHY",
   "statusText": "All Clusters available."
   

9. Beenden Sie die MySQL-Shell.

   \q