Relay

首先要明白为什么要用 mysql 的主从复制： 1–在从服务器可以执行查询工作 (即我们常说的读功能)，降低主服务器压力；（主库写，从库读，降压） 2–在从主服务器进行备份，避免备份期间影响主服务器服务；（确保数据安全） 3–当主服务器出现问题时，可以切换到从服务器。（提升性能） 来说一下主从复制的实现原理 mysql 复制过程分为三步（如上图所示）： 1.mster 将改变记录到二进制日志 (binary log) 当中 这些记录过程叫做二进制日志事件 binary log events; 2.slave 将 master 的 binary log events 拷贝到它的中继日志 (relay log) 当中； 3.slave 重做中继日志中的事件 将改变应用到自己的数据库当中 mysql 复制是异步的且串行化的 3.slave 重做中继日志中的事件 将改变应用到自己的数据库当中 mysql 复制是异步的且串行化的 复制的最大问题： 从主机复制数据达到从机可能会有延时！ 都说 master 主机和 slave 从机的 mysql 版本号要一致 我就没一致 master 主机上是 5.6 slave 从机上是 5.7 一样搞 拿过来一台服务器你不得先找 mysql 吗？mysql 在哪里 配置文件在哪里？ 执行命令： which mysql /usr/bin/mysql -

特征如下： CPU占用一直比较高，初步分析是挖矿程序： 系统的crontab –l显示调度列表如下： 20 * * * * /root/.aliyun.sh >/dev/null 2>&1 查看脚本内容： #!/bin/bash exec &>/dev/null echo

列举了MySQL主从复制主要的相关参数 binlog server_id 服务器在集群中唯一标识符 log_bin[=binlog_name] 启动二进制日志 log_bin_index 二进制日志索引名称 binlog_format 二进制日志的类型 binlog_row_image 二进制镜像保存量 binlog_do_db,binlog_ignore_db 记录在二进制日志中和不记录在二进制日志中 replicate_do_db[table] slave只重放指定的库/表 replicate_ignore_db[table] slave 忽略重放指定的库/表 replicate_wild_do_table slave重放满足匹配的表 replicate_wild_ignore_table slave忽略重放满足匹配条件的表 binlog_cache_size 缓存还没刷新到磁盘的binlog日志 max_binlog_size 二进制日志最大值 expire_logs_days 二进制日志被保留的有效期 sync_binlog 二进制日志刷新到磁盘频率 binlog_rows_query_log_events 二进制日志基于行，用来指定额外的信息 ##relay_log relay_log[=relay_log_name] 从节点中继日志名 relay_log_index

【推荐阅读】微服务还能火多久？>>> 在面试时，比如被问到HSRP的主备切换时间时多久，STP几个状态的停留时间，自己知道有这些东西，但在工作中不会经常用到，就老是记不住，觉得可能还是自己基础不够牢固，知识掌握不够全面。 充分而彻底地了解一个协议，是记住它的关键! Spanning tree(802.1d)收敛过程 天下群雄纷起(switch power on)，个个都默认是老大(root bridge)，但都还比较谦虚，保持静默15秒(listening，unable forwarding end user traffic)，用于收集情报(other switch BPDU)，最早进入静默状态的山大王(最先启动的交换机)等的不耐烦了(listening timeout)，因为他没有收集到任何消息，开始散发传单(it's own BPDU)，2秒一次(BPDU interval )，大言不惭称帝(root bridge)。 各地土匪由于武力不敌(BPDU priority 低)，只好俯首称臣(non root bridge)，只敢乖乖地接收皇帝的圣旨(BPDU configuration )，然后再 relay 一下皇帝的圣旨到下游郡王… 大枭雄(BPDU priority 最高)醒来的晚(power on)，看到如此情形不愿意了，一个小虾米竟然充大尾巴狼，于是发出了自己的挑战书

【今日推荐】：为什么一到面试就懵逼！>>> Mysql主从基本原理，主要形式以及主从同步延迟原理 (读写分离)导致主库从库数据不一致问题的及解决方案 一、主从数据库的区别 从数据库(Slave)是主数据库的备份，当主数据库(Master)变化时从数据库要更新，这些数据库软件可以设计更新周期。这是提高信息安全的手段。主从数据库服务器不在一个地理位置上，当发生意外时数据库可以保存。 (1) 主从分工 其中Master负责写操作的负载，也就是说一切写的操作都在Master上进行，而读的操作则分摊到Slave上进行。这样一来的可以大大提高读取的效率。在一般的互联网应用中，经过一些数据调查得出结论，读/写的比例大概在 10：1左右 ，也就是说大量的数据操作是集中在读的操作，这也就是为什么我们会有多个Slave的原因。但是为什么要分离读和写呢？熟悉DB的研发人员都知道，写操作涉及到锁的问题，不管是行锁还是表锁还是块锁，都是比较降低系统执行效率的事情。我们这样的分离是把写操作集中在一个节点上，而读操作其其他的N个节点上进行，从另一个方面有效的提高了读的效率，保证了系统的高可用性。 (2) 基本过程 1)、Mysql的主从同步就是当master（主库）发生数据变化的时候，会实时同步到slave（从库）。 2)、主从复制可以水平扩展数据库的负载能力，容错，高可用，数据备份。 3)、不管是delete

