Implantar um cluster MySQL com estado no GKE

Criar um cluster do GKE

Nesta seção, você cria um cluster regional do GKE. Ao contrário de um cluster zonal, o plano de controle de um cluster regional é replicado em várias zonas. Portanto, uma falha temporária em uma única zona não torna o plano de controle indisponível.

Para criar um cluster do GKE, siga estas etapas:

Implantar os StatefulSets do MySQL

Nesta seção, você implantará um StatefulSet do MySQL. Cada StatefulSet consiste em três réplicas do MySQL.

Para implantar o StatefulSet do MySQL, siga estas etapas:

1. Crie um namespace para o StatefulSet.

   kubectl create namespace mysql1
   

2. Crie o secret do 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
   

   Neste tutorial, a senha é implantada a cada pod e usada por scripts e comandos de gerenciamento para o cluster do MySQL InnoDB e a implantação do ClusterSet.

3. Crie o 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
   

   Essa classe de armazenamento usa o tipo de disco permanente pd-balanced que equilibra desempenho e custo. O campo volumeBindingMode está definido como WaitForFirstConsumer, o que significa que o GKE atrasa o provisionamento de um PersistentVolume até que o pod seja criado. Essa configuração garante que o disco seja provisionado na mesma zona em que o pod está programado.

4. Implante o StatefulSet dos pods de instância do 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
   

   Esse comando implanta o StatefulSet composto por três réplicas. Neste tutorial, o cluster principal do MySQL é implantado em três zonas em us-west1. O resultado será assim:

   service/mysql created
   statefulset.apps/dbc1 created
   

   Neste tutorial, os limites de recursos e as solicitações são definidos como valores mínimos para economizar custos. Ao planejar uma carga de trabalho de produção, defina esses valores adequadamente para as necessidades da sua organização.

5. Verifique se o StatefulSet foi criado.

   kubectl get statefulset -n mysql1 --watch
   

   Pode levar cerca de 10 minutos para o SatefulSet ficar pronto.

6. Quando os três pods estiverem em estado pronto, saia do comando usando Ctrl+C. Se você vir erros PodUnscheduleable devido à CPU ou memória insuficientes, aguarde alguns minutos para que o plano de controle seja redimensionado a fim de acomodar a carga de trabalho grande.

   O resultado será assim:

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

7. Para inspecionar o posicionamento dos pods nos nós do cluster do GKE, execute este script:

   bash ../scripts/inspect_pod_node.sh mysql1 mysql
   

   A saída mostra o nome do pod, o nome do nó do GKE e a zona em que o nó é provisionado e é semelhante ao seguinte:

   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
   

   As colunas na saída representam o nome do host, a zona da nuvem e o nome do pod, respectivamente.

   A política topologySpreadConstraints na especificação do StatefulSet (c1-mysql.yaml) direciona o programador para colocar os pods de maneira uniforme no domínio de falha (topology.kubernetes.io/zone).

   A política podAntiAffinity aplica a restrição que exige que os pods não sejam colocados no mesmo nó de cluster do GKE (kubernetes.io/hostname). Para os pods de instância do MySQL, essa política resulta na implantação uniforme dos pods nas três zonas da região do Google Cloud. Com esse posicionamento, você terá alta disponibilidade do cluster do MySQL InnoDB colocando cada instância de banco de dados em um domínio de falha separado.

Preparar o cluster principal do MySQL InnoDB

Para configurar um cluster do InnoDB do MySQL, siga estas etapas:

1. No terminal do Cloud Shell, defina as configurações de replicação de grupo para que as instâncias do MySQL sejam adicionadas ao seu 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

   O script se conecta remotamente a cada uma das três instâncias do MySQL para definir e manter as seguintes variáveis de ambiente:

   • group_replication_ip_allowlist: permite que a instância do cluster se conecte a qualquer instância do grupo.
   • binlog_transaction_dependency_tracking='WRITESET': permite transações paralelas que não entrem em conflito.

   Nas versões do MySQL anteriores à 8.0.22, use group_replication_ip_whitelist em vez de group_replication_ip_allowlist.

2. Abra um segundo terminal para que não seja necessário criar um shell para cada pod.

3. Conecte-se ao MySQL Shell no 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"'
   

4. Verifique a lista de permissões de replicação do grupo do MySQL para se conectar a outras instâncias.

   \sql SELECT @@group_replication_ip_allowlist;
   

   O resultado será assim:

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

5. Verifique se o server-id é exclusivo em cada uma das instâncias.

   \sql SELECT @@server_id;
   

   O resultado será assim:

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

