Relay

MySQL之SQL优化实战记录 背景 本次SQL优化是针对javaweb中的表格查询做的。 部分网络架构图 业务简单说明 N个机台将业务数据发送至服务器，服务器程序将数据入库至MySQL数据库。服务器中的javaweb程序将数据展示到网页上供用户查看。 原数据库设计 windows单机主从分离 已分表分库，按年分库，按天分表 每张表大概20w左右的数据 原查询效率 3天数据查询70-80s 目标 3-5s 业务缺陷 无法使用sql分页，只能用java做分页。 问题排查 前台慢 or 后台慢 如果你配置了druid，可在druid页面中直接查看sql执行时间和uri请求时间 在后台代码中用System.currentTimeMillis计算时间差。 结论 ： 后台慢，且查询sql慢 sql有什么问题 sql拼接过长，达到了3000行，有的甚至到8000行，大多都是union all的操作，且有不必要的嵌套查询和查询了不必要的字段 利用explain查看执行计划，where条件中除时间外只有一个字段用到了索引 备注 ： 因优化完了，之前的sql实在找不到了，这里只能YY了。 查询优化 去除不必要的字段 效果没那么明显 去除不必要的嵌套查询 效果没那么明显 分解sql 将union all的操作分解，例如(一个union all的sql也很长) select aa from bb

问题描述 同事反馈 MySQL主从复制主键冲突 ， 导致从库大量relay中继日志 持续增长 导空间不足 查看从库复制状态 master 10.23.234.140 mysql> show master status\G; *************************** 1. row *************************** File: mysql-bin.000489 Position: 903623288 Binlog_Do_DB: Binlog_Ignore_DB: mysql,information_schema,performation_schema,sys Executed_Gtid_Set: 1 row in set (0.02 sec) ERROR: No query specified slave 10.23.234.141 mysql> show slave status\G *************************** 1. row *************************** Slave_IO_State: Waiting for master to send event Master_Host: 10.23.234.140 Master_User: repl Master_Port: 3306 Connect

导读 ： 作者：高鹏（网名八怪），《深入理解MySQL主从原理32讲》系列文的作者。 水平有限有误请谅解。 本文为笔者2年前写一篇说明性文章，发现很多同学都在问这个问题，因此做一次分享。 本文基于5.7.17源码 本文只考虑row格式binlog 主要考虑DML语句，DDL语句比较简单不做考虑 以单sql线程为例（非MTS） 如果要系统的学习主从原理可以参考我的 《深入理解MySQL主从原理 32讲》。 一、延迟的计算方式 其实每次show slave status命令的时候后台会调用函数show_slave_status_send_data进行及时计算，这个延迟并不是保存在哪里的。栈帧如下： #0 show_slave_status_send_data (thd=0x7fffd8000cd0, mi=0x38ce2e0, io_gtid_set_buffer=0x7fffd800eda0 "e859a28b-b66d-11e7-8371-000c291f347d:42-100173", sql_gtid_set_buffer=0x7fffd8011ac0"e859a28b-b66d-11e7-8371-000c291f347d:1-100173") at /MySQL/MySQL-5.7.17/sql/rpl_slave.cc:3602 #1 0x0000000001867749

平台：迅为iMX6开发板 模块：继电器 系统：Android系统 在安卓系统环境下 迅为 iMX6 继电器实验调试步骤。 继电器(Relay)，也称电驿，是一种电子控制器件，通常应用于自动控制电路中，实际上是用较小的电流去控制较大电流的一种“自动开关”。故在电路中起着自动调节、安全保护、 转换电路等作用。 1 硬件连接 本文档测试使用一块开发板，一个继电器模块。使用排线连接开发板和继电器模块。继电 器模块的 U2 端口，连接开发板上的“GPIO”端口。连接后如下图所示。 硬件连接完成之后，就可以进行软件测试了。 2 软件测试 开发板运行 Android 系统之后，将开发版用 OTG 连接到电脑,。在电脑上安装好“360 手机助手”。双击源码的“bin”目录下的“relaytest.apk”，在弹出的对话框中选择“开始发送”。 打开 APP。若弹出个“超级用户请求”对话框，选择“永久记住选择”,点击“允许”， 如下图所示。 程序运行界面如下图所示。 点击“RELAY ON ”按钮打开继电器，可以听到清脆的响声，则表明已经打开。点击 “RELAY OFF”按钮关闭继电器。 继电器开启和关闭的时候，端子输出如下： 当继电器打开，则网络 XispSPIMISO 输出高电平。继电器管脚 2 和 5 导通，端子的管脚 pin-A 输出 5v 电压。 当继电器关闭，则网络 XispSPIMISO

