問題タブ [tokudb]

ハード ドライブにはいくらかのスペースが残っていますが、tokuDB ストレージ エンジンを使用したテーブルへの挿入は次のエラーで失敗します。

エラー コード: 1021。ディスクがいっぱいです (); 誰かがいくらかのスペースを解放するのを待っています... (errno: 189 "Disk full")

他のストレージ エンジン (例: innodb ) での挿入は引き続き機能します。

テーブルに 64 個を超えるインデックスを作成する必要がありますが、「指定されたキーが多すぎます。最大 64 個のキーが許可されています」というエラーが発生します。MariaDb/TokuDB でこの制限を 1000 を超えて増やすことができる回避策はありますか? または、この制限が必要な理由はありますか?

(この質問が MySQL について尋ねられた/回答されたのを見たことがあります - 答えは --with-max-indexes=256 を ./configure に渡すか、コンパイル時にヘッダー ファイルの 1 つで MAX_KEY を変更することです。残念ながら、これらは回答は MariaDB では機能しないようです)

Ps。典型的な回答は「これほど多くのインデックスが必要な場合、何か間違ったことをしている」というものなので、なぜこれを行う必要があるのか​​を説明し、それが最善の「回避策」である場合は、設計を変更するためのアドバイスをいただければ幸いです。

私のデータは2つのテーブルに保存されています:

table1には 5 つの列が格納されます: (unique key x_position int, column1 string, column2 float, column3 int, column4 tinyint) - 1 億行にもなる可能性があります

table2は概念的に 4 つの列として表すことができます: (外部キー x_position int、sample_id 文字列、value1 tinyint、value2 float) - 最大 5000 の一意の sample_id 値が存在する可能性があり、各 (x_position, sample_id) ペアに対して異なる value1 が存在するため、行の最大数は 1 億 x 5000 = 5000 億行になります。

私がする必要があるクエリは次のようなものです:

代わりに、列が次のようになるように table2 をピボットする方が効率的であると考えていました 。

次に、(sample_id1_value1、sample_id1_value2、..) 列の小さなサブセットに複合インデックスを作成します。これは、これらの列のどれが一緒にクエリされるかというドメイン固有の詳細に基づいています。このテーブルには 1 億行 x 10,000 列 (列の制限を避けるために複数のテーブルに分割) があり、5,000 億行よりも優れているように見えます。また、クエリで「or」句と「group by」句が不要になり、クエリを次のように書き直すことができます。

残念ながら、「キーが多すぎます」というエラーがこれを妨げています。

私はmariadb 10.0.20を使用して、tokudbエンジンで2つのテーブルを作成しました。

JDBCを使用してtable2からtable1に挿入しようとしていました

私は table2 のような何百ものテーブルと各テーブルに何百万ものレコードを持っています。挿入が正常に完了したかどうかにかかわらず、トランザクションを再起動して失敗するデッドロック状態になることがあります。

上記のエラーメッセージの理由を教えてください

前もって感謝します

何らかの理由で ***_status.tokudb ファイルが欠落している TokuDB テーブルがあります。

TokuDB のクラッシュが原因でファイルが欠落しているのかどうかはまだわかりません。

質問は:

• メイン ファイルとキー ファイルからステータス ファイルを復元または再作成する方法はありますか (これは tokudb_file マップから確認できます)。
• tokuDBステータスファイルが削除された原因をデバッグするにはどうすればよいですか?

これは本当によくあることですか、それとも既知のバグですか? https://github.com/percona/tokudb-engine/wiki/Broken-tables-caused-by-non-transactional-table-operations#unexplained-inconsistency-problems-with-tokudb

TokuDBは優れた圧縮を提供しますが、実際に必要以上に多くのスペースを割り当てることで、多くのスペースを無駄にしていることがわかります。

次のように、サイズを取得するために information_schema を使用しています。

そしてここに結果があります

ご覧size_allocatedのとおり、基本的に 2 倍になります。ディスク上のファイルは size_allocated よりも少し多いため、information_schema を使用したレポートは適切です。

最適化を数回実行してみましたが、それほど役に立たず、時には増加することさえあります。うまくいくと思われる唯一の解決策は、ALTER TABLEtblを実行するengine=tokudbことですが、テーブルを完全に再構築するため、多くの時間がかかります。

未使用のスペースを回復する方法を知っている人はいますか?

(percona mysql サーバーで tokudb 5.6.27-76.0 を実行)

データベースのテーブルを InnoDB から TokuDB に変換しましたが、TokuDB では読み取りが CPU を使いすぎていることに気付きました。どうしてこれなの？

より具体的には、TokuDB テーブルを持つサーバーは、PXC の一部である InnoDB を持つサーバーのスレーブです。スレーブは、PXC ではなく、通常の percona サーバーを使用しました。しかし、スレーブがあまりにも多くの CPU を使用しているようで、その理由がわかりません。

以下は私の my.cnf 設定です:

次のレプリケーション メッセージは、tokudb_cache_size が最初に合計 RAM の 80% に設定されたときに、監視システム xymon によって報告されていました。

------InnoDB と PXC の一部を実行しているマスター サーバーに関する詳細情報-----------

最近、mySQL5.6 から percona サーバー 5.7 へのアップグレードと tokuDB テーブルの使用のテストを開始しました。データベースは、パラメータ化されたクエリに PDO ライブラリを使用する PHP 5.5 アプリケーションを提供しています。

同一のデータを持つ percona を tokudb テーブルにロードし、パフォーマンスを既存のプロダクションと比較すると、すぐにパフォーマンスが大幅に低下していることに気付きました (10 倍遅くなりました)。以下のクエリでは、テーブルに 1,200 万行あると仮定しています

5.7 データベースでこの問題を絞り込むことができたのは、次のようなクエリを実行するときの事実です。

ここで、id は列タイプの整数です。それは私の印象であり、私の調査では、比較される列が数値型の場合、mySQL は '12345' を 12345 に暗黙的に変換する必要があることが確認されているようですが、これは mySQL5.7/Percona では発生していないようです。それはmySQL5.6xで起こっていました

ここでの問題は、この動作では、変数ごとにPDOStatement::bindParam (参照http://php.net/manual/en/pdostatement.bindparam.php ) を使用して型を明示的に設定する必要があることです! これを行うと、明示的な型設定をサポートしていない PDOStatement:execute() に現在パラメーターの配列を渡しているすべての準備済みステートメントがほぼグローバルに書き換えられます。

だから-私の質問はこれです-mySQLで何かが変更されたので、暗黙の変換は5.7で行われませんか、それともPerconaですか、それともtokuDBテーブルですか? これをオンに戻すために設定できる構成パラメーターはありますか?