3 月，跳不动了？>>> 作者：高鹏（网名八怪） 文章末尾有他著作的《深入理解 MySQL 主从原理 32 讲》，深入透彻理解 MySQL 主从，GTID 相关技术知识。 本文来源：转载自公众号-老叶茶馆 *爱可生开源社区出品，原创内容未经授权不得随意使用，转载请联系小编并注明来源。 本文为笔者 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

3 月，跳不动了？>>> mysql半同步复制跟无损半同步复制的区别： 无损复制其实就是对semi sync增加了rpl_semi_sync_master_wait_point参数，来控制半同步模式下主库在返回给会话事务成功之前提交事务的方式。rpl_semi_sync_master_wait_point该参数有两个值：AFTER_COMMIT和AFTER_SYNC 第一个值：AFTER_COMMIT（5.6默认值） master将每个事务写入binlog（sync_binlog=1）， 传递到slave刷新到磁盘(sync_relay=1)，同时主库提交事务 。master等待slave反馈收到relay log，只有收到ACK后master才将commit OK结果反馈给客户端。 第二个值：AFTER_SYNC（5.7默认值，但5.6中无此模式） master将每个事务写入binlog , 传递到slave刷新到磁盘(relay log)。master等待slave反馈接收到relay log的ack之后，再提交事务 并且返回commit OK结果给客户端。 即使主库crash，所有在主库上已经提交的事务都能保证已经同步到slave的relay log中。 半同步复制与无损复制的对比 1) ACK的时间点不同 - 半同步复制在InnoDB层的Commit Log后等待ACK

3 月，跳不动了？>>> 作者：cheery@QAX-ATEAM && n0thing@QAX-ATEAM 公众号： 奇安信ATEAM 0x00 前言 本文是由一次真实的授权渗透案例引申而出的技术分析和总结文章。在文章中我们会首先简单介绍这次案例的整体渗透流程并进行部分演绎，但不会进行详细的截图和描述，一是怕“有心人”发现端倪去目标复现漏洞和破坏，二是作为一线攻击人员，大家都明白渗透过程也是一个试错过程，针对某一个点我们可能尝试了无数种方法，最后写入文章的只有成功的一种，而这种方法很有可能也是众所周知的方法。因此我们只会简单介绍渗透流程，然后提取整个渗透过程中比较精华的点，以点及面来进行技术分析和探讨，望不同的人有不同的收获。 0x01 渗透流程简述 在接到项目以后，由“前端”小组（初步技术分析小组）进行项目分析和信息收集以及整理，整理出了一批域名和一些关键站点，其中有一个phpmyadmin 和 discuz的组合建站，且均暴露在外网，这也是很常见的一种情况。由于网站某个web端口的解析配置问题导致了php不被解析而形成任意文件下载漏洞，通过这个漏洞我们拿到了mysql的root账户密码。由于linux服务器权限设置比较严格的问题没法直接使用phpmyadmin登录mysql而提权拿到discuz的webshell

某厂面试归来，发现自己落伍了！>>> 作者：林靖华 爱可生服务团队成员，负责处理客户在MySQL日常运维中遇到的问题；擅长处理备份相关的问题，对数据库相关技术有浓厚的兴趣，喜欢钻研各种问题。 本文来源：原创投稿 *爱可生开源社区出品，原创内容未经授权不得随意使用，转载请联系小编并注明来源。 前言 在日常数据库运维中，备份是不可缺少的一部分。我们常常用备份集来新建从库或恢复数据不一致的实例等等。但有些时候恢复完实例加回集群后，是有可能会丢失数据的。 实验 环境准备 ip role server_id server_uuid log_slave_updates version 192.168.13.131 master 1 eefac7d8-2370-11e9-bfeb-000c29d74445 on 5.7.29 192.168.13.132 slave 2 b66b4623-207d-11ea-a993-000c29122c12 on 5.7.29 步骤 1、主从同步验证 先在主库写入一些数据，然后验证数据已经同步到从库 -- master(131) mysql> create database test1; Query OK, 1 row affected (0.00 sec) mysql> create database test2; Query OK, 1 row

本文作者：高鹏，欢迎订阅他的简书专栏 本节包含一个笔记，链接如下： 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