AlloyDB Omni の管理とモニタリング

このページでは、AlloyDB Omni ユーザーロールの管理、AlloyDB Omni サーバーのアクティビティのモニタリング、AlloyDB Omni インストールの更新または削除の方法について説明します。

ユーザーロールを管理する

AlloyDB Omni は、AlloyDB に含まれる事前定義された PostgreSQL ユーザーロールのセットを使用しますが、次の点が異なります。

• AlloyDB Omni には alloydbiamuser ロールがありません。

• AlloyDB Omni には、alloydbadmin という名前のスーパーユーザー ロールが含まれています。

AlloyDB と同様に、データベースを設定する際は次の手順に従うことをおすすめします。

1. postgres ユーザーロールを使用してデータベースを定義またはインポートします。新規インストールでは、このロールにはデータベースの作成権限とロールの作成権限があり、パスワードはありません。

2. postgres ユーザーロールを使用して、アプリケーションのテーブルへの適切なアクセス権を持つ新しいユーザーロールを作成します。

3. これらの新しい限定アクセス ロールを使用してデータベースに接続するようにアプリケーションを構成します。

新しいユーザーロールは、必要な数だけ作成して定義できます。AlloyDB Omni に付属のユーザーロールは変更または削除しないでください。

詳細については、AlloyDB ユーザーロールを管理するをご覧ください。

AlloyDB Omni をモニタリングする

AlloyDB Omni のインストールをモニタリングするには、ログファイルを読み取って分析します。

Kubernetes で実行される AlloyDB Omni には、Prometheus エンドポイントとして使用できる一連の基本指標もあります。使用可能な指標のリストについては、AlloyDB Omni の指標をご覧ください。

単一サーバー

AlloyDB Omni は、次の 2 つの場所にアクティビティを記録します。

• AlloyDB Omni は、dataplane.conf 構成ファイルで定義したディレクトリを基準として、data/log/postgres にデータベース アクティビティを記録します。

  このログファイルの名前と形式は、/var/alloydb/config/postgresql.conf で定義されているさまざまな log_* ディレクティブを使用してカスタマイズできます。詳細については、エラー レポートとロギングをご覧ください。

• AlloyDB Omni は、インストール、起動、シャットダウンのアクティビティを /var/alloydb/logs/alloydb.log に記録します。

サーバーの直近の実行ステータスを確認するには、AlloyDB Omni のステータスを確認するをご覧ください。

Kubernetes

データベース クラスタのログファイルを探す

postgresql.audit ファイルと postgresql.log ファイルは、データベース Pod のファイル システムにあります。これらのファイルにアクセスする手順は次のとおりです。

1. データベース ポッドの名前を含む環境変数を定義します。

   export DB_POD=`kubectl get pod -l alloydbomni.internal.dbadmin.goog/dbcluster=DB_CLUSTER_NAME,alloydbomni.internal.dbadmin.goog/task-type=database -o jsonpath='{.items[0].metadata.name}'`

   DB_CLUSTER_NAME は、データベース クラスタの名前に置き換えます。これは、作成時に宣言したデータベース クラスタ名と同じです。

2. データベース Pod でルートとしてシェルを実行します。

   kubectl exec ${DB_POD} -it -- /bin/bash

3. /obs/diagnostic/ ディレクトリでログファイルを探します。

   • /obs/diagnostic/postgresql.audit
   • /obs/diagnostic/postgresql.log

モニタリング サービスを一覧表示する

v1.0

データベース クラスタを作成すると、AlloyDB Omni は同じ Namespace 内のデータベース クラスタのインスタンス CR ごとに次のモニタリング サービスを作成します。

al-INSTANCE_NAME-monitoring-system

モニタリング サービスを一覧表示するには、次のコマンドを実行します。

kubectl get svc -n NAMESPACE | grep monitoring

NAMESPACE は、クラスタが属する Namespace に置き換えます。

次のレスポンスの例は、al-1060-dbc-monitoring-system、al-3de6-dbc-monitoring-system、al-4bc0-dbc-monitoring-system サービスを示しています。各サービスは 1 つのインスタンスに対応します。

