ログアーカイブを利用する物理スタンバイデータベースであれ、ネットワークを利用する物理スタンバイデータベースであれ、スタンバイテナントにはログ復元ソースを設定する必要があります。どちらのデプロイメント方式でも、ログ復元ソースはいつでも必要に応じて動的に変更でき、あるログ復元ソースから別のログ復元ソースへの切り替えもサポートしています。このセクションでは、ログアーカイブを利用する物理スタンバイデータベースの場合と、ネットワークを利用する物理スタンバイデータベースの場合に分けて、ログ復元ソースの設定方法を説明します。
注意点
ログ復元ソースをある種類から別の種類に変更する際は、変更前後でのログ復元ソースがスタンバイテナント作成時に指定したソーステナントと一致している必要があります。つまり、ソーステナントのログアーカイブを使用するか、直接ソーステナントを指す必要があります。変更前後でログ復元ソースが一致しない場合、スタンバイテナントのデータが誤ってしまい、復元できなくなるため、新しいスタンバイテナントを再作成する必要があります。
ログアーカイブを利用した物理スタンバイデータベースの構成例
物理バックアップ・リストア（ログ付き）機能で作成されたスタンバイテナントは、RESTORE コマンドで復元する際に既にデフォルトの復元ソースが設定されています。このデフォルトの復元ソースは、通常はプライマリテナントまたはソース側のスタンバイテナントのログアーカイブ宛先となります。そのため、通常は追加の設定は不要です。ログ復元ソースをプライマリテナントやソース側のスタンバイテナントに直接変更する必要がある場合は、本記事の ネットワーク経由の物理スタンバイデータベースの構成例 を参照して設定をやり直してください。
他の方法（空のスタンバイテナントの作成や BACKUP DATABASE PLUS ARCHIVELOG 機能を使用してスタンバイテナントを作成する場合）で作成されたスタンバイテナントでは、ログ復元ソースをプライマリテナントのログアーカイブを利用するように設定する必要がある場合、以下の手順を参照してログ復元ソースを手動で設定してください。
注意
アーカイブ媒体がオブジェクトストレージ（例：Alibaba Cloud OSS、Azure Blob、AWS S3、およびS3プロトコル互換のオブジェクトストレージ）の場合、物理スタンバイデータベースの稼働中にプライマリテナントまたはソース側のスタンバイテナントでバックアップ媒体のキー情報が変更された場合、以下の手順を参照してログ復元ソースを再設定する必要があります。
管理者ユーザーでスタンバイテナント、またはそのスタンバイテナントが存在するクラスタの
sysテナントにログインします。以下のコマンドを実行し、スタンバイテナントの復元ソースをプライマリテナントのアーカイブ宛先に設定します。
スタンバイテナントが存在するクラスタの
sysテナントでスタンバイテナントの復元ソースを設定ALTER SYSTEM SET LOG_RESTORE_SOURCE ='LOCATION=archive_path' TENANT = tenant_name;スタンバイテナントで自身の復元ソースを設定
ALTER SYSTEM SET LOG_RESTORE_SOURCE ='LOCATION=archive_path';
ここで、
LOCATIONプロパティはプライマリテナントのアーカイブ宛先を指定するために使用されます。以下は、アーカイブ媒体がOSSまたはNFSの場合を例に説明します。
Alibaba Cloud OSSNFSプライマリテナントのアーカイブメディアがOSSの場合、スタンバイテナントが配置されているクラスタの
sysテナントまたはスタンバイテナントでログ復元ソースを設定する例は以下のとおりです：obclient> ALTER SYSTEM SET LOG_RESTORE_SOURCE ='location=oss://oceanbase-test-bucket/backup/archive?host=****.aliyun-inc.com&access_id=****&access_key=****' TENANT = standby_tenant;obclient> ALTER SYSTEM SET LOG_RESTORE_SOURCE ='location=oss://oceanbase-test-bucket/backup/archive?host=****.aliyun-inc.com&access_id=****&access_key=****';プライマリテナントのアーカイブメディアがNFSの場合、スタンバイテナントが配置されているクラスタの
sysテナントまたはスタンバイテナントでログ復元ソースを設定する例は以下のとおりです。obclient> ALTER SYSTEM SET LOG_RESTORE_SOURCE ='location=file:///data/1/sh_archive' TENANT = standby_tenant;obclient> ALTER SYSTEM SET LOG_RESTORE_SOURCE ='location=file:///data/1/sh_archive';
ネットワークベースの物理スタンバイデータベースのシナリオ
空のスタンバイテナントを作成する方法で作成されたスタンバイテナントでは、CREATE STANDBY TENANT コマンド実行時に LOG_RESTORE_SOURCE パラメータでデフォルトのログ復元ソースが設定されており、デフォルトではプライマリテナントを直接指します。そのため、通常は追加で設定する必要はありません。それでもログ復元ソースをプライマリテナントのログアーカイブを使用するよう変更する必要がある場合は、本記事の ログアーカイブを利用した物理スタンバイデータベースのシナリオ を参照してログ復元ソースを再設定してください。
他の方法（バックアップ復元（ログあり）機能を使用してスタンバイテナントを作成する場合や BACKUP DATABASE PLUS ARCHIVELOG 機能を使用してスタンバイテナントを作成する場合）で作成されたスタンバイテナントでは、ログ復元ソースをプライマリテナントまたはソース側のスタンバイテナントを指すよう設定する必要がある場合、以下の手順を参考に ALTER SYSTEM SET LOG_RESTORE_SOURCE コマンドを使用してログ復元ソースを手動で設定してください。
ステップ１：ビューにアクセスするための専用ユーザーを作成する
スタンバイテナントがプライマリテナントまたはソース側のスタンバイテナントに接続する際、プライマリテナントまたはソース側のスタンバイテナントの一部のシステムビューにアクセスする必要があります。そのため、ビューにアクセスするための専用ユーザーが必要であり、このユーザーにはこれらのシステムビューに対するクエリ権限が付与されていなければなりません。既存の権限を持つプライマリテナントまたはソース側のスタンバイテナントのユーザーを利用するか、プライマリテナントまたはソース側のスタンバイテナント上に、現在のスタンバイテナント専用の新しいユーザーを作成して関連権限を付与することもできます。
スタンバイテナントがアクセスする必要があるシステムビューは以下のとおりです：
GV$OB_LOG_STAT：プライマリテナントのマシンリスト、レプリカサービスのログストリームLSN範囲、ロール（リーダーかどうか）などの情報を取得するために使用されます。GV$OB_LOG_STATビューの詳細については、GV$OB_LOG_STATを参照してください。GV$OB_UNITS：プライマリテナントのすべてのUnit情報を照会し、レプリカの状態、ゾーン、リージョンなどの情報を取得します。これは、テナントのマシン接続のフィルタリング、取得、メンテナンスに使用されます。GV$OB_UNITSビューの詳細については、GV$OB_UNITSを参照してください。GV$OB_PARAMETERS: プライマリテナントのcluster_id、tenant_idなど、サービスに必要なメタ情報を照会するために使用されます。GV$OB_PARAMETERSビューの詳細については、GV$OB_PARAMETERSを参照してください。DBA_OB_ACCESS_POINT: アクセスポイント情報を取得するために使用されます。プライマリテナントの移行レプリケーション、災害復旧などのシナリオで、アクセスポイントが変更された場合、スタンバイテナントは自動的に検知でき、ユーザーが手動で変更する必要はありません。DBA_OB_ACCESS_POINTビューの詳細については、DBA_OB_ACCESS_POINTを参照してください。DBA_OB_TENANTS：プライマリテナントの互換モードを取得します。DBA_OB_TENANTSビューの詳細については、DBA_OB_TENANTSを参照してください。DBA_OB_LS: プライマリテナントのログストリームリストおよびログストリームの状態を取得します。DBA_OB_LSビューの詳細については、DBA_OB_LSを参照してください。
ビューにアクセスするための専用ユーザーの作成と権限付与の具体的な操作は以下のとおりです。
注意
OceanBaseデータベースのユーザー名と権限情報はプライマリ/スタンバイテナント間で同期されます。スタンバイテナント単独ではユーザーの作成や権限の付与は許可されていません。したがって、現在のスタンバイテナントのソースが別のスタンバイテナントの場合は、対応するプライマリテナント上でビューにアクセスするための専用ユーザーを作成し、権限を付与する必要があります。
MySQLモード
管理者ユーザーでプライマリテナントにログインします。
以下のコマンドを実行して、新しいユーザーを作成します。
obclient [oceanbase]> CREATE USER rep_user IDENTIFIED BY '******';ユーザーに権限を付与します。
以下の例では、
oceanbaseデータベースのすべてのテーブルに対するSELECT権限をこのユーザーに付与します。または、oceanbaseデータベース内のGV$OB_LOG_STAT、GV$OB_UNITS、GV$OB_PARAMETERS、DBA_OB_ACCESS_POINT、DBA_OB_TENANTS、DBA_OB_LSなどのビューに対するSELECT権限のみを付与することもできます。obclient [oceanbase]> GRANT SELECT ON oceanbase.* TO rep_user;
Oracleモード
管理者ユーザーでプライマリテナントにログインします。
新しいユーザーを作成します。
obclient [SYS]> CREATE USER rep_user IDENTIFIED BY '******';新規ユーザー
rep_userにロールSTANDBY_REPLICATIONを付与します。STANDBY_REPLICATIONはシステムのデフォルトロールであり、デフォルトでCREATE SESSIONシステム権限および以下のビューに対するクエリ権限が含まれています：- GV$OB_LOG_STAT
- GV$OB_UNITS
- GV$OB_PARAMETERS
- DBA_OB_ACCESS_POINT
- DBA_OB_TENANTS
- DBA_OB_LS
- DBA_OB_LS_HISTORY
ステートメントは以下のとおりです：
obclient [SYS]> GRANT STANDBY_REPLICATION TO rep_user;
ステップ2：プライマリテナントまたはソース側のスタンバイテナントのアクセスポイント情報を取得する
ネットワークベースの物理スタンバイデータベースでログ復元ソースを設定する際には、プライマリテナントまたはソース側のスタンバイテナントのアクセスポイント情報、すなわちテナントレプリカが配置されているOBServerノードのIPアドレスとポート番号も取得する必要があります。
管理者ユーザーでプライマリテナントまたはソース側のスタンバイテナントにログインします。
以下のコマンドを実行して、アクセスポイント情報を取得します。
MySQLモード
obclient [oceanbase]> SELECT * FROM oceanbase.DBA_OB_ACCESS_POINT;説明
現在
sysテナントにログインしている場合は、CDB_OB_ACCESS_POINTビューをクエリしてアクセスポイント情報を取得する必要があります。Oracleモード
obclient [SYS]> SELECT * FROM SYS.DBA_OB_ACCESS_POINT;
クエリ結果は次のとおりです：
+-----------+-------------+-------------+----------+ | TENANT_ID | TENANT_NAME | SVR_IP | SQL_PORT | +-----------+-------------+-------------+----------+ | 1004 | mysql | xx.xx.xx.22 | 17855 | | 1004 | mysql | xx.xx.xx.23 | 17857 | | 1004 | mysql | xx.xx.xx.24 | 17859 | +-----------+-------------+-------------+----------+ 3 rows in setこの例では、クエリしたテナントには3つのレプリカがあります。プライマリテナントまたはソース側のスタンバイテナントがシングルレプリカテナントの場合は、1行の結果のみが返されます。
ステップ3：プライマリテナントの設定を確認する
現在のプライマリ/スタンバイアーキテクチャでは、プライマリテナントでスケールインやTransferなどの操作を実行した後、プライマリテナントのログストリームが削除されたり、ログが回収されたりして、スタンバイテナントのログ同期が停止する問題が発生しやすいです。この問題を解決するには、プライマリテナントでアーカイブモードを有効にするか、テナントレベルのパラメータls_gc_delay_timeを設定する必要があります。
プライマリテナントでログアーカイブが有効になっているか、パラメータls_gc_delay_timeが設定されているかを確認する方法は以下のとおりです：
プライマリテナントでアーカイブモードが有効になっているか確認する
管理者ユーザーでプライマリテナント、またはそのクラスタの
sysテナントにログインします。アーカイブモードが有効になっているかどうかを確認します。
プライマリテナントが存在するクラスタの
sysテナントobclient> SELECT LOG_MODE FROM oceanbase.DBA_OB_TENANTS WHERE TENANT_NAME='mysql';ユーザーテナント
MySQLモードOracleモードMySQLモードでアーカイブモードが有効かどうかを確認する：
obclient> SELECT LOG_MODE FROM oceanbase.DBA_OB_TENANTS;Oracleモードでアーカイブモードが有効かどうかを確認する：
obclient> SELECT LOG_MODE FROM SYS.DBA_OB_TENANTS;
クエリ結果の例は次のとおりです：
+--------------+ | LOG_MODE | +--------------+ | NOARCHIVELOG | +--------------+ 1 row in setクエリ結果によると、
ARCHIVELOGはプライマリテナントでアーカイブモードが有効であることを示し、NOARCHIVELOGは無効であることを示します。アーカイブモードを有効にする詳細な操作については、アーカイブモードの有効化を参照してください。
プライマリテナントのパラメータ
ls_gc_delay_timeの値が0sより大きいか確認するテナントレベルのパラメータ
ls_gc_delay_timeは、ログストリームの遅延削除時間を設定するために使用され、デフォルト値は0sで、ログストリームの遅延削除機能が無効であることを意味します。パラメータls_gc_delay_timeが設定されている場合でアーカイブが有効でない場合、ログストリームは削除条件を満たした後、一定時間待機してから回収されます。管理者ユーザーでプライマリテナントにログインします。
プライマリテナントのパラメータ
ls_gc_delay_timeの値を確認します。obclient> SHOW PARAMETERS LIKE '%ls_gc_delay_time%';クエリ結果によると、値が
0sの場合は未設定であり、ユーザーは必要に応じて設定できます。パラメータls_gc_delay_timeの詳細な設定方法および説明については、ls_gc_delay_timeを参照してください。
ステップ4：ログ復元ソースの設定
管理者ユーザーでスタンバイテナント、またはそのテナントが属するクラスタの
sysテナントにログインします。以下のコマンドを実行して、ログ復元ソースを設定します。
スタンバイテナントが存在するクラスタの
sysテナントが、そのスタンバイテナントのログ復元ソースを設定する場合ALTER SYSTEM SET LOG_RESTORE_SOURCE ='SERVICE=$ip_list USER=$user_name@$tenant_name PASSWORD=$password' TENANT = standby_tenant_name;スタンバイテナントが、自身のログ復元ソースを設定する場合
ALTER SYSTEM SET LOG_RESTORE_SOURCE ='SERVICE=$ip_list USER=$user_name@$tenant_name PASSWORD=$password';
主なパラメータの説明は以下の通りです：
$ip_list：プライマリテナント、またはソース側のスタンバイテナントが存在するレプリカのOBServerノードのIPアドレスとSQLポート番号。ここにはステップ2で取得した情報を入力します。複数のOBServerノード情報がある場合、すべてのOBServerノードの情報を入力する必要はありません。$user_name：ステップ1で作成したビューにアクセスするための専用ユーザー名。$tenant_name：接続先のプライマリテナント、またはソース側のスタンバイテナント名。$password：ビューにアクセスするための専用ユーザーのパスワード。
例：
obclient > ALTER SYSTEM SET LOG_RESTORE_SOURCE = 'SERVICE=11.xx.xx.22:17855;11.xx.xx.23:17857;11.xx.xx.24:17859 USER=rep_user@mysql PASSWORD=******' TENANT = standby_tenant;obclient > ALTER SYSTEM SET LOG_RESTORE_SOURCE = 'SERVICE=11.xx.xx.22:17855;11.xx.xx.23:17857;11.xx.xx.24:17859 USER=rep_user@mysql PASSWORD=******';設定が成功すると、システムテナント(
sysテナント)またはユーザーテナントは、それぞれCDB_OB_LOG_RESTORE_SOURCEビューおよびDBA_OB_LOG_RESTORE_SOURCEビューを使用して、ログ復元ソースが正常に変更されたかどうかを確認できます。詳細な操作については、ログ復元ソース情報の確認を参照してください。