Questa pagina è stata tradotta dall'API Cloud Translation.

Esegui il deployment di un cluster MySQL stateful su GKE

Autopilot Standard

Questo documento è rivolto ad amministratori di database, architetti cloud e professionisti delle operazioni interessati a eseguire il deployment di una topologia MySQL ad alta disponibilità su Google Kubernetes Engine.

Segui questo tutorial per scoprire come eseguire il deployment di un cluster InnoDB di MySQL e di un ClusterSet InnoDB di MySQL, oltre al middleware MySQL Router sul tuo cluster GKE e come eseguire gli upgrade.

Obiettivi

In questo tutorial imparerai a:

Crea ed esegui il deployment di un servizio Kubernetes con stato.
Esegui il deployment di un cluster MySQL InnoDB per l'alta disponibilità.
Esegui il deployment del middleware Router per il routing delle operazioni del database.
Esegui il deployment di un ClusterSet MySQL InnoDB per la tolleranza ai disastri.
Simula un failover del cluster MySQL.
Esegui un upgrade della versione di MySQL.

Le sezioni seguenti descrivono l'architettura della soluzione che creerai in questo tutorial.

Cluster InnoDB di MySQL

Nel tuo cluster GKE regionale, utilizzando un StatefulSet, esegui il deployment di un'istanza del database MySQL con la denominazione e la configurazione necessarie per creare un cluster MySQL InnoDB. Per fornire tolleranza di errore e alta disponibilità, esegui il deployment di tre pod di istanze database. In questo modo, la maggior parte dei pod in zone diverse è disponibile in qualsiasi momento per un'elezione principale riuscita utilizzando un protocollo di consenso e il tuo cluster MySQL InnoDB è tollerante ai singoli guasti zonali.

Diagramma dell'architettura che mostra la relazione tra applicazioni, router MySQL e cluster MySQL — **Figura 1**: architettura di esempio di un singolo cluster InnoDB MySQL

Una volta disegnato, designa un pod come istanza principale per gestire sia le operazioni di lettura che quelle di scrittura. Gli altri due pod sono repliche secondarie di sola lettura. Se l'istanza principale presenta un errore di infrastruttura, puoi promuovere uno di questi due pod di replica in modo che diventi quello principale.

In uno spazio dei nomi separato, esegui il deployment di tre pod router MySQL per fornire il routing delle connessioni al fine di migliorare la resilienza. Invece di connettersi direttamente al servizio di database, le applicazioni si connettono ai pod del router MySQL. Ogni pod router è a conoscenza dello stato e dello scopo di ogni pod del cluster MySQL InnoDB e inoltra le operazioni dell'applicazione al rispettivo pod in stato di salute. Lo stato del routing viene memorizzato nella cache nei pod del router e aggiornato dai metadati del cluster memorizzati su ogni nodo del cluster MySQL InnoDB. In caso di errore di un'istanza, il router regola il routing della connessione a un'istanza attiva.

MySQL InnoDB ClusterSet

Puoi creare un ClusterSet InnoDB di MySQL da un cluster InnoDB di MySQL iniziale. In questo modo puoi aumentare la tolleranza ai disastri se il cluster principale non è più disponibile.

Il diagramma mostra come i cluster InnoDB MySQL principali e di replica vengono mantenuti sincronizzati tramite la replica asincrona. — **Figura 2**: esempio di architettura ClusterSet multi-regione che contiene un cluster principale e un cluster di replica

Se l'istanza principale del cluster InnoDB di MySQL non è più disponibile, puoi promuovere un cluster di replica nel ClusterSet a principale. Quando utilizzi il middleware MySQL Router, la tua applicazione non deve monitorare lo stato dell'istanza del database principale. Il routing viene modificato in modo da inviare le connessioni al nuovo primario dopo l'elezione. Tuttavia, è tua responsabilità assicurarti che le applicazioni che si connettono al middleware MySQL Router seguano le best practice per la resilienza, in modo che le connessioni vengano riprovate se si verifica un errore durante il failover del cluster.

Costi

In questo documento utilizzi i seguenti componenti fatturabili di Google Cloud:

