Docker で MySQL を実行していますか?おめでとうございます、ついに解雇されましたね！

コンテナの定義: コンテナは、「動作環境を切り替えたときにソフトウェアが正常に動作することをどのように保証するか」という問題を解決するために設計されています。

現在、コンテナとDockerは依然としてテクノロジー分野で最もホットな言葉です。ステートレス サービスのコンテナ化はすでに一般的なトレンドになっています。同時に、議論されているホットな問題も生じます。データベース MySQL をコンテナ化する必要があるかどうかです。

全員の意見を注意深く分析した結果、同意する人はコンテナの利点の観点から MySQL をコンテナ化する必要があると説明しているだけで、意見を検証するためのビジネス シナリオはほとんどないことがわかりました。一方、反対派は、パフォーマンスやデータセキュリティなど複数の要素からMySQLをコンテナ化する必要はないと説明し、また、いくつかの不適切なビジネスシナリオも挙げています。次に、Docker が MySQL の実行に適していない理由について説明します。

データセキュリティの問題

コンテナ内にデータを保存しないでください。これは Docker コンテナの公式使用ヒントの 1 つでもあります。コンテナはいつでも停止または削除できます。コンテナが rm されると、コンテナ内のデータは失われます。データの損失を防ぐために、ユーザーはデータ ボリューム マウントを使用してデータを保存できます。ただし、コンテナ ボリュームの設計は永続的なストレージを提供するために Union FS イメージ レイヤーに基づいており、データのセキュリティは保証されません。コンテナが突然クラッシュし、データベースが適切にシャットダウンされない場合、データが破損する可能性があります。さらに、コンテナ内のデータ ボリューム グループを共有すると、物理マシンのハードウェアに重大な損傷が発生する可能性があります。

[[261587]]

パフォーマンスの問題

ご存知のとおり、MySQL は IO 要件が高いリレーショナル データベースです。物理マシンで複数のインスタンスを実行すると、IO が蓄積され、IO ボトルネックが発生し、MySQL の読み取りおよび書き込みパフォーマンスが大幅に低下します。

Docker の使用における 10 大困難に関する特別セッションで、ある国営銀行のアーキテクトが次のように述べました。「データベースのパフォーマンスのボトルネックは通常、IO で発生します。Docker の考え方に従うと、最終的には複数の Docker IO 要求がストレージ上に現れます。現在、インターネット上のほとんどのデータベースは共有なしのアーキテクチャに基づいており、これが Docker への移行を検討しない要因となっている可能性があります。」

[[261588]]

実際、この問題を解決するための次のような戦略がいくつかあります。

（１）データベースプログラムとデータの分離

Docker を使用して MySQL を実行する場合は、データベース プログラムとデータを分離し、データを共有ストレージに保存し、プログラムをコンテナーに配置する必要があります。コンテナ内で例外が発生した場合や、MySQL サービスに異常が発生した場合は、新しいコンテナが自動的に起動されます。また、ホストマシンにデータを保存しないことをお勧めします。ホストマシンとコンテナはボリュームグループを共有するため、ホストマシンへのダメージが大きくなります。

（２）軽量データベースや分散データベースの実行

Docker で軽量データベースまたは分散データベースをデプロイする場合、Docker 自体は、コンテナ サービスを再起動するのではなく、サービスを終了して新しいコンテナを自動的に起動することを推奨しています。

（３）アプリケーションの合理的なレイアウト

IO 要件が高いアプリケーションやサービスの場合、データベースを物理マシンまたは KVM に展開する方が適切です。現在、Tencent Cloud の TDSQL と Alibaba の Oceanbase は、Docker ではなく物理マシンに直接デプロイされています。

ステータスの問題

Docker の水平スケーリングは、データベースではなく、ステートレス コンピューティング サービスにのみ使用できます。

Docker の急速な拡大における重要な特徴は、ステートレス性です。データ状態を持つものは、Docker に直接配置するのに適していません。 Docker にデータベースをインストールする場合は、ストレージ サービスを別途提供する必要があります。

現在、Tencent Cloud の TDSQL (金融分散データベース) と Alibaba Cloud の Oceanbase (分散データベース システム) はどちらも、管理が容易な Docker ではなく、物理マシン上で直接実行されています。

[[261589]]

リソースの分離

リソースの分離という点では、Docker は確かに仮想マシン KVM ほど優れていません。 Docker は Cgroup を使用してリソース制限を実装しますが、リソース消費の最大値を制限することしかできず、他のプログラムが独自のリソースを占有するのを分離することはできません。他のアプリケーションが物理マシンのリソースを過度に占有すると、コンテナ内の MySQL の読み取りおよび書き込み効率に影響します。

必要な分離レベルが増えるほど、発生するリソースのオーバーヘッドも大きくなります。専用環境と比較して、水平スケーリングが容易なことが Docker の大きな利点です。ただし、Docker では、水平スケーリングはステートレス コンピューティング サービスにのみ使用でき、データベースには使用できません。

[[261590]]

MySQL はコンテナ内で実行できないのですか?

MySQL は完全に制御不能というわけではありません。

• データ損失の影響を受けにくいビジネス (ユーザーによる製品検索など) はデジタル化でき、データベース シャーディングを使用してインスタンスの数を増やし、スループットを向上させることができます。
• Docker は軽量または分散データベースの実行に適しています。 Docker サービスがクラッシュすると、コンテナ サービスを再起動する代わりに、新しいコンテナが自動的に起動されます。
• データベースは、ミドルウェアとコンテナ化されたシステムを使用して、自動的にスケーリング、災害からの回復、切り替えを行い、複数のノードを備えています。コンテナ化も可能です。

典型的なケース: Tongcheng Travel、JD.com、Alibaba のデータベース コンテナ化はすべて優れたケースであり、自分で確認することができます。