MySQL复制简单主/从复制

2023年6月18日 161次阅读

我有简单的主/从配置.我的两个生产箱都有8GB的RAM.

我只使用Master for Writes和slave for Reads.但是在周末我运行了一项工作,即在master上插入数据,应该复制到slave.由于我的奴隶在主人身后徘徊了将近15-16小时,这给我的报告造成了很大的麻烦,因为我从奴隶和奴隶那里读到它没有更新的信息.

关于这一点,我有几个问题：

>有没有合理的理由为什么要使用slave来读取而不是master.(我的主人在5分钟后写了.)并且有些作业是从slave读取的时间表.
>我有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      |         |

最佳答案 我们遇到了类似的情况,但是我们的奴隶有时落后于船长3到4天,其他人则完全是最新的.

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

然后扩展这个以决定在我们有多个(某种软件负载均衡器！)时从哪个从站触发查询.

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

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

希望这可以帮助.

戴夫

点赞