Pile de données

Récupération du cluster Galera

Une panne majeure du cluster Kubernetes ou une perturbation volontaire accidentelle peut entraîner une perte du quorum de Galera et un échec total du cluster.

Suivez l'étape suivante pour récupérer en réamorcant le cluster.

• Exigence : Définir l'environnement de la station de travail :

  export RELEASE=<release name>
  export CONFIG_REPO_BASEURL=https://raw.githubusercontent.com/actility/thingpark-enterprise-kubernetes/v$RELEASE
  eval $(curl $CONFIG_REPO_BASEURL/VERSIONS)
  # Set the deployment namespace as an environment variable
  export NAMESPACE=thingpark-enterprise
  # Value in s,m,l,xl,xxl
  export SEGMENT=l
  # Value azure,amazon
  export HOSTING=azure

1. Vérifiez l'état du pod statefulset de Galera, il retournera des conditions d'échec :

   kubectl get po -n $NAMESPACE -l app.kubernetes.io/name=mariadb-galera -o jsonpath='{.items[].status.containerStatuses[].ready}'

   $ kubectl get po -n $NAMESPACE -l app.kubernetes.io/name=mariadb-galera -o jsonpath='{.items[].status.containerStatuses[].state}'|jq
   {
   "waiting": {
       "message": "back-off 5m0s restarting failed container=mariadb-galera pod=tpe-mariadb-galera-0_thingpark-enterprise(6faab544-25fd-4e77-a6b9-185e058462dd)",
       "reason": "CrashLoopBackOff"
   }
   }
   

2. Arrêter le cluster en détruisant le statefulset et en arrêtant le proxy SQL

   kubectl -n $NAMESPACE delete statefulsets.apps mariadb-galera
   kubectl -n $NAMESPACE scale deployment sql-proxy --replicas=0

3. Récupérez le contenu grastate.dat de chaque nœud en utilisant chaque nom de revendication de volume data-mariadb-galera-0, data-mariadb-galera-1, data-mariadb-galera-2, par exemple :

   $ kubectl run --restart=Never -n $NAMESPACE -i --rm --tty volpod --overrides='
   {
       "apiVersion": "v1",
       "kind": "Pod",
       "metadata": {
           "name": "volpod"
       },
       "spec": {
           "containers": [{
               "command": [
                   "cat",
                   "/mnt/data/grastate.dat"
               ],
               "image": "bitnami/minideb",
               "name": "mycontainer",
               "volumeMounts": [{
                   "mountPath": "/mnt",
                   "name": "galeradata"
               }]
           }],
           "restartPolicy": "Never",
           "volumes": [{
               "name": "galeradata",
               "persistentVolumeClaim": {
                   "claimName": "data-mariadb-galera-0"
               }
           }]
       }
   }' --image="bitnami/minideb"
   

4. En conséquence, vous obtenez l'état de chaque nœud, par exemple (cette situation reflète un arrêt incorrect du cluster (tous les safe_to_bootstrap égal à 0)) :

   ## Node 0
   # GALERA saved state
   version: 2.1
   uuid:    f23062b8-3ed3-11eb-9979-0e1cb0f4f878
   seqno:   14
   safe_to_bootstrap: 0
   pod "volpod" deleted
   
   ## Node 1
   # GALERA saved state
   version: 2.1
   uuid:    f23062b8-3ed3-11eb-9979-0e1cb0f4f878
   seqno:   14
   safe_to_bootstrap: 0
   pod "volpod" deleted
   
   ## Node 2
   # GALERA saved state
   version: 2.1
   uuid:    f23062b8-3ed3-11eb-9979-0e1cb0f4f878
   seqno:   14
   safe_to_bootstrap: 0

5. Réamorcer le cluster :

   • Option 1 : Un nœud a un safe_to_bootstrap: 1 :

     # GALERA saved state
     version: 2.1
     uuid:    f23062b8-3ed3-11eb-9979-0e1cb0f4f878
     seqno:   14
     safe_to_bootstrap: 1
     pod "volpod" deleted

     Ce nœud devrait être utilisé pour réamorcer le cluster, par exemple avec le nœud 1 :

     helm -n $NAMESPACE upgrade -i tpe-data actility/thingpark-data \
       --version $THINGPARK_DATA_VERSION --reuse-values \
       --set mariadb-galera.podManagementPolicy=Parallel  \
       --set mariadb-galera.galera.bootstrap.forceBootstrap=true \
       --set mariadb-galera.galera.bootstrap.bootstrapFromNode=1

   • Option 2 : Tous les nœuds ont un safe_to_bootstrap: 0 :

     Le cluster doit être amorcé avec le nœud ayant le seqno le plus élevé :

     helm -n $NAMESPACE upgrade -i tpe-data actility/thingpark-data \
       --version $THINGPARK_DATA_VERSION --reuse-values \
       --set mariadb-galera.podManagementPolicy=Parallel \
       --set mariadb-galera.galera.bootstrap.forceSafeToBootstrap=true \
       --set mariadb-galera.galera.bootstrap.forceBootstrap=true \
       --set mariadb-galera.galera.bootstrap.bootstrapFromNode=1

6. Attendez la fin de la récupération et réinitialisez les valeurs de version Helm de la manière suivante : en arrêtant le cluster Galera de cette manière :

   # Wait until all pods became READY
   kubectl -n $NAMESPACE get statefulsets.apps mariadb-galera -w
   # Scale down gracefully mariadb galera cluster  (wait until the end of pod deletion at each steps)
   kubectl -n $NAMESPACE scale statefulsets.apps mariadb-galera --replicas=2
   kubectl -n $NAMESPACE scale statefulsets.apps mariadb-galera --replicas=1
   # Delete stalefulset
   kubectl  -n $NAMESPACE delete statefulsets.apps mariadb-galera

7. Et enfin, mettez à niveau la version tpe-data et redémarrez le déploiement du routeur SQL-proxy

   helm  upgrade -i tpe-data -n $NAMESPACE \
     actility/thingpark-data --version $THINGPARK_DATA_VERSION \
     -f $CONFIG_REPO_BASEURL/configs/$HOSTING/values-$SEGMENT-segment.yaml \
     -f custom-values.yaml
   
   kubectl scale -n $NAMESPACE deployment sql-proxy --replicas=2