网创优客建站品牌官网
为成都网站建设公司企业提供高品质网站建设
热线:028-86922220
成都专业网站建设公司

定制建站费用3500元

符合中小企业对网站设计、功能常规化式的企业展示型网站建设

成都品牌网站建设

品牌网站建设费用6000元

本套餐主要针对企业品牌型网站、中高端设计、前端互动体验...

成都商城网站建设

商城网站建设费用8000元

商城网站建设因基本功能的需求不同费用上面也有很大的差别...

成都微信网站建设

手机微信网站建站3000元

手机微信网站开发、微信官网、微信商城网站...

建站知识

当前位置:首页 > 建站知识

实例解读:MySQL并行复制如何解决特定的主从问题?

并行复制存世已多年,但是在实际应用场景中的使用并不常见。这次很幸运,我们刚好遇到一个客户,主的写入工作量非常大,但是从难以跟上,在这种情况下,我建议它使用并行从属线程。

为苍溪等地区用户提供了全套网页设计制作服务,及苍溪网站建设行业解决方案。主营业务为网站设计、成都网站设计、苍溪网站设计,以传统方式定制建设网站,并提供域名空间备案等一条龙服务,秉承以专业、用心的态度为用户提供真诚的服务。我们深信只要达到每一位用户的要求,就会得到认可,从而选择与我们长期合作。这样,我们也可以走得更远!

那么,如何衡量并行复制是否在客户的场景中发挥了作用?对于客户业务能够带来多大的帮助?下面我们就一起来看看吧!

在客户业务场景中, slave_parallel_workers 是0,很明显我应该去增大,但增大的幅度是多少呢?1还是10,这个问题我们会在另一篇文章中解释,先说一下本文的场景中,我们将slave_parallel_workers 调整到了40。

同时,我们对slave还做了以下更改:

slave_parallel_type = LOGICAL_CLOCK;
slave_parallel_workers = 40;
slave_preserve_commit_order = ON;

40个线程听起来是很多,但是这是取决于特定的工作负载的,如果事务是独立的,那么它就可能派上用场。

接下来,我们再来看看哪些线程在工作:

MySQL> SELECT performance_schema.events_transactions_summary_by_thread_by_event_name.THREAD_ID AS THREAD_ID
, performance_schema.events_transactions_summary_by_thread_by_event_name.COUNT_STAR AS COUNT_STAR
FROM performance_schema.events_transactions_summary_by_thread_by_event_name
WHERE performance_schema.events_transactions_summary_by_thread_by_event_name.THREAD_ID IN
(SELECT performance_schema.replication_applier_status_by_worker.THREAD_ID
FROM performance_schema.replication_applier_status_by_worker);
+-----------+------------+
| THREAD_ID | COUNT_STAR |
+-----------+------------+
| 25882 | 442481 |
| 25883 | 433200 |
| 25884 | 426460 |
| 25885 | 419772 |
| 25886 | 413751 |
| 25887 | 407511 |
| 25888 | 401592 |
| 25889 | 395169 |
| 25890 | 388861 |
| 25891 | 380657 |
| 25892 | 371923 |
| 25893 | 362482 |
| 25894 | 351601 |
| 25895 | 339282 |
| 25896 | 325148 |
| 25897 | 310051 |
| 25898 | 292187 |
| 25899 | 272990 |
| 25900 | 252843 |
| 25901 | 232424 |
+-----------+------------+

从上述代码中,我们可以看到哪些线程是在工作,但是这些线程真的加速复制了吗?Slave能在同一时间内写出更多的东西吗?

先来看一下 replication lag:

实例解读:MySQL并行复制如何解决特定的主从问题?

我们可以看大lag很快就降下来了,这是因为线程数增加了吗?还是因为生成多个插件的作业完成了,没有更多的写入了?(复制延迟没有达到0,因为这个Slave故意拖延了一个小时。)

幸运的是,在PMM中我们还有其他图表可以看,例如显示InnoDB Row操作:

实例解读:MySQL并行复制如何解决特定的主从问题?

Slave插入了比之前更多的行,那实际插入了多少行呢?下面我们创建一个新的图表来查看

每小时插入了多少行。在PMM中,我们已经拥有了所有这些信息,只需要使用下面的查询创建一个新的图表:

increase(mysql_global_status_innodb_row_ops_total{instance="$host",operation!="read"}[1h])

结果显示:

实例解读:MySQL并行复制如何解决特定的主从问题?

从图中我们可以看到每小时插入行数大幅增加,从每小时约50Mil到200-400Mil。我们可以得出结论,增加slave_parallel_workers数量确实有帮助。


分享文章:实例解读:MySQL并行复制如何解决特定的主从问题?
当前URL:http://bjjierui.cn/article/iedpij.html

其他资讯