リードレプリカの設定
別の Databases for MySQL 配置の読み取りレプリカになるように、 IBM Cloud® Databases for MySQL 配置を 設定できます。
リードレプリカは、非同期レプリケーションを使用して、ソースインスタンスからレプリカデプロイメントにすべてのデータをレプリケートするように設定されます。 その名の通り、リード・レプリカはリード・トランザクションをサポートし、書き込みの多い操作と読み込みの多い操作の両方を行うデータベースのバランスを取るために使用できる。 ソース・データベース・インスタンスで障害が発生した場合は、データ・リカバリーのために読み取りレプリカのプロモーションを使用することもできます。 読み取りレプリカには、 MySQL データ・メンバが 1 つあり、 ソース・データベース・インスタンスと同じメンバごとの消費率で 課金されます。
レプリカに関する考察を読む
-
リード・レプリカは、ソース・データベース・インスタンスと同じリージョンに存在することも、異なるリージョンに存在することもできます。
-
リード・レプリカは、ソース・データベース・インスタンスと同じメジャー・バージョンでなければなりません。
-
読み取り専用レプリカでは、バックアップは利用できません。 バックアップはソース・データベース・インスタンスに対してのみ行われる。
-
EU のクラウド対応リージョン (現時点では
eu-de
) を出入りする読み取りレプリケーションはサポートされません。 これらのリージョンの中ではサポートされます。 -
1つのソース・インスタンスにつきリード・レプリカは5つまでです。
-
リード・レプリカはソース・データベース・インスタンスの選挙には参加せず、リード・レプリカへのフェイルオーバーは自動化されません。 リードレプリカをフルデプロイメントに昇格させるのは、ユーザー主導の手動タスクである。
-
リード・レプリカの最小サイズは、2GBのRAMと20GBのディスクである。 これは、ソース・データベース・インスタンスのデプロイメントが小さくても同じです。
-
読み取りレプリカは、ソース・データベース・インスタンスに合わせて自動スケールされません。 保存するデータ量がデプロイメントに割り当てられているディスクを超える場合は、読み取りレプリカのディスクをスケーリングし、次にソース・データベース・インスタンスのディスクをスケーリングします。 最初にリードレプリカをスケーリングすることで、リードレプリカの容量が不足しないようにする。 ソース・データベース・インスタンスのディスクを、スペースではなくパフォーマンスのためにスケーリングした場合は、読み取りレプリカをスケーリングする必要はありません。
-
レプリケーションは非同期で行われるので、レプリケーションに遅れが生じることがあります。 デフォルトでは、プライマリーとレプリカの間で整合性に関する通信は行われません。 リードレプリカが再同期が必要なほど遅れてしまうことはあり得る。 レプリカがソースデータベースインスタンスから地理的に遠く離れた地域にある場合、レプリケーションのラ グはより大きくなる可能性があります。
-
リードレプリカは、単一のデータメンバーを持つデプロイメントであり、内部的な高可用性を持たない。 メンテナンス時には一時的な中断やダウンタイムが発生しがちです。 読み取りレプリカに依存するアプリケーションがある場合は、失敗したクエリを再試行するロジックや、複数の読み取りレプリカ上で負荷分散を行うロジックを必ず用意してください。
-
Databases for MySQL マドリード (
eu-es
) のリードレプリカ:マドリードのeu-es
リージョンにおける読み取りレプリカの展開は現在中断されています。 可用性に関する最新情報は、できるだけ早く提供されます
リーダー
リード レプリカがプロビジョニングされる前の Databases for MySQL 配置の[ リード レプリカ] タブでは、中央ペインにリード レプリカが存在しないことが表示され、[ 作成] ボタンが表示されます。

配置がリーダで、リード レプリカが既にアタッチされている場合、[ レプリケー ション] ペインにはレプリカ配置のリストと各レプリカへのリンクが表示されま す。

