EOFS とは？

EOFS (フルサポート終了) は、Alibaba Cloud 製品ライフサイクルの一段階です。MongoDB 3.4 は EOFS 段階に入っており、これは以下のことを意味します。

インスタンスが影響を受けるかどうかの確認方法

1. MongoDB コンソールにログインします。

2. インスタンスリストで、対象インスタンスの [データベースバージョン] 列を確認します。

3. バージョンが 3.4 と表示されている場合、そのインスタンスは EOFS の影響を受けるため、できるだけ早くアップグレードする必要があります。

EOFS 後の具体的な制限事項

アップグレードパスのクイックリファレンス表

EOFS の後は、従量課金に切り替えることはできません。期限切れ後、インスタンスは 15 日間ロックされ、アクセスできなくなります。詳細については、「このガイドのセクション 6」をご参照ください。

3.2 なぜスタンドアロンインスタンスは直接スペックアップできないのですか？

直接スペックアップを試行する: 20% はあくまで推奨値であり、厳密なしきい値ではありません。空き領域が推奨値よりわずかに少なくても、スペックアップに成功する可能性があります。空き領域不足が原因でスペックアップに失敗した場合でも、システムはインスタンスに影響を及ぼすことなく自動的にロールバックします。

3.3 ローカルディスク 4.2 はアップグレード可能な最上位バージョン

DTS 移行: より大きなディスク領域を持つ新しい上位バージョンのインスタンスを購入し、DTS を使用してデータを移行し、移行後に旧インスタンスをリリースします。この方法では、ディスク領域による制限を受けません。

• 3.4 から 4.0 および 4.2 にアップグレードする際の互換性の変更点は、以下のとおりです。

• 4.0 へのアップグレード (3.6 経由):

3.4 から 4.2 へ直接アップグレードできますか (4.0 をスキップ)？

• 変更

• 説明

アップグレードによるサービス中断時間はどのくらいですか？

• レプリカセットとシャードクラスター：アップグレードにより 1〜2 回のプライマリ/セカンダリのフェールオーバーがトリガーされ、それぞれ約 30 秒の短時間の切断が発生します。

  説明

  snapshot クエリオプション

  サポートが終了しました

  配列のソート

• $sort 集約ステージのメモリ制限は 100 MB です。

アップグレードによってデータは失われますか？

更新操作

アップグレード後、アカウントの認証情報は変更されますか？

複数のフィールドを同時に更新する場合、新しいフィールドは辞書順で追加されます

アップグレード後、接続文字列は変更されますか？

• reIndex

• インデックスの再構築が完了するまで、グローバルな書き込みロックを追加します

アップグレード後にロールバックできますか？

サポートされなくなりました (4.2 で正式に削除されました)

アップグレード前にディスク領域を確認する必要がありますか？

変更

1. 説明

2. グループ コマンド

3. 削除されました (バージョン 3.4 以降は非推奨となり、バージョン 4.2 で正式に削除されました)。代わりに db.collection.aggregate() または mapReduce() を使用してください。

どのような互換性リスクがありますか？

3.4 から 4.0 および 4.2 にアップグレードする際に導入される互換性の変更は以下の通りです。

削除 (4.0 以降はサポート対象外、4.2 で正式に削除)

アーキテクチャ

4.0 または 4.2

コンソールからの直接アップグレード (レプリカセット/シャードクラスター)

アップグレード後の検証

アップグレードが完了したら、以下の検証を実行してください。

1. スペックアッププロセスでは、それぞれ約 30 秒の短い切断が 2～3 回発生します。アプリケーションに再接続メカニズムが備わっていることを確認してください。

2. スペックアップの完了後、インスタンスステータスは「実行中」に戻ります。

3. スペックアップタスクが長時間「スペックアップ中」と表示されている場合、スイッチオーバー時間を [即時切り替え] に変更することで、完了を早めることができます。

4. 対象: スタンドアロン 3.4 インスタンスのユーザー。

5. バージョン 4.0 または 4.2 の新しい MongoDB インスタンスを購入します。

インスタンスの有効期限が迫っているが、時間内にアップグレードできない場合

新しいインスタンスのストレージ容量は、元のインスタンスの使用済みストレージ容量以上である必要があります。

• MongoDB 4.0 ではスタンドアロンインスタンスを購入できず、レプリカセットインスタンスを購入する必要があります。MongoDB 4.2 はスタンドアロンインスタンスに対応しています。

• DTS コンソールに移動します。

• データ移行タスクを作成します。ソースデータベースには元の 3.4 インスタンスを、ターゲットデータベースには新しい高バージョンインスタンスを選択します。

移行タイプを選択:

インスタンスが有効期限切れでロックされている場合

完全移行: すべてのデータを移行します。ダウンタイムが許容されるシナリオに適しています。完全移行は無料です。

