Keycloakデータ移行の失敗

分析でKeycloakデータの移行中の障害を検出

サマリー

分析により、既存のlegacyDBから新しいInnoDBにKeycloakデータを移行する際に、Verrazzanoのアップグレードが失敗したことが検出されました。

ステップ

  1. dump-claim PVCが存在し、PVにバインドされているかどうかを確認します。 

    $ k get pvc -n keycloak dump-claim

# Sample Output
NAME         STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
dump-claim   Bound    pvc-c246d7c4-3041-4164-8c1e-744dda805686   2Gi        RWO            standard       12m

    $ kubectl get pv

# Sample Output
NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                 STORAGECLASS   REASON   AGE
pvc-c246d7c4-3041-4164-8c1e-744dda805686   2Gi        RWO            Retain           Bound    keycloak/dump-claim   standard                49m

  2. keycloakネームスペースのmysqlまたはmysql-cluster-secretシークレットからmysql-root passwordを取得します。パスワードは、次のステップでrootユーザーとしてMySQLサーバーにアクセスするために必要です。 

    $ kubectl get secret -n keycloak mysql -o jsonpath='{.data.mysql-root-password}' | base64 --decode

# Sample Output
lvYwPJjwFB

  3. 以前のKeycloakデータベース・データを新しいデータベース・インスタンスに移行する際に役立つload-dumpポッドを作成します。

    $ kubectl apply -f - <<EOF
  apiVersion: v1
  kind: Pod
  metadata:
    name: my-load-dump
    namespace: keycloak
    labels:
      job-name: load-dump
  spec:
    containers:
    - name: mysqlsh-load-dump
      image: ghcr.io/verrazzano/mysql-server:8.0.32
      volumeMounts:
      - mountPath: /var/lib/dump
        name: keycloak-dump
    volumes:
    - name: keycloak-dump
      persistentVolumeClaim:
        claimName: dump-claim
EOF

  4. pod内でシェル・セッションを開始し、次のコマンドを実行します: 

    $ kubectl exec -n keycloak my-load-dump -it -- /bin/bash
    a.dumpディレクトリ権限を修正します。 
    $ chown -R 27:27 /var/lib/dump
    b.MySQLサーバーが実行中かどうかを確認します。実行されていない場合は、keycloakネームスペースのMySQLポッドの準備ができているかどうかを確認してから、もう一度確認します。 
    $ mysqladmin ping -h"mysql.keycloak.svc.cluster.local" -p{{ .RootPassword }}

# Sample Output
mysqld is alive
    c.Keycloakデータを移行します。 
    $ mysqlsh -u root -p{{ .RootPassword }} -h mysql.keycloak.svc.cluster.local -e 'util.loadDump("/var/lib/dump/dump", {includeSchemas: ["keycloak"], includeUsers: ["keycloak"], loadUsers: true})'


    # Sample Output
Loading DDL, Data and Users from '/var/lib/dump/dump' using 4 threads.
Opening dump...
Target is MySQL 8.0.32. Dump was produced from MySQL 8.0.29
Scanning metadata - done       
Checking for pre-existing objects...
Executing common preamble SQL
Executing DDL - done         
Executing user accounts SQL...
NOTE: Skipping CREATE/ALTER USER statements for user 'root'@'%'
NOTE: Skipping CREATE/ALTER USER statements for user 'root'@'localhost'
NOTE: Skipping GRANT statements for user 'root'@'%'
NOTE: Skipping GRANT statements for user 'root'@'localhost'
Executing view DDL - done       
Starting data load
4 thds loading \ 100% (159.79 KB / 159.79 KB), 0.00 B/s, 33 / 93 tables done
Recreating indexes - done       
Executing common postamble SQL                                              
93 chunks (1.31K rows, 159.79 KB) for 93 tables in 1 schemas were loaded in 3 sec (avg throughput 159.79 KB/s)
0 warnings were reported during the load.

  5. db-migrationシークレットで、db-migratedフィールドを追加し、その値をtrue (base64 encoded)に設定します。これにより、Keycloakデータが手動で移行されたことがVerrazzanoプラットフォーム・オペレータに通知されます。 

    $ k edit secret -n keycloak db-migration

# Sample Output
data:
  db-migrated: dHJ1ZQ==        # true base64 encoded is dHJ1ZQ==
  database-dumped: dHJ1ZQ==
  deployment-found: dHJ1ZQ==
  ...

  6. load-dumpポッドを削除します。 

    $ kubectl delete pod -n keycloak my-load-dump