作者：高鹏（八怪） 本节包含分发调用流程请参考链接： https://www.jianshu.com/p/8706d7422d89 一、综述 与单 SQL 线程的回放不同，MTS 包含多个工作线程，原有的 SQL 线程蜕变为协调线程。SQL 协调线程同时还承担了检查点的工作。我们知道并行回放的方式有两种，包含 LOGICAL_CLOCK 和 DATABASE，体现在判定哪些事物能够并行回放的规则不同。实际上源码对应两个不同的类： Mts_submode_logical_clock Mts_submode_database 这里只准备讨论基于 LOGICAL_CLOCK 的并发方式，而不会讨论老的基于 DATABASE 的方式，下面是我设置的参数： slave_parallel_type：LOGICAL_CLOCK slave_parallel_workers ：4 注意 slave_parallel_workers 设置的是工作线程的个数，且不包协调线程，因此如果不想使用 MTS 应该将这个参数设置为 0，然后 ‘stop slave;start slave’ 才能生效。因为工作线程在启动的时候已经初始化完毕了。 因为我们知道在 5.7 中即便不开启 GTID 也包含的匿名的 GTID Event，它携带了 last commit 和 seq number，因此即便关闭 GTID

以下文章来源于万能修实验室，作者公先生 2020年1月除了来源信息如迷之故事会一般的冠状病毒外，MySQL 官方发布了全新的8.0.19版本，而其中最大的亮点莫过于ReplicaSet功能。 I nnoDB R eplicaSet由一个主数据库和多个辅助数据库组成 ， 可以使用ReplicaSet对象和AdminAPI操作，在发生故障时手动故障转移到新的主数据库。 官方的MySQL Router同样也支持ReplicaSet，可自动配置、使用InnoDB ReplicaSet，无需手动配置文件。 InnoDB ReplicaSet 先决条件： 仅支持MySQL 8.0及更高版本 仅支持基于GTID的复制 仅支持基于行的复制（RBR），不支持基于语句的复制（SBR） 不支持复制过滤,比如只复制某个库、表。 一个副本集最多包含一个 primary 主实例，支持一个或多个 secondaries 辅助实例。可以添加的辅助实例数量无限制，但由于会占用路由资源，也不要搞得太多。 ReplicaSet必须由MySQL Shell管理, 如：复制帐户的创建和管理。直接用SQL语句无法操作副本集 通常InnoDB ReplicaSet本身不能提供高可用性。与InnoDB Cluster相比，InnoDB ReplicaSet并不十分完善，使用起来也有不少限制，因此还是建议尽可能部署InnoDB

作者：高鹏 本节包含一个笔记如下： https://www.jianshu.com/p/e920a6d33005 这一节会先描述 MTS 的工作线程执行 Event 的大概流程。然后重点描述一下 MTS 中检查点的概念。在后面的第 25 节我们可以看到，MTS 的异常恢复很多情况下需要依赖这个检查点，从检查点位置开始扫描 relay log 做恢复操作，但是在 GTID AUTO_POSITION MODE 模式且设置了 recovery_relay_log=1 的情况下这种依赖将会弱化。 一、工作线程执行 Event 前面我们已经讨论了协调线程分发 Event 的规则，实际上协调线程只是将 Event 分发到了工作线程的执行队列中。那么工作线程执行 Event 就需要从执行队列中拿出这些 Event，然后进行执行。整个过程可以参考函数 slave_worker_exec_job_group。因为这个流程比较简单，因此就不需要画图了，但是我们需要关注一些点如下： （1）从执行队列中读取 Event。注意这里如果执行队列中没有 Event 那么就进入空闲等待，也就是工作线程处于无事可做的状态，等待状态为 ‘Waiting for an event from Coordinator’。 （2）如果执行到 XID_EVENT 那么说明事务已经结束了那么需要完成内存信息更新操作。可参考