Per generare una stima dei costi basata sull'utilizzo previsto, utilizza il Calcolatore prezzi. I nuovi utenti di Google Cloud potrebbero essere idonei per una prova gratuita.

Al termine delle attività descritte in questo documento, puoi evitare la fatturazione continua eliminando le risorse che hai creato. Per ulteriori informazioni, consulta la sezione Pulizia.

Prima di iniziare

Configura il progetto

Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.

In the Google Cloud console, on the project selector page, click Create project to begin creating a new Google Cloud project.

Go to project selector

Make sure that billing is enabled for your Google Cloud project.

Enable the GKE API.

Enable the API

In the Google Cloud console, on the project selector page, click Create project to begin creating a new Google Cloud project.

Go to project selector

Make sure that billing is enabled for your Google Cloud project.

Enable the GKE API.

Enable the API

Configurare i ruoli

Grant roles to your user account. Run the following command once for each of the following IAM roles: role/storage.objectViewer, role/logging.logWriter, role/artifactregistry.Admin, roles/container.clusterAdmin, role/container.serviceAgent, roles/serviceusage.serviceUsageAdmin, roles/iam.serviceAccountAdmin
```
gcloud projects add-iam-policy-binding PROJECT_ID --member="user:USER_IDENTIFIER" --role=ROLE
```
- Replace PROJECT_ID with your project ID.
- Replace USER_IDENTIFIER with the identifier for your user account. For example, user:myemail@example.com.
- Replace ROLE with each individual role.

Configura l'ambiente

In questo tutorial utilizzerai Cloud Shell per gestire le risorse ospitate su Google Cloud. Cloud Shell è preinstallato con Docker e con le interfacce a riga di comando kubectl e gcloud.

Per utilizzare Cloud Shell per configurare l'ambiente:

Imposta le variabili di ambiente.
```
export PROJECT_ID=PROJECT_ID
export CLUSTER_NAME=gkemulti-west
export REGION=COMPUTE_REGION
```
Sostituisci i seguenti valori:
- PROJECT_ID: il tuo ID progetto Google Cloud.
- COMPUTE_REGION: la tua regione Compute Engine. Per questo tutorial, la regione è us-west1. In genere, è preferibile scegliere una regione vicina a te.

Imposta le variabili di ambiente predefinite.

 gcloud config set project PROJECT_ID
 gcloud config set compute/region COMPUTE_REGION

Clona il repository di codice.

git clone https://github.com/GoogleCloudPlatform/kubernetes-engine-samples

Passa alla directory di lavoro.

cd kubernetes-engine-samples/databases/gke-stateful-mysql/kubernetes

Crea un cluster GKE

In questa sezione crei un cluster GKE regionale. A differenza di un cluster di zona, il piano di controllo di un cluster a livello di regione viene replicato in più zone, pertanto un'interruzione in una singola zona non rende il piano di controllo non disponibile.

Per creare un cluster GKE:

Autopilot

In Cloud Shell, crea un cluster GKE Autopilot nella regione us-west1.

gcloud container clusters create-auto $CLUSTER_NAME \
    --region=$REGION

Recupera le credenziali del cluster GKE.

gcloud container clusters get-credentials $CLUSTER_NAME \
  --region=$REGION

Esegui il deployment di un servizio in tre zone.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: prepare-three-zone-ha
  labels:
    app: prepare-three-zone-ha
spec:
  replicas: 3
  selector:
    matchLabels:
      app: prepare-three-zone-ha
  template:
    metadata:
      labels:
        app: prepare-three-zone-ha
    spec:
      affinity:
        # Tell Kubernetes to avoid scheduling a replica in a zone where there
        # is already a replica with the label "app: prepare-three-zone-ha"
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - prepare-three-zone-ha
            topologyKey: "topology.kubernetes.io/zone"
      containers:
      - name: prepare-three-zone-ha
        image: busybox:latest
        command:
            - "/bin/sh"
            - "-c"
            - "while true; do sleep 3600; done"
        resources:
          limits:
            cpu: "500m"
            ephemeral-storage: "10Mi"
            memory: "0.5Gi"
          requests:
            cpu: "500m"
            ephemeral-storage: "10Mi"
            memory: "0.5Gi"