al-1060-dbc-monitoring-system   ClusterIP   10.0.15.227   <none>        9187/TCP   7d20h
al-3de6-dbc-monitoring-system   ClusterIP   10.0.5.205    <none>        9187/TCP   7d19h
al-4bc0-dbc-monitoring-system   ClusterIP   10.0.15.92    <none>        9187/TCP   7d19h

バージョン 1.0 未満

データベース クラスタを作成すると、AlloyDB Omni はデータベース クラスタと同じ名前空間に次のモニタリング サービスを作成します。

• DB_CLUSTER-monitoring-db

• DB_CLUSTER-monitoring-system

モニタリング サービスを一覧表示するには、次のコマンドを実行します。

kubectl get svc -n NAMESPACE | grep monitoring

NAMESPACE は、クラスタが属する Namespace に置き換えます。

次のレスポンス例は、al-2953-dbcluster-foo7-monitoring-system サービスと al-2953-dbcluster-foo7-monitoring-db サービスを示しています。

al-2953-dbcluster-foo7-monitoring-db           ClusterIP   10.36.3.243    <none>        9187/TCP   44m
al-2953-dbcluster-foo7-monitoring-system       ClusterIP   10.36.7.72     <none>        9187/TCP   44m

コマンドラインから Prometheus 指標を表示する

すべてのモニタリング サービスで、ポート 9187 の名前は metricsalloydbomni です。

1. ローカル環境からモニタリング サービスへのポート転送を設定します。

   kubectl port-forward service/MONITORING_SERVICE -n NAMESPACE MONITORING_METRICS_PORT:metricsalloydbomni
   

   次のように置き換えます。

   • MONITORING_SERVICE: 転送するモニタリング サービスの名前（例: al-1060-dbc-monitoring-system）。

   • NAMESPACE: クラスタが属する Namespace。

   • MONITORING_METRICS_PORT: ローカルで使用可能な TCP ポート。

   次のレスポンスは、サービスが転送されていることを示しています。

   Forwarding from 127.0.0.1:9187 -> 9187
   Forwarding from [::1]:9187 -> 9187
   

2. 上記のコマンドが実行されている間、指定したポートの HTTP 経由でモニタリング指標にアクセスできます。たとえば、curl を使用すると、すべての指標をプレーンテキストとして表示できます。

   curl http://localhost:MONITORING_METRICS_PORT/metrics
   

Prometheus API を使用して指標を表示する

alloydbomni.internal.dbadmin.goog/task-type ラベルキーと metricsalloydbomni ポートは、AlloyDB Omni のすべてのモニタリング サービスでデフォルトとして使用できます。これらを 1 つの ServiceMonitor カスタム リソースとともに使用すると、データベース クラスタ内のすべての名前空間のすべてのサービスを選択できます。

Prometheus API の使用方法については、Prometheus Operator のドキュメントをご覧ください。

alloydbomni.internal.dbadmin.gdc.goog/task-type ラベルキーと metricsalloydbomni ポートを含む ServiceMonitor カスタム リソースの spec フィールドの例を次に示します。ServiceMonitor カスタム リソースは、すべての Namespace 内のすべての Kubernetes サービスをモニタリングして収集します。

ServiceMonitor の完全な定義については、ServiceMonitor カスタム リソース定義 をご覧ください。

v1.0

    spec:
      selector:
        matchLabels:
          alloydbomni.internal.dbadmin.goog/task-type: monitoring
      namespaceSelector:
        any: true
      endpoints:
        - port: metricsalloydbomni

バージョン 1.0 未満

    spec:
      selector:
        matchExpressions:
        - key: alloydbomni.internal.dbadmin.gdc.goog/task-type
          operator: Exists
          values: []
      namespaceSelector:
        any: true
      endpoints:
      - port: metricsalloydbomni

AlloyDB Omni をアップグレードする

注意: 他のデータベースのアップグレードと同様に、続行する前にデータをバックアップしてください。pg_dumpall コマンドを使用して、データを 1 回限りローカルにエクスポートできます。

単一サーバー

これらの手順は、AlloyDB Omni バージョン 15.2.0 以降にのみ適用されます。

始める前に

マシンに AlloyDB Omni CLI バージョン 1.2 以降がインストールされている必要があります。

アップグレードを実行する

AlloyDB Omni のインストールをアップグレードするには、次のコマンドを実行します。