リードレプリカのプロビジョニング
リーダーの Read Replicas タブから、 Create Read Replicaをクリックして、リードレプリカをプロビジョニングすることができます。 ソース・インスタンスは自動的に入力されます。 リードレプリカの名前は_サービス名_フィールドに自動生成されるが、自由に名前を変更することができる。 レプリカをデプロイするリージョンと、初期メモリー割り振り量を選択できます。 ディスクのサイズ、バージョン、パブリックまたはプライベートのエンドポイントは、ソース データベース インスタンスの展開の設定に合わせて自動的に構成されます。
Key Protect を使用する場合は、CLI と API でプロビジョニングしないと、Bring Your Own Key (BYOK) がサポートされません。 そうでない場合、リードレプリカは生成された鍵で暗号化される。
API または CLI によるプロビジョニング
CLI および API を使用したリードレプリカのプロビジョニングは、 標準的な Databases for MySQL デプロイメントのプロビジョニングと 同様に動作します。 プロビジョニングはリソース・コントローラーで処理され、パラメーター {"remote_leader_id": "crn:v1:..."}
を使用して、プロビジョニングするレプリカのリーダーを指定します。
例えば、CLIでリード・レプリカをプロビジョニングする場合、
ibmcloud resource service-instance-create <replica_name> databases-for-mysql standard <region> \
-p \ '{
"remote_leader_id": "crn:v1:bluemix:public:databases-for-mysql:us-south:a/54e8ffe85dcedf470db5b5ee6ac4a8d8:1b8f53db-fc2d-4e24-8470-f82b15c71819::",
"members_memory_allocation_mb": "2048",
"members_disk_allocation_mb": "10240"
}'
リソースコントローラAPIでリードレプリカをプロビジョニングする場合も、同じパラメータを使用する。
curl -X POST \
https://resource-controller.cloud.ibm.com/v2/resource_instances \
-H 'Authorization: Bearer <>' \
-H 'Content-Type: application/json' \
-d '{
"name": "<replica_name>",
"target": "<region>",
"resource_group": "<your_resource_group_id>",
"resource_plan_id": "databases-for-mysql-standard",
"remote_leader_id": "crn:v1:bluemix:public:databases-for-mysql:us-south:a/54e8ffe85dcedf470db5b5ee6ac4a8d8:1b8f53db-fc2d-4e24-8470-f82b15c71819::",
"members_memory_allocation_mb": "2048",
"members_disk_allocation_mb": "10240"
}'
CLI コマンドと API コマンドのどちらの場合も、RAM 量とディスク量の両方を指定する必要があります。最小サイズは 2 GB の RAM と 20 GB のディスクであることに注意してください。 読み込みレプリカがパブリックエンドポイントを使用するか、プライベートエンドポイントを使用するかをオプションで指定できます。 リードレプリカにバージョンを指定することはできません。 バージョンは、ソースデータベースインスタンスのデプロイメントと同じメジャーバージョンに自動的に設定されます。
リード・レプリカ
リード・ レプリカの[リード・レプリカ] タブでは、[ レプリケーション ]ペインにその名前とリージョン、ソース・データベース・インスタンスの名前とリージョンが表示されます。 また、リードレプリカを再同期したり、促進したりするボタンもある。