kubectl apply -f prepare-for-ha.yaml

Per impostazione predefinita, Autopilot esegue il provisioning delle risorse in due zone. Il deployment definito in prepare-for-ha.yaml garantisce che Autopilot esegui il provisioning dei nodi in tre zone del cluster impostando replicas:3, podAntiAffinity con requiredDuringSchedulingIgnoredDuringExecution e topologyKey: "topology.kubernetes.io/zone".

Controlla lo stato del deployment.

kubectl get deployment prepare-three-zone-ha --watch

Quando vedi tre pod nello stato di attesa, annulla questo comando con CTRL+C. L'output è simile al seguente:

NAME                    READY   UP-TO-DATE   AVAILABLE   AGE
prepare-three-zone-ha   0/3     3            0           9s
prepare-three-zone-ha   1/3     3            1           116s
prepare-three-zone-ha   2/3     3            2           119s
prepare-three-zone-ha   3/3     3            3           2m16s

Esegui questo script per verificare che i pod siano stati dipartiti su tre zone.

bash ../scripts/inspect_pod_node.sh default

Ogni riga dell'output corrisponde a un pod e la seconda colonna indica la zona cloud. L'output è simile al seguente:

gk3-gkemulti-west1-default-pool-eb354e2d-z6mv us-west1-b prepare-three-zone-ha-7885d77d9c-8f7qb
gk3-gkemulti-west1-nap-25b73chq-739a9d40-4csr us-west1-c prepare-three-zone-ha-7885d77d9c-98fpn
gk3-gkemulti-west1-default-pool-160c3578-bmm2 us-west1-a prepare-three-zone-ha-7885d77d9c-phmhj

Standard

In Cloud Shell, crea un cluster GKE Standard nella regione us-west1.

gcloud container clusters create $CLUSTER_NAME \
  --region=$REGION \
  --machine-type="e2-standard-2" \
  --disk-type="pd-standard" \
  --num-nodes="5"

Recupera le credenziali del cluster GKE.

gcloud container clusters get-credentials $CLUSTER_NAME \
  --region=$REGION

Esegui il deployment di StatefulSet di MySQL

In questa sezione esegui il deployment di un StatefulSet MySQL. Ogni StatefulSet consiste di tre repliche MySQL.

Per eseguire il deployment del StatefulSet MySQL:

Crea uno spazio dei nomi per il StatefulSet.
```
kubectl create namespace mysql1
```

Crea il secret MySQL.

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

La password viene dispiattata con ogni pod e utilizzata dagli script di gestione e dai comandi per il dispiacciamento di MySQL InnoDB Cluster e ClusterSet in questo tutorial.

