私はMySQLを使用していますが、多くの人が痛感しているように、InnoDBエンジンは大きくて縮小できないibdata1ファイルを作成しています。innodb_file_per_table を有効にすると問題は解決しますが、解決しません。
MariaDBに移行して、 XtraDBエンジンを使用することを考えていました。これが InnoDB の改良版であることは知っていましたが、それでもこの重要なフローが実行されるかどうか疑問に思っていました。どこにも言及されていないので、これは MariaDB の問題ではないと推測していますが、確認したいと思います。
誰かがそれについて何か明確な情報を持っていますか? 前もって感謝します。
もちろん、 を使用することは標準的な推奨構成であり、当然ながら、大規模なシステム テーブルスペース ファイルを生成する前innodb_file_per_tableに有効にしておく場合にのみ最大のメリットが得られます。ibdata1
これらすべてを正しく行ったとしても、それでも大幅に成長している場合は、それを成長させるために何かをしているということです。
https://www.percona.com/blog/2013/08/20/why-is-the-ibdata1-file-continuously-growing-in-mysql/を参照してください。
Redo ログ (!)、データ ディクショナリ、およびキッチン シンクはすべてまだそこに保存されているため、MySQL (InnoDB) がディスク スペースをますます多く割り当てて、それを忘れて、さらに多くを求めているわけではありません。 . ワークロードがこの成長を大きく左右します。
XtraDBは、ディスク データ構造の観点からは InnoDB です。MySQL Server を停止し、MariaDB または Percona Server のバイナリを抽出して起動します。XtraDB は、ibdata1 とログ ファイルと .ibd ファイルをボスのようにそのまま使用します。おそらく逆の場合もありますが、誰も試したことはありません。(冗談です。しかし、真面目な話、数十台の MySQL 風のサーバーのネットワークで、マシンを MariaDB または Percona サーバーに移行したことがなく、後で「うわー、Oracle のバージョンの MySQL に戻せたらいいのに」と思いました。既存の ibdata1 および .ibd ファイルを使用する XtraDB に関する部分は冗談ではありません, それはすべて真実です. 私は Solaris 上の MySQL から生のバイナリ データ ファイルを取得し、それらを Linux マシンにコピーし、それらを使用して MariaDB を起動しました. - 問題なし。）
同じワークロードで提示すると、同様の成長が期待できますが、必ずしも同じ成長ではありません。しかし、XtraDBは、 InnoDB と同じファイルで同じことを達成する方法において、InnoDB とは異なります。多くの点でよりスマートで高速であり、限られた範囲でその成長を制限するように構成できますが、同じ作業を行うには同じスペースが必要になるため、ディスクスペースの制約に対して極端な魔法は機能しません. 基本的に、ディスク内に存在するという意味では、依然として InnoDB です。