sudo alloydb database-server upgrade

Kubernetes

Kubernetes で AlloyDB Omni をアップグレードする手順は、実行している AlloyDB Omni のバージョンと、アップグレード先のバージョンによって異なります。

現在のバージョン番号を確認する

データベース クラスタで使用されている AlloyDB Omni のバージョンを確認するには、次のコマンドを実行します。

kubectl get dbclusters.alloydbomni.dbadmin.goog DB_CLUSTER_NAME -n NAMESPACE -o jsonpath='{.status.primary.currentDatabaseVersion}'

次のように置き換えます。

• DB_CLUSTER_NAME: データベース クラスタの名前。これは、作成時に宣言したデータベース クラスタ名と同じです。

• NAMESPACE: データベース クラスタの Kubernetes Namespace。

AlloyDB Omni Operator のバージョン 1.0.0 以降を実行している場合、このコマンドはデータベース クラスタで使用されている AlloyDB Omni のバージョンを出力します。

Kubernetes クラスタにインストールされている AlloyDB Omni Operator のバージョンを確認するには、次のコマンドを実行します。

kubectl get dbclusters.alloydbomni.dbadmin.goog DB_CLUSTER_NAME -n NAMESPACE -o jsonpath='{.status.primary.currentControlPlaneAgentsVersion}'

AlloyDB Omni Operator のバージョン 1.0.0 以降を実行している場合、このコマンドは Kubernetes クラスタで実行されている AlloyDB Omni Operator のバージョン番号を出力します。

AlloyDB Omni Operator のバージョンが 1.0.0 より前の場合は、データベース クラスタまたは AlloyDB Omni Operator のオンライン アップグレードを実行できません。代わりに、1.0.0 より前の AlloyDB Omni オペレーターからアップグレードするの手順に沿って操作する必要があります。

解消していない場合は次のセクションに進みます。

ターゲット バージョン番号を決定する

AlloyDB Omni Operator のバージョンが 1.0.0 以降の場合は、アップグレード先の AlloyDB Omni のバージョンによって次の手順が異なります。これには、AlloyDB Omni のバージョン番号を理解する必要があります。

AlloyDB Omni のバージョン番号は 3 つの部分で構成されています。

• PostgreSQL との互換性のメジャー バージョン番号
• PostgreSQL との互換性のマイナー バージョン番号
• この AlloyDB Omni リリースのパッチ バージョン番号

たとえば、AlloyDB Omni バージョン 15.5.2 は、PostgreSQL バージョン 15.5 をサポートする AlloyDB Omni のパッチ バージョン 2 です。

新しいバージョンの PostgreSQL をサポートする AlloyDB Omni のバージョンにアップグレードする場合は、データベース クラスタとともに AlloyDB Omni オペレーター自体をアップグレードする必要があります。特定の PostgreSQL マイナー バージョンをサポートする AlloyDB Omni リリースの各セットには、独自の AlloyDB Omni Operator バージョン番号が関連付けられています。このバージョン番号は、AlloyDB Omni バージョンのリリースノートで確認できます。

AlloyDB Omni の新しいパッチ バージョンにのみアップグレードする場合は、データベース クラスタのみをアップグレードできます。AlloyDB Omni オペレーター自体をアップグレードする必要はありません。データベース クラスタをアップグレードするの手順に進むことができます。

解消していない場合は次のセクションに進みます。

AlloyDB Omni オペレーターをアップグレードする

AlloyDB Omni オペレーターをアップグレードする手順は次のとおりです。

1. 必要な環境変数を定義します。

   export GCS_BUCKET=alloydb-omni-operator
   export OPERATOR_VERSION=OPERATOR_VERSION
   export HELM_PATH=$OPERATOR_VERSION/alloydbomni-operator-$OPERATOR_VERSION.tgz

   OPERATOR_VERSION は、アップグレード先の AlloyDB Omni Operator のバージョンに置き換えます（1.1.0 など）。

2. 新しい AlloyDB Omni オペレーター パッケージをダウンロードします。

   gcloud storage cp gs://$GCS_BUCKET/$HELM_PATH ./ --recursive
   tar -xvzf alloydbomni-operator-${OPERATOR_VERSION}.tgz