Crea la classe 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
```
Questa classe di archiviazione utilizza il tipo di Persistent Disk pd-balanced che bilancia prestazioni e costi. Il campo volumeBindingMode è impostato su WaitForFirstConsumer, il che significa che GKE ritarda il provisioning di un PersistentVolume fino alla creazione del pod. Questa impostazione garantisce che il provisioning del disco venga eseguito nella stessa zona in cui è pianificato il pod.

Esegui il deployment del StatefulSet dei pod dell'istanza MySQL.

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

Questo comando esegue il deployment del StatefulSet composto da tre repliche. In questo tutorial, il cluster MySQL principale viene disegnato in tre zone in us-west1. L'output è simile al seguente:

service/mysql created
statefulset.apps/dbc1 created

In questo tutorial, le richieste e i limiti delle risorse sono impostati su valori minimi per risparmiare sui costi. Quando pianifichi un carico di lavoro di produzione, assicurati di impostare questi valori in modo appropriato in base alle esigenze della tua organizzazione.

Verifica che l'oggetto StatefulSet sia stato creato correttamente.
```
kubectl get statefulset -n mysql1 --watch
```
La preparazione del StatefulSet può richiedere circa 10 minuti.
Quando tutti e tre i pod sono in stato di attesa, esci dal comando utilizzando Ctrl+C. Se visualizzate errori PodUnscheduleable a causa di CPU o memoria insufficienti, attendi qualche minuto affinché il piano di controllo venga ridimensionato per adattarsi al grande carico di lavoro.

L'output è simile al seguente:
```
NAME   READY   AGE
dbc1   1/3     39s
dbc1   2/3     50s
dbc1   3/3     73s
```
Per ispezionare il posizionamento dei pod sui nodi del cluster GKE, esegui questo script:
```
bash ../scripts/inspect_pod_node.sh mysql1 mysql
```
L'output mostra il nome del pod, il nome del nodo GKE e la zona in cui è stato eseguito il provisioning del nodo ed è simile al seguente:
```
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
```
Le colonne nell'output rappresentano rispettivamente il nome host, la zona cloud e il nome del pod.

Il criterio topologySpreadConstraints nella specifica StatefulSet (c1-mysql.yaml) indica allo scheduler di posizionare i pod in modo uniforme nel dominio in errore (topology.kubernetes.io/zone).

Il criterio podAntiAffinity impone il vincolo che i pod non devono essere collocati sullo stesso nodo del cluster GKE (kubernetes.io/hostname). Per i pod delle istanze MySQL, questo criterio comporta il loro deployment in modo uniforme nelle tre zone della regione Google Cloud. Questo posizionamento consente la disponibilità elevata del cluster MySQL InnoDB posizionando ogni istanza di database in un dominio in errore separato.

Prepara il cluster InnoDB MySQL principale

Per configurare un cluster MySQL InnoDB:

Nel terminale Cloud Shell, imposta le configurazioni della replica di gruppo per le istanze MySQL da aggiungere al cluster.

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

Lo script si connette da remoto a ciascuna delle tre istanze MySQL per impostare e mantenere le seguenti variabili di ambiente:

group_replication_ip_allowlist: consente all'istanza all'interno del cluster di connettersi a qualsiasi istanza del gruppo.
binlog_transaction_dependency_tracking='WRITESET': consente transazioni parallelizzate che non entrano in conflitto.

Nelle versioni di MySQL precedenti alla 8.0.22, utilizza group_replication_ip_whitelist instead of group_replication_ip_allowlist.

Apri un secondo terminale per non dover creare una shell per ogni pod.

Connettiti a MySQL Shell nel pod 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"'

Verifica la lista consentita della replica di gruppo MySQL per la connessione ad altre istanze.

\sql SELECT @@group_replication_ip_allowlist;

L'output è simile al seguente:

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

Verifica che server-id sia univoco in ogni istanza.

\sql SELECT @@server_id;

L'output è simile al seguente:

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

Configura ogni istanza per l'utilizzo di MySQL InnoDB Cluster e crea un account amministrativo su ogni istanza.

\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")});

Affinché il cluster MySQL InnoDB funzioni correttamente, tutte le istanze devono avere lo stesso nome utente e la stessa password. Ogni comando produce un output simile al seguente:

...

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.

Verifica che l'istanza sia pronta per essere utilizzata in un cluster InnoDB di MySQL.

dba.checkInstanceConfiguration()

L'output è simile al seguente:

...

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

{
    "status": "ok"
}

Se vuoi, puoi connetterti a ogni istanza MySQL e ripetere questo comando. Ad esempio, esegui questo comando per controllare lo stato dell'istanza dbc1-1:

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()"'

Crea il cluster InnoDB MySQL principale

Successivamente, crea il cluster MySQL InnoDB utilizzando il comando MySQL AdmincreateCluster. Inizia con l'istanza dbc1-0, che sarà l'istanza principale del cluster, quindi aggiungi altre due repliche al cluster.

Per inizializzare il cluster InnoDB di MySQL:

Crea il cluster InnoDB di MySQL.

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

L'esecuzione del comando createCluster attiva queste operazioni:

Esegui il deployment dello schema dei metadati.
Verifica che la configurazione sia corretta per la replica di gruppo.
Registrala come istanza iniziale del nuovo cluster.
Crea gli account interni necessari, ad esempio l'account utente di replica.
Avvia la replica di gruppo.

Questo comando inizializza un cluster InnoDB MySQL con l'host dbc1-0 come primario. Il riferimento al cluster viene memorizzato nella variabile cluster.

L'output è simile al seguente:

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.

Aggiungi la seconda istanza al cluster.

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

Aggiungi l'istanza rimanente al cluster.

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

L'output è simile al seguente:

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

Verifica lo stato del cluster.

cluster.status()

Questo comando mostra lo stato del cluster. La topologia è composta da tre host, un'istanza principale e due secondarie. In alternativa, puoi chiamarecluster.status({extended:1}).

L'output è simile al seguente:

{
    "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"
}

Se vuoi, puoi chiamare cluster.status({extended:1}) per ottenere ulteriori dettagli sullo stato.

Crea un database di esempio

Per creare un database di esempio:

Crea un database e carica i dati al suo interno.

\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) );

Inserisci dati di esempio nel database. Per inserire i dati, devi essere connesso all'istanza principale del cluster.

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

Verifica che la tabella contenga le tre righe inserite nel passaggio precedente.

SELECT * FROM loan;

L'output è simile al seguente:

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

Crea un ClusterSet InnoDB MySQL

Puoi creare un ClusterSet MySQL InnoDB per gestire la replica dal cluster principale ai cluster di replica utilizzando un canale di replica ClusterSet dedicato.

Un ClusterSet MySQL InnoDB offre resilienza ai disastri per i deployment di cluster MySQL InnoDB collegando un cluster MySQL InnoDB principale a una o più repliche di se stesso in posizioni alternative, ad esempio in più zone e regioni.

Se hai chiuso MySQL Shell, crea una nuova shell eseguendo questo comando in un nuovo terminale Cloud Shell:

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

Per creare un ClusterSet InnoDB MySQL:

Nel terminale MySQL Shell, ottieni un oggetto cluster.
```
\js
cluster=dba.getCluster()
```
L'output è simile al seguente:
```
<Cluster:mycluster>
```

Inizializza un ClusterSet InnoDB MySQL con il cluster InnoDB MySQL esistente memorizzato nell'oggetto cluster come principale.

clusterset=cluster.createClusterSet('clusterset')

L'output è simile al seguente:

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>

Controlla lo stato del tuo MySQL InnoDB ClusterSet.

clusterset.status()

L'output è simile al seguente:

{
    "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."
}

Se vuoi, puoi chiamare clusterset.status({extended:1}) per ottenere ulteriori dettagli sullo stato, incluse informazioni sul cluster.

Esci da MySQL Shell.
```
\q
```

Esegui il deployment di un router MySQL

Puoi eseguire il deployment di un router MySQL per indirizzare il traffico delle applicazioni client ai cluster appropriati. Il routing si basa sulla porta di connessione dell'applicazione che esegue un'operazione di database:

Le scritture vengono inoltrate all'istanza Cluster principale nel ClusterSet principale.
Le letture possono essere inoltrate a qualsiasi istanza del cluster principale.

Quando avvii un router MySQL, viene eseguito il bootstrap in base al deployment del cluster MySQL InnoDB. Le istanze MySQL Router collegate al ClusterSet MySQL InnoDB sono a conoscenza di eventuali switchover controllati o failover di emergenza e indirizzano il traffico al nuovo cluster principale.

Per eseguire il deployment di un router MySQL:

Nel terminale Cloud Shell, esegui il deployment di MySQL Router.

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

L'output è simile al seguente:

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

Controlla l'idoneità del deployment di MySQL Router.
```
kubectl -n mysql1 get deployment mysql-router --watch
```
Quando tutti e tre i pod sono pronti, l'output è simile al seguente:
```
NAME           READY   UP-TO-DATE   AVAILABLE   AGE
mysql-router   3/3     3            0           3m36s
```
Se nella console viene visualizzato un errore PodUnschedulable, attendi un paio di minuti mentre GKE esegue il provisioning di altri nodi. Aggiorna e dovresti vedere 3/3 OK.
Avvia MySQL Shell su qualsiasi membro del cluster esistente.
```
kubectl -n mysql1 exec -it dbc1-0 -- \
    /bin/bash -c 'mysqlsh --uri="root:$MYSQL_ROOT_PASSWORD@dbc1-0.mysql"'
