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

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

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

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

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

  • デフォルトの postgres ユーザーにはスーパーユーザーのロールがあります。

  • 他の事前定義されたユーザーロールには権限がありません。将来の使用のために予約されています。

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

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

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

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

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

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

AlloyDB Omni をモニタリングする

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

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

単一サーバー

デフォルトでは、AlloyDB Omni ログを取得するには、次のコマンドを実行します。

Docker

  docker logs CONTAINER_NAME

CONTAINER_NAME は、AlloyDB Omni コンテナの名前に置き換えます。

AlloyDB Omni のロギング動作を構成するには、AlloyDB Omni のインストールをカスタマイズするをご覧ください。

Podman

  podman logs CONTAINER_NAME

CONTAINER_NAME は、AlloyDB Omni コンテナの名前に置き換えます。

AlloyDB Omni のロギング動作を構成するには、AlloyDB Omni のインストールをカスタマイズするをご覧ください。

Podman

  podman logs CONTAINER_NAME

CONTAINER_NAME は、AlloyDB Omni コンテナの名前に置き換えます。

AlloyDB Omni のロギング動作を構成するには、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-systemal-3de6-dbc-monitoring-systemal-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 カスタム リソースとともに使用すると、データベース クラスタ内のすべての Namespace のすべてのサービスを選択できます。

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 をアップグレードする

AlloyDB Omni 15.5.2 以前から 15.5.4 にアップグレードするには、以前のバージョンの AlloyDB Omni から最新バージョンに移行するの手順に沿って操作します。

15.5.4 以降からアップグレードするには:

  1. 新しいイメージ バージョンを使用して AlloyDB Omni を再起動します。

  2. データ ディレクトリは、以前のバージョンの AlloyDB Omni で使用されているパスと同じになるように指定してください。

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

単一サーバー

AlloyDB Omni をアンインストールするには、次のコマンドを使用して AlloyDB Omni コンテナを停止して削除します。

Docker

 docker container stop CONTAINER_NAME
   docker container rm CONTAINER_NAME

CONTAINER_NAME は、AlloyDB Omni コンテナの名前に置き換えます。

Podman

 podman container stop CONTAINER_NAME
   podman container rm CONTAINER_NAME

CONTAINER_NAME は、AlloyDB Omni コンテナの名前に置き換えます。

Podman

 podman container stop CONTAINER_NAME
   podman container rm CONTAINER_NAME

CONTAINER_NAME は、AlloyDB Omni コンテナの名前に置き換えます。

AlloyDB Omni のアンインストール後にデータを保持するかどうか、保持する場合はどのように保持するかに応じて、外部データ ディレクトリを移動、アーカイブ、削除できます。

Kubernetes

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

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

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

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

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 がボリュームの拡張をサポートしている場合のみです。
  • ディスクサイズの縮小はできません。