6. Configurar cada instância para uso do cluster do InnoDB do MySQL e criar uma conta de administrador em cada instância.

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

   Todas as instâncias precisam ter o mesmo nome de usuário e senha para que o cluster do InnoDB do MySQL funcione corretamente. Cada comando produz um resultado semelhante a este:

   ...
   
   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. Verifique se a instância está pronta para ser usada em um cluster do MySQL InnoDB.

   dba.checkInstanceConfiguration()
   

   O resultado será assim:

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

   Também é possível se conectar a cada instância do MySQL e repetir esse comando. Por exemplo, execute este comando para verificar o status da instância 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()"'
   

Criar o cluster principal do MySQL InnoDB

Em seguida, crie o cluster do MySQL InnoDB usando o comando createCluster do MySQL Admin. Comece com a instância dbc1-0, que será a instância principal do cluster e, em seguida, adicione duas réplicas adicionais ao cluster.

Para inicializar o cluster do MySQL InnoDB, siga estas etapas:

1. Criar o cluster do MySQL InnoDB

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

   A execução do comando createCluster aciona estas operações:

   • Implantar o esquema de metadados.
   • Verifique se a configuração está correta para replicação de grupos.
   • Registre-o como a instância de origem do novo cluster.
   • Crie as contas internas necessárias, como a conta de usuário de replicação.
   • Inicie a replicação de grupo.

   Esse comando inicializa um cluster do MySQL InnoDB com o host dbc1-0 como principal. A referência do cluster é armazenada na variável de cluster.

   A resposta será semelhante a:

   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. Adicione a segunda instância ao cluster.

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

3. Adicionar a instância restante ao cluster.

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

   O resultado será assim:

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

4. Verifique o status do cluster.

   cluster.status()
   

   Esse comando mostra o status do cluster. A topologia consiste em três hosts, uma instância primária e duas secundárias. Se quiser, chame cluster.status({extended:1}).

   O resultado será assim:

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

   Como alternativa, é possível chamar cluster.status({extended:1}) para ver mais detalhes do status.

Criar um banco de dados de exemplo

Para criar um banco de dados de amostra, siga estas etapas:

1. Crie um banco de dados e carregar dados nele.

   \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. Insira dados de amostra no banco de dados. Para inserir dados, é necessário estar conectado à instância principal do cluster.

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

3. Verifique se a tabela contém as três linhas inseridas na etapa anterior.

   SELECT * FROM loan;
   

   O resultado será assim:

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

Criar um ClusterSet do MySQL InnoDB

É possível criar um ClusterSet MySQL InnoDB para gerenciar a replicação do cluster principal para os clusters de réplica, usando um canal de replicação dedicado do ClusterSet.

Um MySQLInnoDB ClusterSet fornece tolerância a desastres para implantações de clusters do MySQL InnoDB vinculando um cluster MySQL primário InnoDB a uma ou mais réplicas próprias em locais alternativos, como várias zonas e várias regiões.

Se você tiver fechado o MySQL Shell, crie um novo shell executando este comando em um novo terminal do 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"'

Para criar um ClusterInnoDB MySQLSet, siga estas etapas:

1. No terminal do MySQL Shell, consiga um objeto de cluster.

   \js
   cluster=dba.getCluster()
   

   O resultado será assim:

   <Cluster:mycluster>
   

2. Inicialize um cluster do MySQL InnoDB com o cluster do InnoDB do MySQL armazenado no objeto do cluster como principal.

   clusterset=cluster.createClusterSet('clusterset')
   

   O resultado será assim:

   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. Verifique o status do ClusterSet do MySQL InnoDB.

   clusterset.status()
   

   O resultado será assim:

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

   Opcionalmente, é possível chamar clusterset.status({extended:1}) para receber mais detalhes sobre o status, incluindo informações sobre o cluster.

4. Saia do MySQL Shell.

   \q
   

Implantar um roteador MySQL

É possível implantar um roteador MySQL para direcionar o tráfego de aplicativos do cliente para os clusters adequados. O roteamento é baseado na porta de conexão do aplicativo que emite uma operação de banco de dados:

• As gravações são roteadas para a instância do cluster principal no ClusterSet principal.
• As leituras podem ser roteadas para qualquer instância no cluster principal.

Quando você inicia um roteador MySQL, ele é inicializado na implantação do ClusterSet do MySQL InnoDB. As instâncias do roteador do MySQL conectadas com o MySQLInnoDB ClusterSet estão cientes das mudanças controladas ou de failovers de emergência e do tráfego direto para o novo cluster principal.

Para implantar um roteador MySQL, siga estas etapas:

1. No terminal do Cloud Shell, implante o roteador do MySQL.

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

   O resultado será assim:

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

2. Verifique se a implantação do MySQL Roteador está pronta.

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

   Quando os três pods estiverem prontos, a saída vai ser semelhante a esta:

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

   Se você vir um erro PodUnschedulable no console, aguarde um ou dois minutos enquanto o GKE provisiona mais nodes. Atualize e você verá 3/3 OK.