```
Questo comando si connette al pod dbc1-0, quindi avvia una shell collegata all'istanza MySQL dbc1-0.

Verifica la configurazione del router.

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

L'output è simile al seguente:

{
  "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::": {
      ...
    }
  }
}

Esci da MySQL Shell.
```
\q
```

Esegui questo script per ispezionare il posizionamento dei pod del router MySQL.

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

Lo script mostra il posizionamento dei nodi e delle zone cloud di tutti i pod nello spazio dei nomi mysql1, dove l'output è simile al seguente:

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

Puoi osservare che i pod router MySQL sono distribuiti equamente tra le zone, ovvero non sono posizionati sullo stesso nodo di un pod MySQL o sullo stesso nodo di un altro pod router MySQL.

Gestire gli upgrade di GKE e MySQL InnoDB Cluster

Gli aggiornamenti sia per MySQL sia per Kubernetes vengono rilasciati con una cadenza regolare. Segui le best practice operative per aggiornare regolarmente il tuo ambiente software. Per impostazione predefinita, GKE gestisce gli upgrade dei cluster e dei pool di nodi per te. Kubernetes e GKE forniscono anche funzionalità aggiuntive per facilitare gli upgrade del software MySQL.

Pianifica gli upgrade di GKE

Puoi adottare misure proattive e impostare configurazioni per ridurre i rischi e favorire un upgrade più agevole del cluster quando esegui servizi con stato, tra cui:

Cluster standard: segui le best practice di GKE per l'upgrade dei cluster. Scegli una strategia di upgrade appropriata per assicurarti che gli upgrade vengano eseguiti durante il periodo del periodo di manutenzione:
- Scegli gli upgrade per picchi se l'ottimizzazione dei costi è importante e se i tuoi carichi di lavoro possono tollerare un arresto graduale in meno di 60 minuti.
- Scegli gli upgrade blu/verde se i tuoi carichi di lavoro sono meno tolleranti alle interruzioni e un aumento temporaneo dei costi dovuto a un utilizzo più elevato delle risorse è accettabile.
Per saperne di più, consulta Eseguire l'upgrade di un cluster che esegue un carico di lavoro stateful. L'upgrade dei cluster Autopilot viene eseguito automaticamente in base al canale di rilascio selezionato.
Utilizza i periodi di manutenzione per assicurarti che gli upgrade vengano eseguiti quando vuoi. Prima della periodo di manutenzione, assicurati che i backup del database siano riusciti.
Prima di consentire il traffico ai nodi MySQL di cui è stato eseguito l'upgrade, utilizza i probe di idoneità e di attività per assicurarti che siano pronti per il traffico.
Crea sonde che valutano se la replica è sincronizzata prima di accettare il traffico. Questa operazione può essere eseguita tramite script personalizzati, a seconda della complessità e delle dimensioni del database.

Impostare un criterio del budget di interruzione dei pod (PDB)

Quando un cluster MySQL InnoDB è in esecuzione su GKE, deve essere sempre attivo un numero sufficiente di istanze per soddisfare il requisito del quorum.

In questo tutorial, dato un cluster MySQL di tre istanze, devono essere disponibili due istanze per formare un quorum. Un criterio PodDisruptionBudget ti consente di limitare il numero di pod che possono essere terminati in un determinato momento. Questo è utile sia per le operazioni in stato stazionario dei servizi stateful sia per gli upgrade dei cluster.

Per assicurarti che un numero limitato di pod venga interrotto contemporaneamente, imposta il PDB per il tuo carico di lavoro su maxUnavailable: 1. In questo modo, in qualsiasi momento dell'operazione del servizio, non è in esecuzione più di un pod.

Il seguente manifest dei criteri PodDisruptionBudget imposta il numero massimo di pod non disponibili su 1 per la tua applicazione MySQL.

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

Per applicare il criterio PDB al cluster:

Applica il criterio PDB utilizzando kubectl.

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

Visualizza lo stato del PDB.

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

Nella sezione status dell'output, controlla i conteggi dei pod currentHealthy e desiredHealthy. L'output è simile al seguente:

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

Pianifica gli upgrade dei file binari di MySQL

Kubernetes e GKE forniscono funzionalità per semplificare gli upgrade del codice binario di MySQL. Tuttavia, devi eseguire alcune operazioni per prepararti agli upgrade.

Tieni presente le seguenti considerazioni prima di iniziare la procedura di upgrade:

Gli upgrade devono essere eseguiti in un ambiente di test. Per i sistemi di produzione, devi eseguire ulteriori test in un ambiente di pre-produzione.
Per alcune release binarie, non puoi eseguire il downgrade della versione dopo aver eseguito un upgrade. Prenditi il tempo di comprendere le implicazioni di un upgrade.
Le origini di replica possono eseguire la replica in una versione più recente. Tuttavia, in genere la copia da una versione più recente a una precedente non è supportata.
Assicurati di disporre di un backup completo del database prima di eseguire il deployment della versione di cui è stato eseguito l'upgrade.
Tieni presente la natura effimera dei pod Kubernetes. Qualsiasi stato di configurazione memorizzato dal pod e non presente sul volume permanente andrà perso quando il pod verrà riappliato.
Per gli upgrade dei binari MySQL, utilizza la stessa strategia di aggiornamento del pool di nodi, la stessa PDB e gli stessi probe descritti in precedenza.

In un ambiente di produzione, devi seguire queste best practice:

Crea un'immagine container con la nuova versione di MySQL.
Mantieni le istruzioni di compilazione dell'immagine in un repository di controllo del codice sorgente.
Utilizza una pipeline di creazione e test delle immagini automatica come Cloud Build e memorizza il file binario dell'immagine in un registry delle immagini come Artifact Registry.

Per semplificare questo tutorial, non creerai e manterrai un'immagine del contenitore, ma utilizzerai le immagini MySQL pubbliche.

Esegui il deployment del file binario MySQL di cui è stato eseguito l'upgrade

Per eseguire l'upgrade del codice binario di MySQL, emetti un comando dichiarativo che modifica la versione dell'immagine della risorsa StatefulSet. GKE esegue i passaggi necessari per arrestare il pod corrente, eseguire il deployment di un nuovo pod con il programma binario di cui è stato eseguito l'upgrade e collegare il disco permanente al nuovo pod.

Verifica che il PDB sia stato creato.

kubectl get poddisruptionbudgets -n mysql1

Recupera l'elenco dei set stateful.
```
kubectl get statefulsets -n mysql1
```
Recupera l'elenco dei pod in esecuzione utilizzando l'etichetta app.
```
kubectl get pods --selector=app=mysql -n mysql1
```

Aggiorna l'immagine MySQL nell'insieme stateful.

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

L'output è simile al seguente:

statefulset.apps/mysql image updated

Controlla lo stato dei pod in fase di terminazione e dei nuovi pod.
```
kubectl get pods --selector=app=mysql -n mysql1
```

Convalida l'upgrade del file binario MySQL

Durante l'upgrade, puoi verificare lo stato dell'implementazione, dei nuovi pod e del servizio esistente.

Conferma l'upgrade eseguendo il comando rollout status.

kubectl rollout status statefulset/dbc1 -n mysql1

L'output è simile al seguente:

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

Conferma la versione dell'immagine controllando l'insieme stateful.

kubectl get statefulsets -o wide -n mysql1

L'output è simile al seguente:

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

Controlla lo stato del cluster.

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\")"'

Per ogni istanza del cluster, cerca i valori di stato e versione nell'output. L'output è simile al seguente:

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

Esegui il rollback dell'ultimo deployment dell'app

Quando ripristini il deployment di una versione binaria di cui è stato eseguito l'upgrade, il processo di implementazione viene annullato e viene eseguito il deployment di un nuovo insieme di pod con la versione dell'immagine precedente.

Per ripristinare il deployment alla versione precedente funzionante, utilizza il comando rollout undo:

kubectl rollout undo statefulset/dbc1 -n mysql1

L'output è simile al seguente:

statefulset.apps/dbc1 rolled back

Scala il cluster di database in orizzontale

Per eseguire il ridimensionamento orizzontale del cluster MySQL InnoDB, aggiungi altri nodi al pool di nodi del cluster GKE (obbligatorio solo se utilizzi Standard), esegui il deployment di altre istanze MySQL e poi aggiungi ogni istanza al cluster MySQL InnoDB esistente.

Aggiungere nodi al cluster standard

Questa operazione non è necessaria se utilizzi un cluster Autopilot.

Per aggiungere nodi al cluster standard, segui le istruzioni riportate di seguito per Cloud Shell o la console Google Cloud. Per la procedura dettagliata, consulta Ridimensionare un node pool.

gcloud

In Cloud Shell, ridimensiona il pool di nodi predefinito in modo da avere otto istanze in ogni gruppo di istanze gestite.

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

Console

Per aggiungere nodi al cluster standard:

Apri la pagina gkemulti-west1 Cluster nella console Google Cloud.
Seleziona Nodi e fai clic su Pool predefinito.
Scorri verso il basso fino a Gruppi di istanze.
Per ogni gruppo di istanze, ridimensiona il valore Number of nodes da 5 a 8 nodi.

Aggiungi pod MySQL al cluster principale

Per eseguire il deployment di pod MySQL aggiuntivi per scalare il cluster orizzontalmente:

In Cloud Shell, aggiorna il numero di repliche nel deployment MySQL da tre a cinque.
```
kubectl scale  -n mysql1 --replicas=5 -f c1-mysql.yaml
```
Verifica l'avanzamento del deployment.
```
kubectl -n mysql1 get pods --selector=app=mysql -o wide
```
Per determinare se i pod sono pronti, utilizza il flag --watch per monitorare il deployment. Se utilizzi i cluster Autopilot e visualizzi erroriPod Unschedulable, è possibile che GKE stia eseguendo il provisioning dei nodi per supportare i pod aggiuntivi.
Configura le impostazioni di replica dei gruppi per le nuove istanze MySQL da aggiungere al cluster
```
bash ../scripts/c1-clustersetup.sh 3 4
```
Lo script invia i comandi alle istanze in esecuzione sui pod con ordinali da 3 a 4.

Apri MySQL Shell.

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

Configura le due nuove istanze MySQL.

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")});

I comandi verificano se l'istanza è configurata correttamente per l'utilizzo di MySQL InnoDB Cluster e apportano le modifiche di configurazione necessarie.

Aggiungi una delle nuove istanze al cluster principale.

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

Aggiungi una seconda nuova istanza al cluster principale.

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

Ottieni lo stato del ClusterSet, che include anche lo stato del cluster.

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

L'output è simile al seguente:

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

Esci da MySQL Shell.
```
\q
```

Esegui la pulizia

Per evitare che al tuo account Google Cloud vengano addebitati costi relativi alle risorse utilizzate in questo tutorial, elimina il progetto che contiene le risorse oppure mantieni il progetto ed elimina le singole risorse.

Elimina il progetto

Il modo più semplice per evitare la fatturazione è eliminare il progetto che hai creato per il tutorial.

Attenzione: l'eliminazione di un progetto ha i seguenti effetti:

L'intero contenuto del progetto viene eliminato. Se hai utilizzato un progetto esistente per le attività descritte in questo documento, quando lo elimini elimini anche tutto il lavoro svolto nel progetto.
Gli ID progetto personalizzati non sono più disponibili. Quando hai creato questo progetto, potresti aver creato un ID progetto personalizzato che vuoi utilizzare in futuro. Per conservare gli URL che utilizzano l'ID progetto, ad esempio un appspot.com URL, elimina le risorse selezionate all'interno del progetto anziché eliminare l'intero progetto.

Se intendi esplorare più architetture, tutorial o guide rapide, il riuso dei progetti può aiutarti a non superare i limiti di quota.

Delete a Google Cloud project:

gcloud projects delete PROJECT_ID

Passaggi successivi

Scopri di più su come l'integrazione di MySQL di Google Cloud Observability raccoglie le metriche relative alle prestazioni di InnoDB.
Scopri di più su Backup per GKE, un servizio per il backup e il ripristino dei carichi di lavoro in GKE.
Esplora i volumi permanenti in modo più dettagliato.