4

単純なマスター/スレーブ構成があります。両方のプロダクション ボックスに 8GB の RAM を搭載しています。書き込み専用のマスターと読み取り専用のスレーブを使用していました。しかし、週末に、スレーブに複製する必要があるデータをマスターに挿入するという1つのジョブを実行しました。そのため、スレーブがマスターの背後で約 15 ～ 16 時間ラングし、レポートをスレーブから読み取っていて、スレーブの情報が更新されていなかったため、レポートに大きな問題が発生しました。

これに関して、私はいくつかの質問があります：

  1. マスターではなく読み取りにスレーブを使用する正当な理由はありますか?

  2. 私は100GBのテーブルを持っており、毎日同じテーブルに何百万ものレコードを挿入しています。すべての選択と挿入は、このテーブルで行われます。このテーブルを最適化するために、このテーブルから複数のテーブルに年ごとにデータを分離する方法を選択しました。このテーブルを最適化して実行を高速化するために取得できる他の方法はありますか。

不明な点がありましたらお知らせください。

以下はテーブルのデザインです。

+----------------+------------------+------+-----+---------------------+----------------+
| Field          | Type             | Null | Key | Default             | Extra          |
+----------------+------------------+------+-----+---------------------+----------------+
| test_id        | int(11) unsigned | NO   | PRI | NULL                | auto_increment |
| prime_id       | int(11) unsigned | NO   | MUL | 0                   |                |
| prime2_id      | int(11) unsigned | NO   | MUL | 0                   |                |
| timestamp      | datetime         | NO   | MUL | 0000-00-00 00:00:00 |                |
| test_time      | int(11)          | NO   |     | 0                   |                |
| status         | int(11)          | NO   |     | 0                   |                |
| component      | int(11) unsigned | NO   |     | 0                   |                |
| c_component    | int(11) unsigned | NO   |     | 0                   |                |
| C2_component   | int(11) unsigned | NO   |     | 0                   |                |
| C3_component   | int(11) unsigned | NO   |     | 0                   |                |
| rt_component   | int(11) unsigned | NO   |     | 0                   |                |
| code           | int(11) unsigned | NO   |     | 0                   |                |
| ip             | int(11) unsigned | YES  |     | 0                   |                |
| step_id        | int(11) unsigned | YES  |     | NULL                |                |
+----------------+------------------+------+-----+---------------------+----------------+
This is the index information of the table:

| Table | Non_unique | Key_name              | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment |
+-------+------------+-----------------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+
| tests |          0 | PRIMARY               |            1 | test_id     | A         |   629448388 |     NULL | NULL   |      | BTREE      |         |
| tests |          1 | ixf_prime_id          |            1 | prime_id    | A         |          14 |     NULL | NULL   |      | BTREE      |         |
| tests |          1 | ixf_prime2_id         |            1 | prime2_id   | A         |          14 |     NULL | NULL   |      | BTREE      |         |
| tests |          1 | ix_timestamp          |            1 | timestamp   | A         |   157362097 |     NULL | NULL   |      | BTREE      |         |
| tests |          1 | ix_prime_id_timestamp |            1 | prime_id    | A         |          14 |     NULL | NULL   |      | BTREE      |         |
| tests |          1 | ix_prime_id_timestamp |            2 | timestamp   | A         |   629448388 |     NULL | NULL   |      | BTREE      |         |
4

1 に答える 1

2

これと同様の状況がありましたが、スレーブがマスターより 3 ～ 4 日遅れることもあれば、完全に最新の状態になることもありました。

これに対処するために行ったのは、生成された各ページ (またはスケジュールされたジョブのスクリプト) の上部でスレーブのステータスをテストすることでした。「マスターからの秒数」が、私たちが決定した任意の量よりも大きい場合は、そのためのすべてのクエリを起動しました。マスターのページ/ジョブ。マスターからの秒数が許容時間内 (多くの場合ゼロ) 内にある場合、スレーブでクエリを発行しても安全であることがわかりました。

次に、これを拡張して、複数ある場合にどのスレーブでクエリを実行するかを決定しました (一種のソフトウェア ロード バランサーです!)。

最終的に、アーキテクチャと挿入クエリを再設計して、スレーブの遅延が非常に小さな問題になることを確実にしました...

できることの 1 つは、挿入を小さなバッチに分割して、単一の挿入に時間がかかりすぎないようにすることです。これにより、マスターが次の挿入でビジーな間にスレーブがその挿入を開始できるようになります。

お役に立てれば。

デイブ

于 2011-05-19T07:44:33.863 に答える