MySQLに対する最も重要な議論は？

最近の一連の記事（「PostgreSQLエバンジェリストのメモ：MySQLを正しく批判する」 1、2、3 ）が生計を立てています。



私のチームは、MySQLがシステムの主要コンポーネントの1つである、300以上のオブジェクトを持つヒステリックに形成されたシステムを継承しました。 一部のサイトではレプリケーションも使用しています。 サードパーティ開発者のMySQLを使用するソフトウェア。



ほとんどのオブジェクトは、「合理的な人」（山、草原）から離れた地域にあります。 一部のオブジェクトは、最寄りの村から200 km以内に位置しています。 これらの施設での停電はごく普通であり、定期的です。 UPSは非常に役立ちますが、長時間の停電から救うことができない場合があります。 そしてほとんどの場合、一連の停電からです。 つまり、UPSはまだ充電されておらず、機器はすでに稼働しており、データベースにデータを書き込みます。ここでEPは消えて表示され、再び消えます。 システムが落ちています。

MySQLをバージョン5.6.23にアップグレードする前に、1か月間で2つまたは3つのデータベースを手動で復元する必要がありました。 今、あなたはあまり頻繁に復元する必要はありませんが、それでもまだです。 8月以降、復元されたデータベースは2つだけです。



kaamosの記事の1つの後、私たちは5.6.26のテストを開始し、テストではこのバージョンがさらに粘り強いことが示されました。 ただし、サイトの状態を完全にシミュレートすることはできません（約20種類のサイト）。 データベースモデルは同じですが、これらすべてのタイプの負荷プロファイルは異なります。



したがって、問題の重要な条件：

外部キーとON DELETE CASCADE ON UPDATE CASCADEを持つテーブルがあり、上記を参照するいくつかのテーブルでは、トリガーが設定されます。



おそらく、これはMySQLの貧弱なデータモデル設計です。 なんで？ 今日、私は次の声明に出くわしました。



InnoDBエンジンは完全にACIDに準拠していますが、InnoDB、外部キーとカスケードアクションおよびトリガーの組み合わせを使用すると、一貫性の標準定義に失敗します。 これは、MySQLのSQLレイヤーで実装されているトリガーと、InnoDBストレージエンジンレベルで実装されている外部キーの結果です。



このステートメントが真の場合、ACIDからの文字「C」は、この場合、まったく保証されません。



そして、次の形式のエラーメッセージに驚かないでください。

[エラー]テーブル./database/tableにはInnoDBデータディクショナリには主キーがありませんが、MySQLには主キーがあります！



また、レプリケーションの一貫性に100％依存するべきではないようです。



おそらくこの問題は5.7で解決され、ディストリビューションのパッケージデータベースに表示されるとすぐに、システムの更新を開始し、問題を喜んで忘れます。



しかし、MySQLのマルチレベルアーキテクチャ自体には、さらに多くの驚きがありますか？