DBインスタンスは仮想機器とインストールされたMariaDBを包括する概念で、 RDS for MariaDBが提供するMariaDBの単位です。 DBインスタンスのOSに直接アクセスすることはできず、DBインスタンス作成時に入力したポートを介してデータベースにのみアクセスできます。使用できるポート範囲には以下のような制約事項があります。
DBインスタンスは、顧客が付与する名前と自動的に付与される32バイトのIDで識別されます。 DBインスタンス名は下記のような制約事項があります。
下記の設定でDBインスタンスを作成できます。
NHN Cloudは、物理的なハードウェアの問題で生じる障害に備えるため、システム全体を複数のアベイラビリティゾーンに分けています。このアベイラビリティゾーンごとに、ストレージシステム、ネットワークスイッチ、ラック、電源装置がすべて別々に構成されています。1つのアベイラビリティゾーン内で起こる障害は他のアベイラビリティゾーンに影響を与えないため、サービス全体の可用性が高くなります。DBインスタンスを複数のアベイラビリティゾーンに分けて構築すれば、サービスの可用性をさらに高めることができます。複数のアベイラビリティゾーンに分散して作成されたDBインスタンス同士でネットワーク通信が可能で、この時発生するネットワーク使用費用は請求されません。
[注意] すでに作成したDBインスタンスのアベイラビリティゾーンは変更できません。
以下に明示されたバージョンを使用できます。
バージョン | 備考 |
---|---|
----------------- | ---- |
MariaDB 10.6.16 | |
MariaDB 10.6.12 | |
MariaDB 10.6.11 | |
MariaDB 10.3.30 |
DBエンジンの場合、作成後、Webコンソールの修正機能でバージョンアップが可能です。 DBエンジンの詳細はDBエンジンで確認できます。
DBインスタンスはタイプごとに異なるCPUコア数とメモリ容量を持っています。 DBインスタンス作成時、データベースのワークロードに応じて適切なDBインスタンスタイプを選択する必要があります。
タイプ | 説明 |
---|---|
m2 | CPUとメモリをバランスよく設定したタイプです。 |
c2 | CPUのパフォーマンスを高く設定したインスタンスタイプです。 |
r2 | 他のリソースに比べてメモリの使用量が多い場合に使用できます。 |
x1 | 高スペックのCPUとメモリをサポートするタイプです。高性能が必要なサービスやアプリケーションに使用します。 |
作成済みのDBインスタンスのタイプはWebコンソールから簡単に変更できます。
[注意] 作成済みのDBインスタンスのタイプを変更すると、DBインスタンスが終了するため、多少のダウンタイムが発生します。
データストレージにデータベースのデータファイルを保存します。DBインスタンスは、HDD、SSDの2種類のデータストレージタイプをサポートします。データストレージの種類によって性能と価格が異なるため、データベースのワークロードに応じて適切なタイプを選択する必要があります。データストレージは20GB~2TBで作成できます。
[注意] すでに作成したDBインスタンスのデータストレージタイプは変更できません。
[参考] データストレージを2TB以上使用する場合は、NHN Cloudサポートに連絡してください。
以下の作業は、データストレージのI/O使用率が高くなるため、進行中にDBインスタンスの性能が低下する可能性があります。
高可用性DBインスタンスは、可用性とデータの耐久性を高め、障害許容が可能なデータベースを提供します。高可用性DBインスタンスはマスター、予備マスターで構成され、異なる可用性領域に作成されます。予備マスターは障害に備えたDBインスタンスで、普段は使用できません。高可用性DBインスタンスの場合、予備マスターでバックアップが行われるため、バックアップによる性能低下を回避できます。高可用性DBインスタンスが提供する様々な機能は高可用性DBインスタンスで確認できます。
DBインスタンスに接続するVPCサブネットを選択する必要があります。同じサブネットに接続されたComputeサービスのインスタンス間では、別途のFloating IPなしで通信することができ、ネットワークトラフィックに対する費用が請求されません。 DBインスタンスは基本的にすべてのネットワークアクセスを遮断するため、接続を希望する場合は、DBセキュリティグループを適用する必要があります。
[注意] 作成済みのDBインスタンスのサブネットは変更できません。
外部からDBインスタンスにアクセスするには、Floating IPをDBインスタンスに接続する必要があります。Internet Gatewayが接続されたサブネットを接続する場合のみFloating IPを作成できます。Floating IPは使用と同時に課金され、これとは別にFloating IPを介したインターネット方向のトラフィックが発生する場合は別途課金されます。
パラメータグループは、DBインスタンスにインストールされたデータベースを設定できるパラメータの集合です。DBインスタンス生成時に必ず一つのパラメータグループを選択しなければなりません。パラメータグループは、作成後も自由に変更できます。パラメータグループの詳しい説明はパラメータグループの項目を参照してください。
DBセキュリティグループは、外部からの侵入に備えて接続を制限するために使用します。送受信トラフィックに対して特定のポート範囲あるいはデータベースポートに対してアクセスを許可できます。DBインスタンスに複数のDBセキュリティグループを適用できます。DBセキュリティグループの詳しい説明はDBセキュリティグループを参照してください。
DBインスタンスのデータベースを定期的にバックアップするように設定したり、コンソールから好きなタイミングでバックアップを作成できます。バックアップが実行されている間、パフォーマンスの低下が発生する場合があります。サービスに影響を与えないように、サービスの負荷が少ない時間にバックアップすることを推奨します。バックアップによる性能低下を望まない場合は、高可用性構成を使用するか、以前バックアップ以降のデータの増分のみをバックアップすることができ、読み取りレプリカでバックアップを実行できます。バックアップファイルは内部オブジェクトストレージに保存され、バックアップ容量に応じて課金されます。必要に応じて、NHN Cloudのユーザーオブジェクトストレージにエクスポートできます。予期せぬ障害に備えるため、定期的にバックアップを行うように設定することを推奨します。バックアップの詳細については、バックアップと復元を参照してください。
DBインスタンス作成時、基本通知を設定できます。基本通知を設定すると、{{DBインスタンス名}-default
という名前で新しい通知グループが作成され、下記の通知項目が自動で設定されます。基本通知として作成された通知グループは自由に修正、削除できます。通知グループについての詳しい説明は通知グループを参照してください。
項目 | 比較方法 | しきい値 | 持続時間 |
---|---|---|---|
CPU使用率 | >= | 80% | 5分 |
Storageの空き容量 | <= | 5,120MB | 5分 |
Database Connection Status | <= | 0 | 0分 |
Storage使用量 | >= | 95% | 5分 |
ストレージ障害 | <= | 0 | 0分 |
Connection Ratio | >= | 85% | 5分 |
メモリ使用量 | >= | 90% | 5分 |
Slow Query | >= | 60 counts/min | 5分 |
削除保護を有効にすると、誤ってDBインスタンスが削除されないように保護できます。
Webコンソールで作成されたDBインスタンスを確認できます。レプリケーショングループ単位でまとめて見たり、個別DBインスタンスで見ることができます。
❶ DBインスタンス画面モードを変更できます。 ❷ボタンをクリックして、グループ内に属するDBインスタンスを展開したり、折りたたむことができます。 ❸最近収集されたモニタリング指標を表示します。 ❹現在の状態を見ることができます。 ❺進行中の作業がある場合、スピナーが表示されます。
DBインスタンスの状態は下記のような値で構成され、ユーザーの行為と現在の状態によって変更されます。
状態 | 説明 |
---|---|
BEFORE_CREATE | 作成前 |
AVAILABLE | 使用可能 |
STORAGE_FULL | 容量不足 |
FAIL_TO_CREATE | 作成失敗 |
FAIL_TO_CONNECT | 接続失敗 |
REPLICATION_STOP | 複製中断 |
FAILOVER | フェイルオーバー完了 |
SHUTDOWN | 停止した |
変更できる検索条件は次のとおりです。
❶パラメータ変更事項適用が必要なDBインスタンスをフィルタリング条件で検索できます。
DBインスタンスを選択すると、詳細情報を見ることができます。
❶接続情報のドメインをクリックすると、IPアドレスを確認できるポップアップが表示されます。 ❷ DBセキュリティグループをクリックすると、DBセキュリティルールを確認できるポップアップが表示されます。 ❸パラメータグループをクリックすると、パラメータを確認できる画面に移動します。 ❹マウスでドラッグ&ドロップして詳細情報パネルの高さを調整できます。 ❺詳細情報パネルの高さをあらかじめ指定した高さに調整できます。
DBインスタンス作成時に内部ドメインを発行します。内部ドメインは、ユーザーのVPCサブネットに属するIPアドレスを指します。高可用性DBインスタンスの場合、フェイルオーバーで予備マスターが新しいマスターに変更されても内部ドメインは変更されません。したがって、特別な理由がなければ、アプリケーションの接続情報は必ず内部ドメインを利用する必要があります。
Floating IPを作成した場合、外部ドメインを追加で発行します。外部ドメインはFloating IPのアドレスを指します。外部ドメインまたはFloating IPは外部からアクセスが可能なので、DBセキュリティグループのルールを適切に設定してDBインスタンスを保護する必要があります。
DBインスタンスのログタブでは、各種ログファイルの閲覧や、ダウンロードを行うことができます。ログファイルは下記のように決められた設定でローテーションされます。一部のログファイルは、パラメータグループで有効または無効にできます。
項目 | ローテーション設定 | 変更するかどうか | 関連パラメータ |
---|---|---|---|
error.log | 100MB 10個 | 固定 | |
slow_query.log | 100MB 40個 | 固定 | slow_query_log |
general_log.log | 100MB 40個 | 固定 | general_log |
server_audit.log | 20MB 30個 | 変更可能 | server_audit_logging server_audit_file_rotations |
mysql-bin.xxxxxx | 5日 | 変更可能 | binlog_expire_logs_seconds (8.Xバージョン)expire_logs_days (5.Xバージョン) |
❶ ログ表示をクリックすると、ログファイルの内容を確認できるポップアップ画面が表示されます。最大65,535Bytesのログを確認できます。 ❷ インポートをクリックすると、DBインスタンスのログファイルをダウンロードするようにリクエストします。 ❸ダウンロードの準備が整うと、ダウンロードボタンが表示されます。クリックすると、ログをダウンロードします。
[注意] インポートをクリックすると、約5分間、ログファイルがバックアップストレージにアップロードされ、ログファイルのサイズ分だけバックアップストレージの容量が課金されます。 ダウンロードをクリックすると、ログファイルのサイズ分だけインターネットトラフィックが課金されます。
❹バイナリログ(binary log)の場合、2つの形式でダウンロードできます。インポートをクリックすると、バイナリログの形式を選択できるポップアップ画面が表示されます。
❺ mysqlbinlogユーティリティを利用してバイナリログ(binary log)をSQLファイルに変換してダウンロードする場合は選択します。
DBインスタンスのDBスキーマ&ユーザータブでは、データベースに作成されたスキーマとユーザーの照会及び制御を行うことができます。
❶ 作成をクリックすると、DBスキーマの名前を入力できるポップアップウィンドウが表示されます。 ❷ DBスキーマ名を入力した後、確認をクリックしてDBスキーマを作成することができます。
DBスキーマ名には下記のような制約事項があります。
information_schema
, performance_schema
, db_helper
, sys
, mysql
, rds_maintenance
はDBスキーマ名として使用できません。作成されたDBスキーマの名前は修正できません。
❶削除するDBスキーマを選択し、ドロップダウンメニューをクリックします。 ❷ 削除メニューをクリックすると、削除確認ポップアップ画面が表示されます。確認をクリックして削除をリクエストできます。
❶ +作成をクリックすると、ユーザー追加ポップアップ画面が表示されます。 ❷ユーザーIDを入力します。
ユーザーIDには以下のような制約があります。
mysql.session
, mysql.sys
, mysql.infoschema
, sqlgw
, admin
, etladm
, alertman
, prom
, rds_admin
, rds_mha
, rds_repl
はユーザーIDとして使用できません。❸ Passwordを入力します。
❹接続を許可するHost IPを入力します。%
文字を利用すると、許可するHost IPを範囲として指定できます。例えば、1.1.1.1.1.%
は、1.1.1.0
~1.1.1.255
の間のすべてのIPを意味します。
❺ユーザーに付与する権限を選択します。付与できる権限と説明は次のとおりです。
READ * 照会権限を持っています。
GRANT SELECT, SHOW VIEW, PROCESS, SHOW DATABASES, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO '{user_id}'@'{host}';
GRANT SELECT ON `mysql`.* TO '{user_id}'@'{host}';
GRANT SELECT, EXECUTE ON `sys`.* TO '{user_id}'@'{host}';
GRANT SELECT ON `performance_schema`.* TO '{user_id}'@'{host}';
CRUD * READ権限を含み、データを変更する権限を持っています。
GRANT INSERT, UPDATE, DELETE, CREATE TEMPORARY TABLES, LOCK TABLES, EXECUTE ON *.* TO '{user_id}'@'{host}';
DDL * CRUD権限を含み、DDLクエリを実行する権限を持っています。
GRANT CREATE, DROP, INDEX, ALTER, CREATE VIEW, REFERENCES, EVENT, ALTER ROUTINE, CREATE ROUTINE, TRIGGER, RELOAD ON *.* TO '{user_id}'@'{host}';
GRANT EXECUTE ON `mysql`.* TO '{user_id}'@'{host}';
CUSTOM * 外部データベースのバックアップからDBインスタンスを復元した場合、データベースに存在する全てのユーザーはCUSTOM権限で表現されます。 * CUSTOM権限テンプレートにはどのような権限があるのか分かりません。 * CUSTOM権限テンプレートから他の権限テンプレートに変更した場合、再びCUSTOM権限テンプレートに変更することはできません。
❶修正するユーザー行の修正をクリックすると、ユーザー情報を修正できるポップアップ画面が表示されます。 ❷ Passwordを入力しないと変更されません。
❶削除するユーザーを選択し、ドロップダウンメニューをクリックします。 ❷ 削除をクリックすると、削除確認ポップアップ画面が表示されます。確認をクリックして削除をリクエストできます。
Webコンソールを通じて作成されたDBインスタンスの様々な項目を簡単に変更できます。変更要求した項目は、順次DBインスタンスに適用されます。適用過程で再起動が必要な場合、すべての変更を適用した後、DBインスタンスを再起動します。変更不可能な項目と再起動が必要な項目は次のとおりです。
項目 | 変更可否 | 再起動が必要かどうか |
---|---|---|
アベイラビリティゾーン | いいえ | |
DBエンジン | はい | はい |
DBインスタンスタイプ | はい | はい |
データストレージ種類 | いいえ | |
データストレージサイズ | はい | はい |
高可用性の有無 | はい | いいえ |
Ping間隔 | はい | いいえ |
名前 | はい | いいえ |
説明 | はい | いいえ |
DBポート | はい | はい |
VPCサブネット | いいえ | |
Floating IP | はい | いいえ |
パラメータグループ | はい | 変更されたパラメータの再起動するかどうかで決定 |
DBセキュリティグループ | はい | いいえ |
バックアップ設定 | はい | いいえ |
スキーマ&ユーザー制御 | はい | いいえ |
高可用性DBインスタンスの場合、再起動が必要な項目の変更がある場合、安定性を高め、瞬断時間を減らすためにフェイルオーバーを利用した再起動機能を提供します。
フェイルオーバーを利用した再起動を使用しない場合は、マスターと予備マスターに変更事項を順次適用した後、DBインスタンスを再起動します。詳細は高可用性DBインスタンスの手動フェイルオーバー項目を参照してください。
RDS for MariaDBではDBスキーマとユーザーを簡単に管理できるようにコンソールで管理機能を提供していますが、ユーザーが直接制御できるように設定する機能も提供しています。直接制御を使う場合、現在作成されている全てのユーザーに下記の権限を付与します。
GRANT CREATE,DROP,LOCK TABLES,REFERENCES,EVENT,ALTER,INDEX,INSERT,SELECT,UPDATE,DELETE,CREATE VIEW,SHOW VIEW,CREATE ROUTINE,ALTER ROUTINE,EXECUTE,CREATE USER,PROCESS,RELOAD,REPLICATION SLAVE,REPLICATION CLIENT,SHOW DATABASES, CREATE TEMPORARY TABLES,TRIGGER ON *.* TO '{user_id}'@'{host}' WITH GRANT OPTION;
[直接] コントロールを使用した後、再度使用しないに変更した時の注意点 * 既に付与した権限を回収しません。 この時、コマンドを使用してDBスキーマやユーザーを追加すると、Webコンソールのデータと整合性が合わなくなる場合があります。 * ユーザーに付与された権限と関係なく、データベースに存在するすべてのユーザーはCUSTOM権限で表現されます。
DBインスタンスOSアップグレードをサポートします。OSのアップグレードにより、セキュリティ脆弱性の解決やOSのEOL(end of life)に対応できます。 OSアップグレードはサービス瞬断が発生するため注意が必要です。高可用性DBインスタンスはフェイルオーバーにより、サービス瞬断を最小限に抑えることができます。
現在のDBインスタンスのOS情報は、DBインスタンスの詳細画面で確認できます。
❶ DBインスタンスのOS情報を確認できます。 ❷ OSがバージョンアップグレード対象である場合、OSバージョンアップグレードボタンが表示されます。
OSバージョンアップグレードは、高可用性構成であるかどうかによって異なります。高可用性の場合は、フェイルオーバーを利用してOSバージョンアップグレードを実行します。高可用性ではない場合は、DBインスタンスを再起動してOSバージョンアップグレードを実行します。
単一DBインスタンスのOSバージョンアップグレードボタンをクリックすると、次のようなポップアップ画面が表示されます。
高可用性DBインスタンスのOSバージョンアップグレードボタンをクリックすると、次のようなポップアップ画面が表示されます。詳細については、高可用性DBインスタンスの手動フェイルオーバー項目を参照してください。
使用しないDBインスタンスは削除できます。マスターを削除すると、そのレプリケーショングループに属する予備マスターとリードレプリケーションも全て削除されます。削除されたDBインスタンスは復旧できないため、重要なDBインスタンスは削除保護設定を有効にすることを推奨します。
障害状況に備えて、DBインスタンスのデータベースを復旧できるように事前に準備できます。必要な時にコンソールでバックアップを実行したり、定期的にバックアップが実行されるように設定できます。詳細はバックアップの項目を参照してください。
バックアップを利用して希望の時点にデータを復元できます。復元時には常に新しいDBインスタンスが作成され、既存のDBインスタンスに復元することはできません。詳細は復元の項目を参照してください。
急激な負荷でバイナリログ(binary log)が過剰に生成され、ストレージの容量が不足する場合、Webコンソールの容量確保機能を利用してバイナリログを削除できます。Webコンソールで容量確保を選択すると、DBインスタンスのバイナリログを選択できるポップアップ画面が表示されます。バイナリログを選択した後、OKを押して選択した項目より前に生成された全てのバイナリログを削除します。容量確保機能は一時的に容量を確保する機能です。継続して容量が不足する場合は、サービス負荷に合わせてバイナリログの保存期間を設定するか、ストレージのサイズを拡張する必要があります。
[参考]
binlog_expire_logs_seconds
パラメータでバイナリログ(binary log)の保存期間を設定できます。[注意] 削除されたバイナリログ(binary log)によっては、特定の時点への復元ができない場合があります。
DBインスタンスに接続されたパラメータグループの設定が変更されても、この変更はDBインスタンスに自動的に適用されません。DBインスタンスに適用されたパラメータと接続されたパラメータグループの設定が異なる場合、コンソールにパラメータボタンが表示されます。
次のいずれかの方法を使用してDBインスタンスにパラメータグループの変更を適用できます。
❶対象DBインスタンスのパラメータをクリックする。 ❷対象DBインスタンスを選択した後、ドロップダウンメニューのパラメータグループ変更適用メニューをクリックするか、または ❸対象DBインスタンスの基本情報タブでパラメータグループの変更事項の適用をクリックする。
パラメータグループで再起動を必要とするパラメータが変更された場合、変更内容を適用する過程でDBインスタンスが再起動されます。
高可用性DBインスタンスの場合、安定性を高め、瞬断時間を減らすためにフェイルオーバーを利用した再起動機能を提供します。
フェイルオーバーを利用した再起動を使用しない場合は、マスターと予備マスターに変更事項を順次適用した後、DBインスタンスを再起動します。詳細は高可用性DBインスタンスの手動フェイルオーバー項目を参照してください。
外部MariaDBのバックアップファイルをNHN Cloudのユーザーオブジェクトストレージにアップロードして、RDS for MariaDBのDBインスタンスに復元することができます。詳細は、外部MariaDBバックアップを利用した復元を参照してください。
バックアップ後、バックアップファイルをユーザーオブジェクトストレージにエクスポートできます。詳細については、バックアップエクスポート項目を参照してください。
読み取り性能を高めるために、読み取り専用に使用できるリードレプリカを作成できます。リードレプリカは1つのマスターに対して最大5台まで作成できます。リードレプリカのリードレプリカは作成できません。
リードレプリカを作成するには、レプリケーショングループに属するDBインスタンスのうち、テーブルロック使用オプションで作成されたバックアップファイルとバイナリログ(binary log)が必要です。バックアップファイルがない場合、次の順序でバックアップを実行するDBインスタンスを選択します。
❶自動バックアップを設定したリードレプリカ ❷自動バックアップを設定した予備マスター ❸自動バックアップを設定したマスター
条件に合致するDBインスタンスがない場合、リードレプリカ作成リクエストは失敗します。
[注意] リードレプリカ作成時、マスターのI/O性能が通常より低くなることがあります。 バックアップが実行されるDBインスタンスの場合、リードレプリカの作成過程でストレージI/O性能が低下する可能性があります。
[参考] リードレプリカの作成過程で必要なバイナリログ(binary log)サイズ分、オブジェクトストレージ課金が発生する可能性があります。
リードレプリカを作成するには、Webコンソールで
❶原本DBインスタンスを選択した後、[リードレプリカ作成]をクリックすると
以下の設定でリードレプリカを作成できます。
リードレプリカを作成する際、下記の項目は原本DBインスタンスの設定に従うため、変更できません。
リードレプリカを作成するリージョンを選択する際、リージョンピアリングをサポートする場合、異なるリージョンに存在するVPC間のリージョンピアリングを接続すると、他のリージョンVPCに属するサブネットにリードレプリカを作成できます。ただし、元のDBインスタンスのリージョンと異なるリージョンを選択すると、レプリケーションの遅延が発生する可能性があり、DBバージョンのアップグレードをサポートしません。
[注意] リージョンピアリングが接続されていても、ルート設定が正しくない場合、リードレプリカの作成に失敗したり、レプリケーションが中断されることがあります。
リードレプリカのアベイラビリティゾーンを選択します。詳しい説明はアベイラビリティゾーン項目を参照してください。
リードレプリカは、マスターと同じ仕様またはより高い仕様で作成することを推奨します。低い仕様で作成すると、複製遅延が発生する場合があります。
原本DBインスタンスと同じサイズで作成することを推奨します。サイズを小さく設定する場合、データストレージ容量不足で複製プロセスが中断される場合があります。
リードレプリカのFloating IPを使用するかどうかを選択します。詳しい説明はFloating IPの項目を参照してください。
リードレプリカのパラメータグループを選択する際、レプリケーション関連設定を変更する必要がない場合は、元のDBインスタンスと同じパラメータグループを選択することを推奨します。パラメータグループの詳しい説明はパラメータグループ項目を参照してください。
リードレプリカに適用するDBセキュリティグループを選択します。レプリケーションに必要なルールは自動的に適用されるため、DBセキュリティグループに別途レプリケーション関連ルールを追加する必要はありません。 DBセキュリティグループの詳しい説明はDBセキュリティグループの項目を参照してください。
マスターとの複製関係を解除して、リードレプリカを独立したマスターに転換する過程を昇格といいます。昇格したマスターは独立したDBインスタンスとして動作します。昇格を希望するリードレプリカとマスターの間に複製遅延が存在する場合、その遅延が解決されるまで昇格が行われません。一度昇格されたDBインスタンスは、以前の複製関係に戻すことはできません。
[注意] マスターDBインスタンスの状態が異常な場合は、昇格作業を進めることができません。
[参考] リードレプリカが位置するリージョンと同じリージョンのコンソールを通じて昇格作業を行うことができます。
マスターや原本リージョンの状態に関係なく、リードレプリカの現在時点のデータに基づいて強制昇格を行います。複製遅延がある場合、データ損失が発生する可能性があります。したがって、リードレプリカを緊急にサービスに投入しなければならない状況でない限り、この機能の使用は推奨しません。
リードレプリカは、さまざまな理由で複製が中断されることがあります。リードレプリカの状態が複製中断
の場合、すぐに原因を確認して正常化する必要があります。複製中断
状態が長時間続く場合、複製ディレイが長くなります。正常化に必要なバイナリログ(binary log)がない場合、リードレプリカを再構築する必要があります。複製が中断した原因はリードレプリカでSHOW SLAVE STATUS
コマンドを使用して確認できます。Last_Errno
の値が1062の場、以下のProcedureをエラーが消えるまで呼び出せます。
mariadb> CALL mysql.tcrds_repl_skip_repl_error();
リードレプリカの複製問題を解決できない場合、再構築を通じて正常な状態に復元できます。この過程でリードレプリカの全てのデータベースを削除し、マスターデータベースを基盤に新たに再構築します。再構築中は、リードレプリカは使用できません。リードレプリカを再構築するには、レプリケーショングループに属するDBインスタンスのうち、テーブルロック使用オプションで作成されたバックアップファイルとバイナリログ(binary log)が必要です。バックアップファイルがない場合、動作及び注意事項はリードレプリカの作成の項目を参照してください。
[参考] 再構築後も接続情報(ドメイン、IP)は変更されません。
MariaDBを再起動したり、高可用性DBインスタンスを手動でフェイルオーバーしたい場合、DBインスタンスを再起動できます。再起動時間を最小化するため、サービス負荷が低い時間帯に行うことをお勧めします。高可用性DBインスタンスの場合、フェイルオーバーを利用した再起動を使用しない場合、予備マスターを先に再起動した後、マスターを再起動します。フェイルオーバー機能を利用した再起動の場合、手動フェイルオーバー項目を参照してください。
DBインスタンスを再起動するには、Webコンソールで
❶再起動を希望するDBインスタンスを選択した後、ドロップダウンメニューからDBインスタンスの再起動メニューをクリックします。
DBインスタンスのMariaDBが正常に動作しない場合、強制的に再起動できます。強制再起動の場合、MariaDBにSIGTERMコマンドを実行して正常終了するのを10分間待ちます。10分以内にMariaDBが正常終了したら、仮想マシンを再起動します。10分以内に正常終了しない場合、仮想マシンを強制的に再起動します。仮想マシンが強制的に再起動されると、作業中の一部のトランザクションが失われる可能性があり、データボリュームが破損して復旧が不可能になる可能性があります。強制再起動後、DBインスタンスの状態が使用可能な状態に戻らない場合があります。このような状況が発生した場合は、サポートにお問い合わせください。
[注意] データが消失したり、データボリュームが破損する可能性があるため、この機能は緊急かつ不可避な状況以外では使用を控えてください。
[参考] 高可用性DBインスタンスの場合、強制再起動はできません。
DBインスタンスを強制的に再起動するには、Webコンソールで
❶強制再起動を希望するDBインスタンスを選択した後、ドロップダウンメニューからDBインスタンス強制再起動メニューをクリックします。
削除保護を有効にすると、誤ってDBインスタンスが削除されないように保護できます。削除保護を無効化するまで、そのDBインスタンスを削除できません。削除保護設定を変更するには
❶削除保護設定を変更したいDBインスタンスを選択した後、ドロップダウンメニューから削除保護設定変更メニューをクリックすると、ポップアップウィンドウが表示されます。
❷削除保護設定を変更した後、確認をクリックします。
高可用性DBインスタンスは可用性とデータ耐久性を増加させ、障害許容が可能なデータベースを提供します。高可用性DBインスタンスはマスター、予備マスターで構成され、異なるアベイラビリティゾーンに作成されます。予備マスターは障害に備えたDBインスタンスで、通常は使用できません。高可用性DBインスタンスの場合、予備マスターでバックアップが行われます。
[参考] 高可用性DBインスタンスの場合、MariaDBクエリ文を使用して他のDBインスタンスまたは外部MariaDBのMasterから強制的に複製するように設定すると、高可用性および一部の機能が正常に動作しません。
予備マスターには障害を検出するためのプロセスが存在し、定期的にマスターの状態を検出します。このような検出周期をPing間隔と呼び、4回連続状態チェックに失敗した場合、フェイルオーバーを実行します。Ping間隔が短いほど障害に敏感に反応し、Ping間隔が長いほど障害に鈍感に反応します。サービス負荷に合わせて適切なPing間隔を設定することが重要です。
[参考] マスターのストレージ使用量がいっぱいになると、高可用性監視プロセスが障害として検出し、フェイルオーバーを実行するので注意してください。
予備マスターでマスターの状態チェックに4回連続失敗した場合、マスターがサービスを提供できないと判断し、自動的にフェイルオーバーを実行します。スプリットブレイン防止のため、障害が発生したマスターに割り当てられたすべてのユーザーセキュリティグループの接続を解除して外部からの接続を遮断し、予備マスターがマスターの役割を代行します。接続のための内部ドメインのA recordは障害が発生したマスターから予備マスターに変更されるので、アプリケーションの変更は必要ありません。フェイルオーバーが完了すると、障害が発生したマスターの種類はフェイルオーバーが発生したマスターに、予備マスターの種類はマスターに変更されます。フェイルオーバーが発生したマスターを復旧または再構築するまでフェイルオーバーは実行されません。昇格されたマスターは、フェイルオーバーが発生したマスターのすべての自動バックアップを継承します。フェイルオーバーの過程でマスターが変更されると、バイナリログがすべて削除されるため、既存のバックアップを利用した時点復元はサポートされません。昇格されたマスターで新規にバックアップが行われた時点から時点復元を行うことができます。
[参考] 高可用性機能はドメインに基づいているため、接続をしようとするクライアントがDNSサーバーに接続できないネットワーク環境の場合、ドメインを介してDBインスタンスに接続することができず、フェイルオーバー発生時、正常な接続ができません。 内部ドメインのA recordの変更が反映されるのに約3秒程度かかります。所要時間は、接続を試みるクライアント環境のDNS Cacheポリシーによって異なる場合があります。
[注意] マスターと予備マスター間のバイナリログ(binary log)のposition numberの値が100,000,000,000以上差がある場合、フェイルオーバーが行われません。
障害が発生してフェイルオーバーが発生したマスターをフェイルオーバーが発生したマスターといいます。フェイルオーバーが発生したマスターの自動バックアップは行われず、フェイルオーバーが発生したマスターの復旧、再構築、分離、削除を除く他のすべての機能は実行できません。
フェイルオーバーの過程でデータの整合性が崩れず、障害が発生した時点から復旧を試みる時点までバイナリログ(binary log)が失われなければフェイルオーバーが発生したマスターと昇格したマスターを再び高可用性構成で復旧できます。フェイルオーバーが発生したマスターのデータベースをそのまま昇格されたマスターと複製関係を再設定するため、データの整合性が崩れたり復旧に必要なバイナリログ(binary log)が失われた場合、復旧は失敗します。フェイルオーバーが発生したマスターの復旧に失敗した場合、再構築を通じて再び高可用性機能を有効にできます。
[参考] 2023年4月11日以前にフェイルオーバーが発生したDBインスタンスの場合、復旧をサポートしません。
フェイルオーバーされたマスターを復旧するには、Webコンソールで
❶復旧を希望するフェイルオーバーされたマスターを選択した後、ドロップダウンメニューからフェイルオーバーされたマスターの復旧メニューをクリックします。
フェイルオーバーが発生したマスターの復旧に失敗した場合、再構築を利用して再び高可用性機能を有効にできます。再構築は復旧とは異なり、フェイルオーバーが発生したマスターのデータベースを全て削除し、昇格したマスターのデータベースを基に再構築します。バックアップファイルがない場合、次の順序でバックアップを実行するDBインスタンスを選択します。
❶自動バックアップを設定したリードレプリカ ❷自動バックアップを設定したマスター
条件に合うDBインスタンスがない場合、フェイルオーバーされたマスターの再構築要求は失敗します。
[注意] マスターのデータベースサイズに比例して、フェイルオーバーされたマスターの再構築時間が長くなる場合があります。 バックアップが実行されるDBインスタンスの場合、フェイルオーバーされたマスター再構築の過程で、ストレージI/O性能が低下する可能性があります。
[参考] フェイルオーバーされたマスターの再構築過程に必要なバイナリログ(binary log)サイズ分、バックアップストレージの課金が発生する可能性があります。
フェイルオーバーされたマスターを再構築するには、Webコンソールで
❶再構築を希望するフェイルオーバーされたマスターを選択した後、ドロップダウンメニューからフェイルオーバーされたマスターの再構築メニューをクリックします。
フェイルオーバーされたマスターの復旧に失敗してデータ補正が必要な場合、フェイルオーバーされたマスターを分離して高可用性機能を無効にできます。分離されたマスターと昇格されたマスター間の複製関係が切断され、それぞれ一般的なDBインスタンスとして動作します。分離された後は、元の構成に復旧することはできません。
フェイルオーバーされたマスターを分離するには、Webコンソールで
❶分離を希望するフェイルオーバーされたマスターを選択した後、ドロップダウンメニューからフェイルオーバーされたマスター分離メニューをクリックします。
フェイルオーバーが発生したマスターの復旧に失敗してデータ補正が必要な場合、そのマスターを分離して高可用性機能を無効にできます。分離されたマスターと昇格されたマスター間の複製関係が切断され、それぞれ一般DBインスタンスとして動作します。分離後は既存の構成に戻せません。
高可用性DBインスタンスの場合、再起動を伴う作業を実行すると、フェイルオーバーを利用した再起動を行うかどうかを選択でき、その作業は次のとおりです。
フェイルオーバーを利用した再起動を行うと、予備マスターを先に再起動します。その後、フェイルオーバーにより予備マスターをマスターに昇格させ、既存のマスターは予備マスターの役割をすることになります。昇格時に接続のための内部ドメインのA recordはマスターから予備マスターに変更されるので、アプリケーションの変更は必要ありません。昇格されたマスターは、以前のマスターのすべての自動バックアップを継承します。フェイルオーバーの過程でマスターが変更され、バイナリログ(binary log)がすべて削除されるため、既存のバックアップを利用した時点復元はサポートしません。昇格されたマスターで新規にバックアップが行われた時点から時点復元を行うことができます。
[注意] 予備マスターとレプリケーショングループに含まれるリードレプリカのSeconds_Behind_Masterの値が1以上の場合、製遅遅延が発生したものとみなし、手動フェイルオーバーは失敗します。負荷が少ない時間に手動フェイルオーバーを行うことを推奨します。レプリケーション遅延による再起動の失敗は、イベント画面で確認できます。
フェイルオーバーを利用した再起動時、次の項目を追加的に選択して安定性を高めることができます。
フェイルオーバーの過程でバイナリログ(binary log)がすべて削除されるため、フェイルオーバーを利用した再起動が完了した後、すぐに手動バックアップを行うことができます。
予備マスターに変更事項を先に適用した後、その推移を観察したり、正確な時間にフェイルオーバーを実行したい場合、Webコンソールでフェイルオーバーのタイミングを直接制御できます。フェイルオーバー手動制御を選択すると、予備マスターが再起動された後、❶コンソールにフェイルオーバーボタンが表示されます。このボタンをクリックするとフェイルオーバーが実行され、最大5日間実行を待機できます。5日以内にフェイルオーバーを実行しない場合、その作業は自動的にキャンセルされます。
[注意] フェイルオーバーを待機している間は、自動フェイルオーバーは行われません。
複製遅延解消待機オプションを有効にすると、予備マスターとレプリケーショングループに含まれるリードレプリカの複製遅延がなくなるまで待機できます。
複製遅延を解消する間、書き込み負荷を追加的に遮断する選択が可能です。書き込み負荷を遮断すると、フェイルオーバーを実行する直前にマスターが読み取り専用モードに切り替わり、すべての変更クエリが失敗するように設定されます。
一時的な作業による接続中断や大量の負荷が予想される状況で、一時的に高可用性機能を停止できます。高可用性機能が一時停止されると、障害を検出しないため、フェイルオーバーを実行しません。高可用性機能が一時停止した状態で再起動が必要な作業を実行しても一時停止された高可用性機能が再開されません。高可用性機能が一時停止するとデータ複製は正常に行われず、障害が検出されないため、長時間一時停止状態に維持することは推奨しません。
ネットワークの切断、誤ったFEDERATEDエンジンの使用、他のマスターからの複製設定など、さまざまな原因で予備マスター複製が中断されることがあります。複製中断状態の予備マスターは自動フェイルオーバーが実行されません。予備マスターの複製中断を解決するには予備マスターを再構築する必要があります。予備マスターの再構築時には予備マスターのデータベースをすべて削除し、マスターのデータベースを基に再構築します。この過程で再構築に必要なバックアップファイルがマスターデータベースに存在しない場合、マスターでバックアップが行われ、バックアップによる性能低下が発生する可能性があります。
RDS for MariaDBはユーザーに利便性を提供するため、ユーザーアカウントで制限されるいくつかの機能を実行するプロシージャを独自に提供しています。
mariadb> CALL mysql.tcrds_active_process();
mariadb> CALL mysql.tcrds_process_kill(processlist_id );
mariadb> CALL mysql.tcrds_current_lock();
mariadb> CALL mysql.tcrds_repl_changemaster (master_instance_ip, master_instance_port, user_id_for_replication, password_for_replication_user, MASTER_LOG_FILE, MASTER_LOG_POS);
ex) call mysql.tcrds_repl_changemaster('10.162.1.1',10000,'db_repl','password','mysql-bin.000001',4);
[注意]複製用アカウントが複製対象(Master) MySQLに作成されている必要があります。
mariadb> CALL mysql.tcrds_repl_init();
mariadb> CALL mysql.tcrds_repl_slave_stop();
mariadb> CALL mysql.tcrds_repl_slave_start();
MariaDB error code 1062: 'Duplicate entry ? for key ?'
mariadb> CALL mysql.tcrds_repl_skip_repl_error();
例) MariaDB error code 1236 (ER_MASTER_FATAL_ERROR_READING_BINLOG): Got fatal error from master when reading data from binary log
mariadb> CALL mysql.tcrds_repl_next_changemaster();
SET GLOBAL innodb_monitor_reset = '{counter-name|module_name|pattern|all}';
クエリを実行します。mariadb> CALL mysql.tcrds_innodb_monitor_reset('{counter-name|module_name|pattern|all}');
ex) CALL mysql.tcrds_innodb_monitor_reset('dml_reads');
CALL mysql.tcrds_innodb_monitor_reset('module_dml');
SET GLOBAL innodb_monitor_reset_all = '{counter-name|module_name|pattern|all}';
クエリを実行します。mariadb> CALL mysql.tcrds_innodb_monitor_reset_all('{counter-name|module_name|pattern|all}');
SET GLOBAL foreign_key_checks ='ON|OFF';
クエリを実行します。mysql> CALL mysql.tcrds_foreign_key_checks('{0|1|'OFF'|'ON'}');
mysqldump -h{rds_insance_floating_ip} -u{db_id} -p{db_password} --port={db_port} --single-transaction --routines --events --triggers --databases {database_name1, database_name2, ...} > {local_path_and_file_name}
mysqldump -h{rds_insance_floating_ip} -u{db_id} -p{db_password} --port={db_port} --single-transaction --routines --events --triggers --databases {database_name1, database_name2, ...} | mysql -h{external_db_host} -u{external_db_id} -p{external_db_password} --port={external_db_port}
mysqldump -h{external_db_host} -u{external_db_id} -p{external_db_password} --port={external_db_port} --single-transaction --set-gtid-purged=off --routines --events --triggers --databases {database_name1, database_name2, ...} | mysql -h{rds_insance_floating_ip} -u{db_id} -p{db_password} --port={db_port}
ERROR 1227
エラーが発生した場合ERROR 1227
エラーはmysqldumpファイルの保存されたオブジェクト(トリガー、ビュー、関数またはイベント)にDEFINERが定義されている時に発生します。これを解決するためには、mysqldumpファイルでDEFINER
部分を削除してください。ERROR 1418
エラーが発生する場合ERROR 1418
エラーはmysqldumpファイルの関数宣言にNO SQL、READS SQL DATA, DETERMINISTICがなく、バイナリログが有効な状態の時に発生します。log_bin_trust_function_creators
パラメータの値を1
に変更する必要があります。mysqldump -h{rds_master_insance_floating_ip} -u{db_id} -p{db_password} --port={db_port} --single-transaction --master-data=2 --routines --events --triggers --databases {database_name1, database_name2, ...} > {local_path_and_file_name}
mysqldump -h{rds_read_only_slave_insance_floating_ip} -u{db_id} -p{db_password} --port={db_port} --single-transaction --dump-slave=2 --routines --events --triggers --databases {database_name1, database_name2, ...} > {local_path_and_file_name}
...
[mysqld]
...
server-id={server_id}
replicate-ignore-db=rds_maintenance
...
mysql -h{external_db_host} -u{exteranl_db_id} -p{external_db_password} --port={exteranl_db_port} < {local_path_and_file_name}
STOP SLAVE;
RESET SLAVE;
CHANGE MASTER TO master_host = '{rds_master_instance_floating_ip}', master_user='{user_id_for_replication}', master_password='{password_forreplication_user}', master_port ={rds_master_instance_port}, master_log_file ='{MASTER_LOG_FILE}', master_log_pos = {MASTER_LOG_POS};
START SLAVE;
mysqldump -h{master_insance_floating_ip} -u{db_id} -p{db_password} --port={db_port} --single-transaction --master-data=2 --routines --events --triggers --databases {database_name1, database_name2, ...} > {local_path_and_file_name}
mysqldump -h{slave_insance_floating_ip} -u{db_id} -p{db_password} --port={db_port} --single-transaction --dump-slave=2 --routines --events --triggers --databases {database_name1, database_name2, ...} > {local_path_and_file_name}
...
[mysqld]
...
server-id={server_id}
replicate-ignore-db=rds_maintenance
...
mysql -h{rds_master_insance_floating_ip} -u{db_id} -p{db_password} --port={db_port} < {local_path_and_file_name}
mariadb> CREATE USER 'user_id_for_replication'@'{external_db_host}' IDENTIFIED BY '<password_forreplication_user>';
mariadb> GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'user_id_for_replication'@'{external_db_host}';
mariadb> call mysql.tcrds_repl_changemaster ('rds_master_instance_floating_ip',rds_master_instance_port,'user_id_for_replication','password_forreplication_user','MASTER_LOG_FILE',MASTER_LOG_POS );
mariadb> call mysql.tcrds_repl_slave_start;
mariadb> call mysql.tcrds_repl_init();
NHN Cloudは周期的にDBインスタンスのハイパーバイザソフトウェアをアップデートしてセキュリティと安定性を向上させています。 メンテナンス対象ハイパーバイザで起動中のDBインスタンスは、マイグレーションを通してメンテナンスが完了したハイパーバイザに移動する必要があります。
DBインスタンスのマイグレーションはNHN Cloudコンソールで開始できます。 DB構成に応じて特定DBインスタンスを選択してマイグレーションする時、関連するDBインスタンス(例えばSlaveインスタンス)もメンテナンス対象の場合は一緒にマイグレーションを進行します。 下記のガイドに従ってコンソールにあるマイグレーション機能を利用してください。 メンテナンス対象に指定されたDBインスタンスがあるプロジェクトに移動します。
名前の横にマイグレーションボタンがあるDBインスタンスがメンテナンス対象のインスタンスです。
マイグレーションボタンにマウスオーバーすると、メンテナンス日程の詳細を確認できます。
DBに接続しているサービスに影響を与えないように、適切な措置を取ってください。 やむを得ずサービスに影響を与えてしまう時は、NHN Cloudサポートに連絡してくだされば、適切な措置を案内いたします。
DBインスタンスの状態が変更されない場合は「更新」を行ってください。
DBインスタンスのマイグレーション中は何も操作ができません。 DBインスタンスのマイグレーションが正常に完了しなかった場合、自動的に管理者に報告され、NHN Cloudから別途連絡いたします。
Federated Storage Engineを使用する場合、次を考慮する必要があります。