このページでは、Lindorm インスタンスの操作 (スケーリング、構成変更、バージョンアップグレード、再起動など) に関する一般的な質問に回答します。各操作にかかる時間、実行中のワークロードへの影響、および開始前に確認すべき事項について説明します。
概要
以下の表は、主要な運用と保守の操作すべてについて、期間とビジネスへの影響をまとめたものです。メンテナンスウィンドウの計画にご活用ください。
| 操作 | 期間 | 読み取り/書き込みは中断されますか？ | レイテンシーのジッターは発生しますか？ | 接続が切断される可能性がありますか？ |
|---|---|---|---|---|
| ノードのスケールアウト | ノードあたり 10～15 分 (並行) | いいえ | はい | — |
| ストレージのスケールアウト | 数分 | いいえ | — | — |
| コールドストレージの有効化 | ノードあたり 10～15 分 (順次) | いいえ | はい | はい |
| コールドストレージのスケールアウト | 数分 | いいえ | — | — |
| 構成のアップグレード | ノードあたり 10～15 分 (順次) | いいえ | はい | はい |
| ノードのスケールイン | 数式 | いいえ | — | — |
| 構成のダウングレード | ノードあたり 10～15 分 (順次) | いいえ | はい | はい |
| マイナーバージョンアップグレード — LindormDFS | ノードあたり 10～15 分 (順次) | いいえ | — | — |
| マイナーバージョンアップグレード — LindormTable | ノードあたり 10～15 分（逐次） | いいえ | はい | はい |
| インスタンスの再起動 | ノードあたり 10～15 分 (順次) | いいえ | はい | はい |
レイテンシーのジッターや接続の切断が発生する可能性がある操作については、クライアントが自動的に再接続するように構成し、ワークロードが遅延の影響を受けやすい場合は、オフピーク時間に操作をスケジュールしてください。
スケールアウト、構成のアップグレード、およびサービスの有効化
インスタンスのノードのスケールアウトにかかる時間
ノードのスケールアウトは、追加されるすべてのノードで並行して実行されます。各ノードには約 10～15 分かかります。
ノードのスケールアウト中のビジネスへの影響
インスタンスは、スケールアウト中も読み取りと書き込みを継続して処理します。一部のリクエストでは、一時的なレイテンシースパイクが発生する可能性があります。クライアントが自動的に再接続するように構成されていることを確認してください。
インスタンスのストレージ容量のスケールアウトにかかる時間とビジネスへの影響
ストレージのスケールアウトは、ワークロードを中断することなく数分で完了します。ストレージのスケールアウトは、Standard、Performance、または Capacity ストレージを使用するインスタンスでのみ利用可能です。ご利用のインスタンスがローカル SSD または HDD を使用している場合は、ストレージ容量を増やすためにノードを追加してください。
コールドストレージの有効化にかかる時間とビジネスへの影響
コールドストレージの有効化では、各ノードが順次再起動されます。各ノードには約 10～15 分かかるため、4 ノードのインスタンスでは約 60 分かかります。リージョンが多いノードほど時間がかかります。
インスタンスは、プロセス中も読み取りと書き込みを継続して処理しますが、一時的なレイテンシースパイクや短い接続の切断が発生する可能性があります。クライアントが自動的に再接続するように構成されていることを確認してください。
インスタンスのコールドストレージ容量のスケールアウトにかかる時間とビジネスへの影響
コールドストレージのスケールアウトは、ワークロードを中断することなく数分で完了します。
インスタンスの構成のアップグレードにかかる時間とビジネスへの影響
構成のアップグレードは、各ノードに順次適用されます。各ノードには約 10～15 分かかるため、4 ノードのインスタンスでは約 60 分かかります。リージョンが多いノードほど時間がかかります。
インスタンスは、アップグレード中も読み取りと書き込みを継続して処理しますが、一時的なレイテンシースパイクや短い接続の切断が発生する可能性があります。クライアントが自動的に再接続するように構成されていることを確認してください。
スケールインと構成のダウングレード
インスタンスのノードのスケールインにかかる時間
データ移行時間を推定するには、次の数式を使用します。
Migration time = Data to migrate ÷ (Total nodes × 30 MB/s)例: 10 TB の使用済みストレージを持つ 10 ノードのインスタンスで、2 ノードを削除する必要があるとします。データは均等に分散されているため、2 TB のデータを移行する必要があります。
2 TB ÷ (10 nodes × 30 MB/s) = 6,990.5 seconds ≈ 2 hours0.5 時間のクールダウン期間を追加すると、合計で約 2.5 時間になります。
これは推定値です。実際の時間は、ワークロードと記憶媒体によって異なります。
スケールインリクエストを送信する前に、残りのノードに移行されるデータを吸収するのに十分なディスク領域があることを確認してください。スケールイン後にいずれかの記憶媒体が 85% の使用率を超える場合、リクエストを送信できません。
スケールイン後に適用される払い戻しルールについては、Alibaba Cloud International Website の解約ルールをご参照ください。
ノードのスケールイン中のビジネスへの影響
インスタンスは、スケールイン中も中断することなく読み取りと書き込みを継続して処理します。
インスタンスの構成のダウングレードにかかる時間とビジネスへの影響
構成のダウングレードは、各ノードに順次適用され、各ノードが順番に再起動されます。各ノードには約 10～15 分かかるため、4 ノードのインスタンスでは約 60 分かかります。リージョンが多いノードほど時間がかかります。
インスタンスは、ダウングレード中も読み取りと書き込みを継続して処理しますが、一時的なレイテンシースパイクや短い接続の切断が発生する可能性があります。クライアントが自動的に再接続するように構成されていることを確認してください。
構成のダウングレード後に適用される払い戻しルールについては、Alibaba Cloud International Website の解約ルールをご参照ください。
マイナーバージョンアップグレードとインスタンスの再起動
インスタンスのマイナーバージョンアップグレードにかかる時間
各ノードには約 10～15 分かかります。アップグレードは順次適用されるため、4 ノードのインスタンスでは、LindormDFS と LindormTable の両方で約 60 分かかります。
アップグレードするマイナーバージョンを選択できますか？
いいえ。マイナーバージョンは常に、最新の安定した前方互換性のあるバージョンにアップグレードされます。ターゲットバージョンを指定することはできません。
マイナーバージョンアップグレード中のビジネスへの影響
LindormDFS: 実行中のワークロードは基本的に影響を受けません。
LindormTable: インスタンスは読み取りと書き込みを継続して処理しますが、一時的なレイテンシースパイクや短い接続の切断が発生する可能性があります。クライアントが自動的に再接続するように構成されていることを確認してください。
インスタンスの再起動にかかる時間とビジネスへの影響
ノードは順次再起動されます。各ノードには約 10～15 分かかるため、4 ノードのインスタンスでは約 60 分かかります。リージョンが多いノードほど時間がかかります。
インスタンスは、再起動中も読み取りと書き込みを継続して処理しますが、一時的なレイテンシースパイクや短い接続の切断が発生する可能性があります。クライアントが自動的に再接続するように構成されていることを確認してください。
ストレージ容量
ストレージ使用量の理解
ストレージ使用量は、ストレージタイプによって異なる方法でレポートされます。
クラウドストレージ (Performance、Standard、および Capacity): 使用量は 2 つの部分で構成されます。たとえば、LindormTable のみが有効になっている場合、コンソールには次のように表示されます：
ラベル 説明 ① 単一レプリカによって使用されるスペース。レプリカ数は考慮されません。 ② エンジン以外のコンポーネントによって使用されるスペース：ゴミ箱データ、ブロックメタデータ、書き込み中のブロックの事前割り当て済みスペース、システムファイル、および分散システム用の予約済みスペース。これは通常、総使用量のごく一部です。 
非クラウドストレージ (ローカル SSD または HDD): レプリカ数が考慮されます。たとえば、3 つのレプリカがある場合、100 MB のデータを書き込むと 300 MB のストレージ容量が消費されます。
