ユーザーロールを管理する
AlloyDB Omni は、AlloyDB に含まれる事前定義された PostgreSQL ユーザーロールの同じセットを使用しますが、次の点が異なります。
AlloyDB Omni には、
alloydbadminという名前のスーパーユーザー ロールと、alloydbmetadataという名前の非スーパーユーザー ロールが含まれています。デフォルトの
postgresユーザーにはスーパーユーザー ロールがあります。他の事前定義されたユーザーロールには権限がありません。将来の使用のために予約されています。
AlloyDB と同様に、データベースを設定する際は次の手順に沿うことをおすすめします。
postgresユーザーロールを使用してデータベースを定義またはインポートします。新規インストールでは、このロールにはスーパーユーザー権限があり、パスワードは必要ありません。再度、
postgresユーザーロールを使用して、アプリケーションのテーブルへの適切なアクセス権を持つ新しいユーザーロールを作成します。これらの新しいアクセス制限付きロールを使用して、データベースに接続するようにアプリケーションを構成します。
新しいユーザーロールは、必要な数だけ作成して定義できます。AlloyDB Omni に付属するユーザーロールは変更または削除しないでください。
詳細については、AlloyDB ユーザーロールを管理するをご覧ください。
AlloyDB Omni をモニタリングする
AlloyDB Omni のインストールをモニタリングするには、ログファイルを読み取り、分析を行います。
使用可能な指標のリストについては、AlloyDB Omni の指標をご覧ください。
Kubernetes で実行される AlloyDB Omni には、Prometheus エンドポイントとして使用できる一連の基本指標もあります。
Kubernetes
データベース クラスタのログファイルを探す
postgresql.audit ファイルと postgresql.log ファイルは、データベース Pod のファイル システムにあります。これらのファイルにアクセスする手順は次のとおりです。
データベース Pod の名前を含む環境変数を定義します。
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は、実際のデータベースの名前に置き換えます。これは、作成時に宣言したデータベース クラスタ名と同じです。データベース Pod でルートとしてシェルを実行します。
kubectl exec ${DB_POD} -it -- /bin/bash/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 はデータベース クラスタと同じ Namespace に次のモニタリング サービスを作成します。
DB_CLUSTER-monitoring-dbDB_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 です。
ローカル環境からモニタリング サービスへのポート転送を設定します。
kubectl port-forward service/MONITORING_SERVICE -n NAMESPACE MONITORING_METRICS_PORT:metricsalloydbomni次のように置き換えます。
MONITORING_SERVICE: 転送するモニタリング サービスの名前。例:al-1060-dbc-monitoring-systemNAMESPACE: クラスタが属する Namespace。MONITORING_METRICS_PORT: ローカルで使用可能な TCP ポート。
次のレスポンスは、サービスが転送されていることを示しています。
Forwarding from 127.0.0.1:9187 -> 9187 Forwarding from [::1]:9187 -> 9187上記のコマンドが実行されている間、指定したポートの 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 Service をモニタリングして収集します。
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 以降からアップグレードするには:
新しいイメージ バージョンを使用して AlloyDB Omni を再起動します。
データ ディレクトリは、以前のバージョンの AlloyDB Omni で使用されているパスと同じになるように指定してください。
AlloyDB Omni をアンインストールする
Kubernetes
データベース クラスタを削除する
データベース クラスタを削除するには、マニフェストで isDeleted を true に設定します。この操作を行うには、次のコマンドを実行します。
kubectl patch dbclusters.alloydbomni.dbadmin.goog DB_CLUSTER_NAME -p '{"spec":{"isDeleted":true}}' --type=mergeDB_CLUSTER_NAME は、実際のデータベースの名前に置き換えます。これは、作成時に宣言したデータベース クラスタ名と同じです。
AlloyDB Omni Operator をアンインストールする
Kubernetes クラスタから AlloyDB Omni Kubernetes Operator をアンインストールする手順は次のとおりです。
すべてのデータベース クラスタを削除します。
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 doneAlloyDB Omni Kubernetes Operator がすべてのデータベース クラスタを削除するまで待機します。データベース リソースが残っているかどうかを確認するには、次のコマンドを使用します。
kubectl get dbclusters.alloydbomni.dbadmin.goog --all-namespacesAlloyDB Omni Kubernetes Operator が作成した他のリソースを削除します。
kubectl delete failovers.alloydbomni.dbadmin.goog --all --all-namespaceskubectl delete restores.alloydbomni.dbadmin.goog --all --all-namespaceskubectl delete switchovers.alloydbomni.dbadmin.goog --all --all-namespacesAlloyDB Omni Kubernetes Operator をアンインストールします。
helm uninstall alloydbomni-operator --namespace alloydb-omni-systemAlloyDB Omni Kubernetes Operator に関連する Secret、カスタム リソースの説明、Namespace をクリーンアップします。
kubectl delete certificate -n alloydb-omni-system --allkubectl 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 -nkubectl delete crd -l alloydb-omni=truekubectl delete ns alloydb-omni-system
Kubernetes ベースのデータベース クラスタのサイズを変更する
Kubernetes ベースのデータベース クラスタの CPU、メモリ、ストレージのサイズを変更するには、Pod を定義するマニフェストの resources フィールドを更新します。AlloyDB Omni Operator は、新しい仕様をデータベース Pod にすぐに適用します。
AlloyDB Omni Operator マニフェストの構文の詳細については、データベース クラスタを作成するをご覧ください。
実行中のデータベース クラスタのリソースの変更には、次の制限が適用されます。
- ディスクのサイズを増やすことができるのは、指定された
storageClassがボリュームの拡張をサポートしている場合のみです。 - ディスクサイズの縮小はできません。