著者の詳細については、ここをクリックしてください マット・ヨンコヴィット.

データベースは私たちのアプリケーションで重要な役割を果たしています。結局のところ、今日では、使用するデータが少ないサービスについて語る人は誰もいません。 ただし、アプリケーションと同様に、データベースには継続的な管理と定期的な更新が必要です。 ある時点で、使用するデータベース バージョンはサポート終了 (EOL) に達します。 これは珍しいことではありません。たとえば、MySQL バージョン 5.6 は 2021 年 3.6 月に EOL になり、MongoDB バージョン 2021 は XNUMX 年 XNUMX 月に EOL になりました。 オープンソース いずれか – Oracle 18c は、30 年 2021 月 XNUMX 日にエラー修正とセキュリティ パッチの適用が終了し、延長サポート オプションは利用できません。 これがデータベースのバージョンで発生した場合は、計画を立てておく必要があります。

データベースのバージョンが EOL に達した場合、それ以上の機能やセキュリティの更新は行われず、ユーザーは新しいバージョンに移行することが推奨されます。 移動は大規模なプロジェクトになる可能性があります。特に、複数のバージョンで更新が遅れている場合はなおさらです。 では、どうすればリスクを軽減し、データ処理のアプローチを改善し、サービスを通常どおり継続できるようにすることができるでしょうか?

あなたの状況はどうですか？

EOL に関しては、そもそもなぜこの時点に達したのかを認識することから始めるべきです。 これは、動作するためにアプリケーションを更新する必要がないためですか? アップグレードは優先リストから外れましたか? データベースから移動できない特定の理由はありますか?

もしあなた することはできません これは通常、アプリケーションが意図したとおりに動作し続けるために何か特別なものが必要なためです。 多くの場合、これは、コンポーネントが特定のデータベース バージョンのみをサポートしているか、コンポーネント自体が更新されていないことが原因です。 これまで、移行は不必要なリスクと見なされてきたかもしれませんが、EOL が近づくと、選択の余地がなくなる可能性があります。

アプリケーションが重要でない場合、そのままにしておくことを優先して、更新を元に戻すのは簡単です。 「壊れていないものは直すな」は、IT の共通のモットーです。 ただし、データベースの EOL 日付を無視するわけにはいきません。

次はどうする？

このような状況に陥った場合は、選択肢を検討し、次に何をすべきかを検討することが重要です。

最初のオプションは、逆説的に言えば、何もしないことです。 問題を無視してはならないと言った後、これは奇妙な提案のように聞こえるかもしれませんが、これら XNUMX つのことは同じではありません。 十分な情報に基づいて既存のデータベース インスタンスを使用するという選択を行うことは、軽率に現状を維持することとは異なるシナリオです。 このアプローチは、データの機密性が低く、セキュリティのために他の制御を実装できる重要でないアプリケーションに最適です。

このシナリオでは、データベース インスタンスの拡張サポート オプションを検討する価値があります。 これにより、EOL の日付が過ぎた後に時間の経過とともに発生する可能性のあるギャップの一部が埋められ、障害が発見された場合にセキュリティの問題を軽減するために必要な手順が記載されたロードマップが提供されます。

5.6 番目のオプションは、移行を実行することです。 これには、EOL データベース エディションから、現在および将来サポートされるエディションへの移行が含まれます。 アプリケーションの互換性に関する懸念とともに、どのくらい前に計画したいかによって、これはポイント アップグレードまたは最新バージョンへの移行になる可能性があります。 たとえば、MySQL v5.7 を扱っている企業には、v8.0 または v5.7 に移行するオプションがあります。 2023 への移行は小規模な変更ですが、このバージョンは 8.0 年 XNUMX 月に EOL に移行します。アプリケーションとデータベースを使用し続ける予定の期間と、移行の作業量によっては、vXNUMX への移行が必要になる場合があります。長期的には低コスト。

このシナリオでは、互換性テストを実行する必要があります。 これにより、アプリケーションが新しいデータベース バージョンでどの程度うまく機能するかが示され、潜在的な問題を特定できるようになります。 問題が発生した場合に備えて、EOL 日の前に徹底的なテストを実行するための十分な時間を確保する必要があります。 締切日の直前にこれを行うと、ストレスが発生する可能性があります. このテストと並行して、既存のシステムで以前のバージョンのデータベースを復元する必要がある場合に備えて、いくつかのバックアップも実行する必要があります。

XNUMX 番目の選択肢は最も急進的です。物事を壊してやり直すことです。 これには、データベースの更新を確認するだけでなく、そもそも適切なデータベースを使用しているかどうかを考慮することも含まれます。 このシナリオは、ダウンタイムが収益の損失につながり、リスクを回避するために更新が延期されているミッション クリティカルなアプリケーションに最適です。

このようなプロジェクトは、変更が生産と収益に対する重大なリスクと見なされる環境でより一般的です。 例としては、アプリケーションが XNUMX 時間体制で利用可能である必要があり、マージンが厳しいサプライ チェーン、製造、公益事業部門が含まれます。 これらの重要なアプリケーションは稼働時間が長くなる可能性があるため、更新のためにオフにすることは危険です。 これらのアップグレードは、それ以上延期できなくなるまで積み重なっていきます。

この状況では、EOL ステータスは、何か問題が発生した場合に他の組織が責任を負わないことを意味します。 問題の影響とその後のクリーンアップの費用は、綿密に計画された移行の費用よりもはるかに大きくなります。 このような場合、強力な費用便益分析に取り組み、これを時間の経過とともにビジネスの利害関係者にとって有益な変化として位置付ける必要があります。 このような状況では、EOL は前向きな力として作用する可能性があり、用心深い企業は長期的で将来を見据えた建設的な変更を行う必要があります。

前方の道路

EOL の状況は、IT プロフェッショナルにとっては避けられない事実であり、時間の経過とともにすべての資産に影響を与えます。 現在の状況がどうであれ、これらの状況に備えて事前に計画することが重要です。

どのような EOL アプローチを採用する場合でも、データの安全性とセキュリティを維持し、アプリケーションが引き続き機能し、ユーザーが影響を受けないようにするために実施できる手順があります。 移行を機能させることから、補完的な制御と追加のセキュリティ対策まで、実装は引き続き適切に機能し、必要な結果を提供する必要があります。 事前に検討し、適切なデータベース展開のアドバイスを得ることで、ビジネスへのリスクを軽減、さらには排除することができます。

コインスマート。 BesteBitcoin-ヨーロッパのBörse
ソース: https://www.dataversity.net/dealing-with-database-end-of-life-issues-what-approach-should-you-take/