レプリケーション状況の確認
レプリケーション状況は自動的にはモニターされません。ユーザーがレプリケーションをモニターする必要があります。
ソース データベース インスタンスから mysql
を使用して、リード レプリカのレプリケーション ステータスとレプリケーション ラグを確認できます。 mysql
でソース・データベース・インスタンスのデプロイメントに接続する は 管理者認証 を使っている。 接続したら、以下のコマンドを実行します。
mysql> SHOW SLAVE STATUS \G
コマンドの状況レポートのキー・フィールドは Seconds_Behind_Master: _
になります。 これは、レプリケーション SQL スレッドがソースのバイナリー・ログの処理をするのが遅れている秒数です。
詳しくは MySQLの 「Checking Replication Status」を参照してください。
レプリカのユーザーと権限を読む
-
ソースデータベースインスタンス上のどのユーザでも、リードレプリカのプロビジョニング前に存在していたユーザでも、ソースデータベースインスタンス上で持っているオブジェクトと同じ権限でリードレプリカにログインし、リードを実行することができます。
-
ソース・データベース・インスタンスにアタッチされている読み取りレプリカが複数ある場合、ソース上で作成されたユーザは、他のすべての読み取りレプリカ上でも作成されます。
-
admin
ユーザーを含め、ソース データベース インスタンスで作成されたユーザーは、リード レプリカがスタンドアロン配備に昇格したときにも保持されます。 読み取りレプリカが昇格すると、ソース データベース インスタンスのすべてのユーザのユーザと特権が昇格した配置に転送されます。 -
全ユーザのリードレプリカへの書き込み操作はフィルタされたり拒否されたりしませんが、データベースレベルで失敗します。
-
リード・レプリカ上に作成されたリード・レプリカ・ユーザーは、
SELECT
権限でソース・データベース・インスタンスに接続できます。
リードレプリカの再同期
リードレプリカを再同期する必要がある場合は、 Resync Read Replica ボタンをクリックします。 再同期は破壊的な操作であり、再同期を行うことでリードレプリカのデータが破壊され、再構築される。 再同期が実行されている間、リードレプリカは他の操作を実行したり、クエリを実行したりすることはできません。 クエリはソース・データベース・インスタンスに再ルーティングされないため、再同期が終了するまでリード・レプリカへの接続は失敗します。
リードレプリカの再同期にかかる時間はまちまちだが、非常に長い時間がかかることもある。
CLI を使用して再同期を開始するには、cdb read-replica-resync
コマンドを使用します。
ibmcloud cdb read-replica-resync <deployment name>
API を使用して再同期を開始するには、/deployments/{id}/remotes/resync
エンドポイントに POST を送信します。
curl -X POST \
https://api.{region}.databases.cloud.ibm.com/v4/ibm/deployments/{id}/remotes/resync \
-H 'Authorization: Bearer <>'
リードレプリカの推進
読み取りレプリカは、読み取り操作だけでなく書き込み操作も受け付ける独立したクラスタに昇格させることができる。 ソースデータベースインスタンスに何か起こった場合、リードレプリカをスタンドアロンクラスタに昇格させ、アプリケーションからの書き込みを受け付け始めることができます。
UIからリードレプリカをプロモートするには、 リードレプリカのプロモートボタンをクリックします。
昇格すると、読み取りレプリカはソース データベース インスタンスへの接続を終了し、スタンドアロンの Databases for MySQL 配置になります。 このデプロイメントは読み取り操作と書き込み操作の受け入れと実行を開始できます。バックアップが有効になり、独自の管理者ユーザーが発行されます。 新しいデータ・メンバーが追加されるので、デプロイメントは 3 つのデータ・メンバーを持つクラスターになります。 これによってコストは増えますが (メンバーの使用量を基準とする同じ料金が課金されるため)、デプロイメントのメンバーは 1 つではなく 3 つになります。
リードレプリカを昇格させる際、通常は昇格時に行われる初期バックアップをスキップすることができます。 初期バックアップをスキップすると、レプリカはより早く使用可能になりますが、即時バックアップは利用できません。 プロモーションのプロセスが完了したら、オンデマンド・バックアップを開始できます。
読み取りレプリカが独立した配置に昇格すると、それを読み取りレプリカに戻したり、ソース データベース インスタンスに再参加させたりすることはできません。
CLI を使用してプロモートするには、cdb read-replica-promote
コマンドを使用します。
ibmcloud cdb read-replica-promote <deployment name>
API を使用してプロモートするには、/deployments/{id}/remotes/promotion
エンドポイントに POST を送信します。
curl -X POST \
https://api.{region}.databases.cloud.ibm.com/v4/ibm/deployments/{id}/remotes/promotion \
-H 'Authorization: Bearer <>' \
-H 'Content-Type: application/json' \
-d '{"promotion": {}}' \
プロモートし、プロモート後の初期バックアップをスキップするには、JSON 本文に skip_initial_backup
も設定します。
curl -X POST \
https://api.{region}.databases.cloud.ibm.com/v4/ibm/deployments/{id}/remotes/promotion \
-H 'Authorization: Bearer <>' \
-H 'Content-Type: application/json' \
-d '{"promotion": {"skip_initial_backup": true}}' \
完了までの時間
プロモート・レシピは、データベースの可用性が高いときにのみ完了します。 ただし、読み取り/書き込みの可用性は約 10 分後に 1 つの重要な警告と共に発生します。つまり、レシピが完了するまでデータベースの可用性は高くならないということです。
読み取りレプリカの全プロモーション時間は、データのサイズに基づいて、以下の 2 つの可能な方法によって判別されます。
- 読み取りレプリカはそれぞれ単一のメンバーです。 昇格すると、2人のメンバーがレプリカとして追加される。 その時間は、データのサイズによって異なります。 データベースが拡大すると、作成には相当の時間がかかるようになります。 プロモート操作は、両方のレプリカが作成されるまで完了しません。
- プロモーションの一部としてバックアップを行う場合、そのバックアップの完成も終了してからでなければ、レシピは完了しません。 これについても、データベースのサイズによって異なります。
プロモーションレシピが完了するまで、高可用性メンバーは存在しないことを忘れないでください。 同様に、初期バックアップを行うことにした場合、2 番目のポイントが完了するか手動バックアップが作成されるまで、バックアップは存在しません。