3. 新しい AlloyDB Omni Operator カスタム リソース定義を適用します。

   kubectl apply -f alloydbomni-operator/crds

4. AlloyDB Omni Operator Helm チャートをアップグレードします。

   helm upgrade alloydbomni-operator alloydbomni-operator-${OPERATOR_VERSION}.tgz \
   --namespace alloydb-omni-system \
   --atomic \
   --timeout 5m

Kubernetes マニフェストとデータベース クラスタの両方をアップグレードして AlloyDB Omni オペレーターのアップグレードを続行するには、前の手順を完了した直後に次のセクションの手順に沿って操作します。

データベース クラスタをアップグレードする

データベース クラスタをアップグレードするには、それを定義するマニフェストの spec セクションで次のフィールドを更新します。

• databaseVersion は、このデータベース クラスタをアップグレードする AlloyDB Omni の完全なバージョン番号に設定します。

• AlloyDB Omni Operator もアップグレードした場合は、controlPlaneAgentsVersion を、アップグレードした AlloyDB Omni Operator の完全なバージョン番号に設定します。

AlloyDB Omni のパッチ バージョンのみをアップグレードする場合（databaseVersion を 15.5.1 から 15.5.2 に更新する場合など）は、この手順のみで完了できます。

PostgreSQL 互換性のマイナー バージョンをアップグレードする場合（databaseVersion を 15.4.1 から 15.5.2 に更新する場合など）は、controlPlaneAgentsVersion も更新する必要があります。その場合は、AlloyDB Omni オペレーターをアップグレードするに記載されている追加の手順を実施していることを確認してください。

たとえば、次のマニフェストの抜粋では、AlloyDB Omni Operator バージョン 15.5.2 を実行するデータベース クラスタを、AlloyDB Omni Operator バージョン 1.0.0 で定義しています。

apiVersion: alloydbomni.dbadmin.goog/v1 
kind: DBCluster
metadata:
  name: dbcluster-sample
spec:
  databaseVersion: 15.5.2
  controlPlaneAgentsVersion: 1.0.0

この例では、AlloyDB Omni バージョン 15.5.3 を実行するようにデータベース クラスタをアップグレードするには、databaseVersion: 15.5.2 を databaseVersion: 15.5.3 に変更します。

1.0.0 より前の AlloyDB Omni オペレーターからアップグレードする

AlloyDB Omni Operator のバージョンが 1.0.0 より前の場合は、Kubernetes ベースの AlloyDB Omni インストールをアップグレードするには、データをバックアップした後に AlloyDB Omni Operator をアンインストールしてから再インストールする必要があります。手順は次のとおりです。

1. すべてのデータベース クラスタを一覧表示します。

   kubectl get dbclusters.alloydbomni.dbadmin.goog --all-namespaces

2. データベース クラスタごとに、pg_dumpall コマンドを使用してすべてのデータをエクスポートします。

   警告: この手順をスキップしないでください。データをエクスポートしなかった場合、次の手順でデータが完全に消去されます。

3. AlloyDB Omni オペレーターをアンインストールします。これには、すべてのデータベース クラスタの削除も含まれます。

4. AlloyDB Omni オペレーターを再インストールします。新しいバージョン番号を指定する必要はありません。AlloyDB Omni Operator の以前のバージョンをインストールしたときと同じコマンドを使用できます。

5. データベース クラスタを再作成します。以前にデータベース クラスタを作成したときに使用したものと同じマニフェスト ファイルを使用できます。AlloyDB Omni オペレータのバージョン 1.0.0 で導入された API の変更（古い version 属性に代わる databaseVersion 属性など）を反映するようにファイルを更新する必要がある場合があります。

6. pg_restore または psql の \i コマンドを使用して、以前にエクスポートしたデータを再作成されたクラスタにインポートします。

アップグレードをロールバックする

これらの手順は、AlloyDB Omni バージョン 15.2.1 ～ 15.5.2 にのみ適用されます。AlloyDB Omni の Kubernetes ベースのデプロイには適用されません。

AlloyDB Omni を以前にインストールしたバージョンにロールバックするには、次のコマンドを実行します。

sudo alloydb database-server rollback

