4

我有简单的主/从配置。我的两个生产机器上都有 8GB 的​​ RAM。我使用 Master 只写，slave 只读。但是在周末我做了一项工作，就是在 master 上插入数据，这些数据应该被复制到 slave。由于我的奴隶落后于主人将近 15-16 个小时，这给我的报告造成了很大的麻烦，因为我是从奴隶那里阅读的，而奴隶没有更新信息。

关于这一点，我有几个疑问：

  1. 是否有任何合理的理由应该使用从属设备而不是主设备进行读取。（我的主设备在 5 分钟后写入。）并且一些作业是从从设备读取的计划。

  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 天，而有时完全是最新的。

我们为解决这个问题所做的是在生成的每个页面（或预定作业的脚本）顶部测试从属状态，如果“主后的秒数”大于我们决定的任意数量，我们会为此触发所有查询页面/工作在主人。如果 master 后面的秒数在我们允许的时间限制内（通常为零），那么我们就知道在 slave 上触发查询是安全的。

然后将其扩展以决定当我们有多个从属设备时触发查询（有点像软件负载平衡器！）。

最终，我们重新设计了架构和插入查询，以确保从属延迟最终成为一个非常小的问题......

您可以做的一件事是尝试将您的插入分块成较小的批次，这样单个插入不会花费太长时间，从而允许从属设备在主设备忙于下一个插入时开始该插入。

希望这可以帮助。

戴夫

于 2011-05-19T07:44:33.863 回答