MySQL 复制 简单主/从复制

Question

我有简单的主/从配置。我的两个生产机器上都有 8GB RAM。 我使用Master仅用于写入，而Slave仅用于读取。但周末我运行了一项工作，即在主服务器上插入应复制到从服务器的数据。由于这个原因，我的奴隶落后于主人近 15-16 个小时，这给我的报告带来了很大的麻烦，因为我从奴隶那里读取它，而奴隶没有更新的信息。

对此我有几个疑问：

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

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      |         |

Answer 1

我们也遇到过类似的情况，但我们的奴隶有时落后主人三四天，而有时则完全是最新的。

我们为解决这个问题所做的就是测试生成的每个页面顶部的从站状态（或计划作业的脚本），如果“落后于主站的秒数”大于我们决定的任意数量，我们将触发所有查询主人的页面/工作。如果主服务器落后的秒数在我们允许的时间限制内（通常为零），那么我们就知道可以安全地向从服务器发出查询。

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

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

您可以做的一件事就是尝试将插入分成较小的批次，这样单个插入就不会占用太长，允许从设备开始插入，而主设备正忙于下一个插入。

希望这有帮助。

戴夫