1. 完全 + 増分移行：まず完全移行を実行し、次に増分データを継続的に同期します。ダウンタイムなしのスイッチオーバーが求められるシナリオに適しています。

   警告

   • 増分移行を選択した場合は、ソースインスタンスで oplog が有効になっていることを確認してください。

   • スタンドアロン 3.4 インスタンスでは、デフォルトで oplog は有効になっていません。

2. oplog を有効化するには、チケットを送信してテクニカルサポートにご連絡ください。oplog を有効化すると、インスタンスの再起動が必要です。この操作はオフピーク時間中に実行してください。

3. レプリカセットおよびシャードクラスターインスタンスでは、デフォルトで oplog が有効になっています。追加の操作は不要です。

Q1：インスタンスの有効期限が迫っており、更新できません。どうすればよいですか？

DTS 移行では、デフォルトでシステムデータベース (admin, local, config) は移行されません。ビジネスデータベースがすべて揃っていることを確認してください。

Q2: コンソールに「データベースバージョンのアップグレード」オプションが表示されない

完全移行が完了した後 (または増分同期のレイテンシーが 0 に近づいたとき)、業務の書き込みを一時停止します。

Q3: 自動更新が動作しなくなったのはなぜですか？

増分同期が完了するまで待ちます。

• アプリケーションコード内のデータベース接続文字列を、新しいインスタンスを指すように更新します。

• 業務の書き込みを再開します。

Q4: 4.0 と 4.2 のどちらにアップグレードすべきですか？

業務が正常に稼働していることを確認した後、古いインスタンスをリリースします。

• 新旧のインスタンスの接続文字列は異なります。新しいインスタンスの接続文字列のフォーマットは、古いインスタンスと異なる場合があります (ドメインサフィックスが異なる場合があります)。すべての接続設定を必ず更新してください。

• アップグレードが完了したら、以下の検証を実行してください。

• バージョン確認：コンソールで、データベースのバージョンが目的のバージョンに変更されたことを確認します。

Q5: アップグレード後、Java コードを修正する必要がありますか？

接続テスト: クライアントを使用してインスタンスに接続し、接続が正常であることを確認します。

Q6: 200 GB のデータを移行するのに、どのくらいの時間がかかりますか？

データの整合性: キービジネスデータが完全であるかどうかを確認します。

Q7: アップグレードプロセスをキャンセルできますか？

アプリケーションの機能: コアビジネス機能をテストし、正常に動作することを確認します。

Q8: スペックアップ後、レプリカセットコンソールにノードが 2 つしか表示されません

パフォーマンスモニタリング: スペックアップ後にパフォーマンスメトリクスを監視し、正常であることを確認します。

スタンドアロンインスタンスは、リリース後にゴミ箱から解凍できません。お使いのインスタンスがスタンドアロンアーキテクチャを使用している場合、ロック期間中 (有効期限が切れてから 1 日目から 15 日目まで) にすぐにチケットを送信してください。コンピューティングリソースがリリースされるまで待たないでください。詳細については、「ゴミ箱の注意事項」をご参照ください。

Q9: インスタンスの有効期限が切れた後、データは保持されますか？

A: すぐにチケットを起票して、状況を説明してください。お使いのインスタンスがレプリカセットまたはシャードクラスターの場合、コンソールから直接 4.0 または 4.2 にアップグレードすることもできます。アップグレード後は、通常どおり更新できます。

Q10: 3.4 から 4.0 への互換性の問題はありますか？

A: 最も考えられる原因は、インスタンスがスタンドアロンアーキテクチャであることです。スタンドアロンの 3.4 インスタンスは、コンソールからの直接スペックアップをサポートしておらず、新しいインスタンスへの DTS 移行が必要です。操作手順については、セクション 5.2 をご参照ください。インスタンスがスタンドアロンではないことを確認してもスペックアップオプションが表示されない場合は、コンソールのスクリーンショットを添付してチケットを送信してください。

Q11: EOFS 後に、従量課金に切り替えることはできますか？

A: 2026年6月30日以降、MongoDB 3.4 は更新サービスのサポートを終了するため、自動更新が停止します。EOFS 日の前に、システムから SMS およびサイト内メッセージで通知が送信されます。更新を再開するには、データベースのメジャーバージョンをアップグレードする必要があります。

1. A：

2. お使いのコードで group コマンドを使用している場合は、まず 4.0 へのアップグレードを推奨します (4.0 でも group は利用可能ですが、非推奨です)。リファクタリングが完了したら、4.2 にアップグレードしてください。

Q12: 運用担当者なしでスペックアップを完了するにはどうすればよいですか？

group コマンドを使用しない場合は、直接 4.2 にスペックアップできます。バージョン 4.2 ではコンソールのディスク領域解放 (compact) がサポートされていますが、4.0 ではサポートされていません。

Q13: "InvalidSaleComponentFault" エラーでアップグレードに失敗する

A: 3.4 から 4.0/4.2 へのアップグレードでは、通常 Java コードの変更は必要ありませんが、次の点をご確認ください。