3. Inicie o MySQL Shell em qualquer membro do cluster atual.

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

   Esse comando se conecta ao pod dbc1-0 e inicia um shell conectado à instância do MySQL de dbc1-0.

4. Verifique a configuração do roteador.

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

   O resultado será assim:

   {
     "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. Saia do MySQL Shell.

   \q
   

6. Execute esse script para inspecionar o posicionamento dos pods do MySQL Router.

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

   O script mostra o nó e a colocação da zona do Cloud de todos os pods no namespace mysql1, em que a saída é semelhante a esta:

   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
   

   É possível observar que os pods do MySQL Router estão distribuídos igualmente entre as zonas. Ou seja, não é colocado no mesmo node que um pod do MySQL ou no mesmo nó de outro pod do roteador do MySQL.

Gerenciar upgrades de clusters do GKE e do MySQL InnoDB

As atualizações para MySQL e Kubernetes são lançadas regularmente. Siga as práticas recomendadas operacionais para atualizar o ambiente de software regularmente. Por padrão, o GKE gerencia os upgrades de clusters e pools de nodes para você. O Kubernetes e o GKE também oferecem recursos adicionais para facilitar os upgrades de software do MySQL.

Plano para upgrades do GKE

É possível tomar medidas proativas e definir configurações para reduzir os riscos e facilitar um upgrade mais tranquilo do cluster quando estiver executando serviços com estado, incluindo:

• Clusters padrão: siga as práticas recomendadas do GKE para fazer upgrade de clusters. Escolha uma estratégia de upgrade apropriada para garantir que os upgrades aconteçam durante o período da janela de manutenção:

  • Escolha upgrades súbitos se a otimização de custos for importante e se as cargas de trabalho estiverem tolerar um encerramento otimizado em menos de 60 minutos.
  • Escolha upgrades azul-verde se as cargas de trabalho forem menos tolerantes a interrupções e um aumento temporário do custo devido ao maior uso de recursos for aceitável.

  Para saber mais, consulte Fazer upgrade de um cluster que executa uma carga de trabalho com estado. Os clusters do Autopilot são atualizados automaticamente, com base no canal de lançamento que você selecionou.

• Use as janelas de manutenção para garantir que os upgrades aconteçam quando você quiser. Antes da janela de manutenção, verifique se os backups do banco de dados foram concluídos.

• Antes de permitir o tráfego para os nodes do MySQL atualizados, use as Sondagens de prontidão e atividades para verificar se estão prontas para tráfego.

• Crie sondagens que avaliem se a replicação está sincronizada antes de aceitar o tráfego. Isso pode ser feito com scripts personalizados, dependendo da complexidade e da escala do seu banco de dados.

Definir uma política de orçamento de interrupção de pod (PDB)

Quando um cluster do MySQL InnoDB está em execução no GKE, é preciso ter um número suficiente de instâncias em execução a qualquer momento para atender ao requisito de quórum.

Neste tutorial, considerando um cluster MySQL de três instâncias, duas instâncias precisam estar disponíveis para formar um quórum. Com uma política PodDisruptionBudget, é possível limitar o número de pods que podem ser encerrados a qualquer momento. Isso é útil para operações de estado estável dos serviços com estado e para upgrades de cluster.

Para garantir que um número limitado de pods seja interrompido simultaneamente, defina o PDB para sua carga de trabalho como maxUnavailable: 1. Isso garante que, em qualquer ponto da operação do serviço, apenas um pod não esteja em execução.

O manifesto de política PodDisruptionBudget a seguir define o máximo de pods indisponíveis para um do seu aplicativo MySQL.

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

Para aplicar a política de PDB ao cluster, siga estas etapas:

1. Aplique a política de PDB usando kubectl.

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

2. Veja o status do PDB.

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

   Na seção status da saída, veja as contagens de pods currentHealthy e desiredHealthy. O resultado será assim:

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

Planejar upgrades binários do MySQL

O Kubernetes e o GKE oferecem recursos para facilitar os upgrades para o binário do MySQL. No entanto, é necessário realizar algumas operações para se preparar para os upgrades.

Lembre-se das seguintes considerações antes de iniciar o processo de upgrade:

• Os upgrades devem ser realizados primeiro em um ambiente de teste. Para sistemas de produção, é preciso realizar mais testes em um ambiente de pré-produção.
• Em algumas versões binárias, não é possível fazer downgrade da versão depois da atualização. Dedique um tempo para entender as implicações de um upgrade.
• As origens de replicação podem ser replicadas para uma versão mais recente. No entanto, geralmente não é possível copiar de uma versão mais recente para uma mais antiga.
• Faça um backup completo do banco de dados antes de implantar a versão atualizada.
• Considere a natureza efêmera dos pods do Kubernetes. Todo estado de configuração armazenado pelo pod que não está no volume permanente será perdido quando o pod for reimplantado.
• Para upgrades binários do MySQL, use o mesmo PDB, estratégia de atualização de pool de nós e sondagens, conforme descrito anteriormente.

Em um ambiente de produção, siga estas práticas recomendadas:

• Crie uma imagem de contêiner com a nova versão do MySQL.
• Mantenha as instruções de criação de imagem em um repositório de controle de origem.
• Use um pipeline automatizado de build e teste de imagens, como o Cloud Build, e armazene o binário da imagem em um registro de imagens, como o Artifact Registry.

Para manter este tutorial simples, você não criará nem manterá uma imagem de contêiner. Em vez disso, use as imagens públicas do MySQL.

Implante o binário MySQL atualizado

Para realizar o upgrade binário do MySQL, você emite um comando declarativo que modifica a versão da imagem do recurso StatefulSet. O GKE executa as etapas necessárias para interromper o pod atual, implantar um novo pod com o binário atualizado e anexar o disco permanente ao novo pod.

1. Verifique se o PDB foi criado.

   kubectl get poddisruptionbudgets -n mysql1
   

2. Veja a lista de conjuntos com estado.

   kubectl get statefulsets -n mysql1
   

3. Veja a lista de pods em execução usando o rótulo app.

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

4. Atualizar a imagem do MySQL no conjunto com estado.

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

   O resultado será assim:

   statefulset.apps/mysql image updated
   

5. Verifique o status dos pods de encerramento e dos novos pods.

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

Validar o upgrade binário do MySQL

Durante o upgrade, é possível verificar o status do lançamento, os novos pods e o serviço atual.

1. Valide o upgrade executando o comando rollout status.

   kubectl rollout status statefulset/dbc1 -n mysql1
   

   O resultado será assim:

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

2. Inspecione o conjunto com estado para confirmar a versão da imagem.

   kubectl get statefulsets -o wide -n mysql1
   

   O resultado será assim:

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

3. Verifique o status do 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\")"'
   

   Para cada instância do cluster, procure os valores de status e versão na saída. O resultado será assim:

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

Reverter o último lançamento de implantação do app

Quando você reverte a implantação de uma versão binária atualizada, o processo de lançamento é revertido e um novo conjunto de pods é implantado com a versão de imagem anterior.

Para reverter a implantação para a versão de trabalho anterior, use o comando rollout undo:

kubectl rollout undo statefulset/dbc1 -n mysql1

O resultado será assim:

statefulset.apps/dbc1 rolled back

Escalonar o cluster do banco de dados horizontalmente

Para escalonar o cluster do InnoDB do MySQL horizontalmente, você adiciona outros nós ao pool de nós do cluster do GKE (obrigatório apenas se você estiver usando o Standard), implanta outras instâncias do MySQL e, em seguida, adiciona cada instância ao MySQL existente Cluster do InnoDB.

Adicionar nodes ao cluster padrão

Essa operação não é necessária se você estiver usando um cluster do Autopilot.

Para adicionar nós ao cluster padrão, siga as instruções abaixo para o Cloud Shell ou o Console do Google Cloud. Para ver as etapas detalhadas, consulte Redimensionar um pool de nodes.

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

Adicionar pods do MySQL ao cluster principal

Para implantar outros pods do MySQL de modo a escalonar o cluster horizontalmente, siga estas etapas:

1. No Cloud Shell, atualize o número de réplicas na implantação do MySQL de três réplicas para cinco réplicas.

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

2. Verifique o andamento da implantação.

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

   Para determinar se os pods estão prontos, use a sinalização --watch para observar a implantação. Se você estiver usando clusters do Autopilot e vir erros Pod Unschedulable, isso poderá indicar que o GKE está provisionando nós para acomodar os pods adicionais.

3. Defina as configurações de replicação de grupo para as novas instâncias do MySQL a serem adicionadas ao cluster.

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

   O script envia os comandos para as instâncias em execução nos pods com ordinais 3 a 4.

4. Abra o MySQL Shell.

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

5. Configurar as duas novas instâncias do 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")});
   

   Os comandos verificam se a instância está configurada corretamente para o uso do cluster do MySQL InnoDB e realizam as alterações de configuração necessárias.

6. Adicione uma das novas instâncias ao cluster principal.

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

7. Adicione uma segunda instância nova ao cluster principal.

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

8. Acessar o status do ClusterSet, que também inclui o status do cluster.

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

   O resultado será assim:

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

9. Saia do MySQL Shell.

   \q