注意: AlloyDB Omni バージョン 15.5.0 以降にパラメータ化されたセキュアなビューのテクノロジー プレビューをインストールしている場合は、ロールバックする前に追加の手順を実施する必要があります。

AlloyDB Omni をアンインストールする

単一サーバー

AlloyDB Omni をアンインストールするには、次のコマンドを実行します。

sudo alloydb database-server uninstall

AlloyDB Omni をアンインストールしても、データ ディレクトリはファイル システムに残ります。このディレクトリは、AlloyDB Omni のアンインストール後にデータを保持するかどうか、保持する場合はどのように保持するかに応じて、移動、アーカイブ、削除できます。

Kubernetes

データベース クラスタを削除する

データベース クラスタを削除するには、マニフェストで isDeleted を true に設定します。これは次のコマンドで実行できます。

注意: 次のコマンドを実行すると、名前付きデータベース クラスタに保存されているすべてのデータが完全に消去されます。

kubectl patch dbclusters.alloydbomni.dbadmin.goog DB_CLUSTER_NAME -p '{"spec":{"isDeleted":true}}' --type=merge

DB_CLUSTER_NAME は、データベース クラスタの名前に置き換えます。これは、作成時に宣言したデータベース クラスタ名と同じです。

AlloyDB Omni Operator をアンインストールする

注意: この手順を行うと、Kubernetes クラスタからすべての AlloyDB Omni データベースが完全に削除されます。

Kubernetes クラスタから AlloyDB Omni Kubernetes オペレーターをアンインストールする手順は次のとおりです。

1. すべてのデータベース クラスタを削除します。

   for ns in $(kubectl get dbclusters.alloydbomni.dbadmin.goog --all-namespaces -o=jsonpath='{range .items[*]}{.metadata.namespace}{"\n"}{end}'); do
   for cr in $(kubectl get dbclusters.alloydbomni.dbadmin.goog -n $ns -o=jsonpath='{range .items[*]}{.metadata.name}{"\n"}{end}'); do
   kubectl patch dbclusters.alloydbomni.dbadmin.goog $cr -n $ns --type=merge -p '{"spec":{"isDeleted":true}}'
   done
   done

2. AlloyDB Omni Kubernetes オペレーターがすべてのデータベース クラスタを削除するまで待ちます。次のコマンドを使用して、データベース リソースが残っているかどうかを確認します。

   kubectl get dbclusters.alloydbomni.dbadmin.goog --all-namespaces

3. AlloyDB Omni Kubernetes オペレーターによって作成された他のリソースを削除します。

   kubectl delete failovers.alloydbomni.dbadmin.goog --all --all-namespaces
   kubectl delete restores.alloydbomni.dbadmin.goog --all --all-namespaces
   kubectl delete switchovers.alloydbomni.dbadmin.goog --all --all-namespaces

4. AlloyDB Omni Kubernetes オペレーターをアンインストールします。

   helm uninstall alloydbomni-operator --namespace alloydb-omni-system

5. AlloyDB Omni Kubernetes オペレーターに関連する Secret、カスタム リソースの説明、Namespace をクリーンアップします。

   kubectl delete certificate -n alloydb-omni-system --all
   kubectl get secrets --all-namespaces -o custom-columns=NAMESPACE:.metadata.namespace,NAME:.metadata.name,ANNOTATION:.metadata.annotations.cert-manager\.io/issuer-name | grep -E 'alloydbomni|dbs-al' | awk '{print $1 " " $2}' | xargs -n 2 kubectl delete secret -n
   kubectl delete crd -l alloydb-omni=true
   kubectl delete ns alloydb-omni-system

Kubernetes ベースのデータベース クラスタのサイズを変更する

Kubernetes ベースのデータベース クラスタの CPU、メモリ、ストレージのサイズを変更するには、Pod を定義するマニフェストの resources フィールドを更新します。AlloyDB Omni オペレーターは、新しい仕様をデータベース Pod にすぐに適用します。

AlloyDB Omni オペレーター マニフェストの構文の詳細については、データベース クラスタを作成するをご覧ください。

実行中のデータベース クラスタのリソースの変更には、次の制限が適用されます。

• ディスクのサイズを増やすことができるのは、指定された storageClass がボリュームの拡張をサポートしている場合のみです。
• ディスクサイズの縮小はできません。