Relay

一、MySQL的数据库主从复制原理 MySQL主从复制实际上基于二进制日志，原理可以用一张图来表示： 分为四步走： 1. 主库对所有DDL和DML产生的日志写进binlog； 2. 主库生成一个 log dump 线程，用来给从库I/O线程读取binlog； 3. 从库的I/O Thread去请求主库的binlog，并将得到的binlog日志写到relay log文件中； 4. 从库的SQL Thread会读取relay log文件中的日志解析成具体操作，将主库的DDL和DML操作事件重放。 关于DDL和DML SQL语言共分为四大类：查询语言DQL，控制语言DCL，操纵语言DML，定义语言DDL。 DQL：可以简单理解为SELECT语句； DCL：GRANT、ROLLBACK和COMMIT一类语句； DML：可以理解为CREATE一类的语句； DDL：INSERT、UPDATE和DELETE语句都是； 二、主从复制存在的问题 1. 主库宕机后，数据可能丢失； 2. 主从同步延迟。 三、MySQL数据库主从同步延迟产生原因 原因分析 MySQL的主从复制都是单线程的操作，主库对所有DDL和DML产生的日志写进binlog，由于binlog是顺序写，所以效率很高。Slave的SQL Thread线程将主库的DDL和DML操作事件在slave中重放。DML和DDL的IO操作是随即的

关于MySQL GTID的一些信息 GTID持久化介质有俩个，一个是TABLE mysql.gtid_executed 表，另外一个是binlog日志。 TABLE mysql.gtid_executed表内的gtid信息并不是实时更新的，只有在binlog二进制日志进行切割的时候才会记录到表mysql.gtid_executed中。 binlog二进制日志中的gtid信息是在commit之后生成的，并且这个时候还会生成last commit和seqeue number（这俩个值和MySQL的group commit以及并行复制有关系） binlog_gtid_simple_recovery 在没有开启这个参数的时候，MySQL重启或者恢复都会扫描全部的binlog获取gtid_executed信息，这样做耗时会很长。开启这个参数之后MySQL只会扫描第一个binlog和最后一个binlog文件。还有一个需要注意的是在中途开启GTID的时候，也会扫描前面所有的binlog直到获取得到 sql_log_bin 支持session级别的动态修改，关闭这个参数之后，那么在当前session并不会产生GTID。 GTID主从复制。 在主库关闭binlog之后不会产生gtid；在从库关闭binlog，那么gtid_executed和gtid_purged和TABLE mysql.gtid

写在前面： 有关openLDAP的部署文档在网上随意能找到很多，但是最近用到才发现网上的教程多数是旧版的用法，例如"/etc/openldap/slapd.conf “早已弃用，更有甚者直接修改/etc/openldap/slapd.d/下的文件，打开的时候上面明确写着不能修改此文件，那是多大的勇气能写成文档出来分享呢？ 通过参考官方文档并且借鉴了两位前辈的文档，我整理出来如下步骤，并经过验证 一、环境准备 1. 操作系统: CentOS 7.x 2. 关闭防火墙、selinux 3. yum源(略) 忘了用不用依赖epel-release 自己试试 二、OpenLDAP服务安装 1. 服务安装 yum install -y openldap openldap-servers openldap-clients openldap-devel 2. 生成OpenLDAP管理密码 [root@localhost ~]# slappasswd New password: //此处输入密码 Re-enter new password: //再次密码 {SSHA}CrdqT5EAh8H2y2SorEUbuxP3R5eOggjb 记录好生成的密码，后面用得到 3. 配置OpenLDAP OpenLDAP 2.3之后的版本取消了/etc/openldap/slapd.conf的配置方式

数据回档常常是使用全量备份+binlog增量实现的。 而数据量很大的情况下，增量恢复binlog一直是一个苦恼的问题，因为恢复binlog速度十分慢，并且容易出错。 恢复binlog文件一般有两种方法： 〇 先解析成sql文件，再导入 MySQL mysqlbinlog mysql- bin . 000001 --start- position = n > / data / add . sql mysqlbinlog mysql- bin . 000002 . . . mysql- bin . n > > / data / add . sql mysql -u -p -S < / data / add . sql 〇 直接管道到MySQL中 mysqlbinlog mysql-bin.000001 --start-position=n | mysql -u -p -S mysqlbinlog mysql-bin.000002 ... mysql-bin.n | mysql -u -p -S 关于这种方式的更多info，可以参考： https://dev.mysql.com/doc/refman/5.7/en/point-in-time-recovery.html 然而这两种方式原理都是一样的，通过mysqlbinlog解析成sql并导入到MySQL中。 〇 优点： 操作方便

MySql第零章，安装及集群配置 一、MySql安装 1、RPM安装 RPM安装，无法自定义一些安装路径和配置文件路径 ##以后再填坑 2、Generic安装 二进制 预编译 Generic，下载地址： https://cdn.mysql.com/archives/mysql-5.7/mysql-5.7.29-linux-glibc2.12-x86_64.tar.gz [root@mysq|1 ~ ]# groupadd mysql [root@mysql1 ~ ]# useradd -r -g mysql -s /bin/false mysql [root@mysql1 ~ ]# cd /usr/local [root@mysq|1 local]# tar -zxvf /opt/software/file/mysql-5.7.29-linux-glibc2.12-x86_64.tar.gz [root@mysq|1 local]# ln -s mysql-5.7.29-linux-glibc2.12-x86_64 mysql #超链接 1、mysql初始化 没有编译安装的过程 [root@mysq|1 local]# cd mysql [root@mysql1 mysq|]# mkdir mysql-files [root@mysql1 mysq|]# chmod 750

上一篇mysql面试的文章之后收到不少朋友的意见，希望深入讲讲复制、日志的格式这些，今天，我们就来深挖一下mysql的复制机制到底有哪一些，以及binlog和relay-log的结构到底是什么样子的。 binlog作用 binlog的主要作用是记录数据库中表的更改，它只记录改变数据的sql，不改变数据的sql不会写入，比如select语句一般不会被记录，因为他们不会对数据产生任何改动。 用一个实际的场景看下binlog产生的过程，准备sql： create table test(text varchar(20)); insert into test values ('test_text'); select * from test; flush logs; 查看binlog show binlog events in 'binlog.000029'; 显示的结果如下： binlog 另外，也可以使用mysqlbinlog工具来查看binlog的内容： show variables like 'log_%'; #查看日志目录 mysqlbinlog --short-form --force-if-open --base64-output=never /usr/local/var/mysql/binlog.000029 从日志我们可以看到执行了创建表的语句以及一个Format

想请问下，搭建好coturn服务器，使用的阿里云ECS服务器， 测试地址：https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/ 使用火狐浏览器就没有问题，但是用google虽然done，但是报701错误？360浏览器也报这个错？？ Note: errors from onicecandidateerror above are not neccessarily fatal. For example an IPv6 DNS lookup may fail but relay candidates can still be gathered via IPv4. The server stun:47.95.XXX.XX:3478 returned an error with code=701: STUN server address is incompatible. 转中文：报错信息： 注意：上述onicecandidateerror错误不一定是致命的。 例如，IPv6 DNS查找可能会失败，但仍可以通过IPv4收集中继候选者。 服务器stun：47.95.XXX.XX：3478返回了错误，代码为701： 正常的火狐浏览器： google浏览器： 来源： oschina 链接： https://my

场景描述: 如果从库上表 t 数据与主库不一致，导致复制错误，整个库的数据量很大，重做从库很慢，如何单独恢复这张表的数据？ 通常认为是不能修复单表数据的，因为涉及到各表状态不一致的问题。 下面就列举备份单表恢复到从库会面临的问题以及解决办法 一、本次演示环境描述: Dell物理服务器r620 两台 网络环境都是内网 master:192.168.1.220 slave:192.168.1.217 OS系统环境：centos7.8 X86_64位最小化安装，关闭iptables，关闭selinux 测试软件版本:mysql5.7.27二进制包 提前配置好基于Gtid的MySQL主从复制 创建模拟测试数据，模拟故障场景 修复MySQL主从复制 pt-table-checksum 校验修复后的MySQL主从复制数据是否一致 二、配置主从复制 MySQL的安装过程此处不再描述，自行百度 配置主从复制 给一个master机器配置一个新的slave的话，记得在mysqldump备份数据时加参数--set-gtid-purged=ON 知识补充： 1.常规备份是要加--set-gtid-purged=OFF解决备份时的警告 [root@localhost ~]# mysqldump -uroot -p'dXdjVF#(y3lt' --set-gtid-purged=OFF --single

一、背景 ​ 随着业务的快速发展，对于很多公司来说，构建于单地域的技术体系架构，会面临诸如下面的多种问题： 基础设施的有限性限制了业务的可扩展性。 业务扩大到单个数据中心撑不住，主要机房已经不能再添加机器，但业务却不断要求扩展； 机房、城市级别的故障灾害，影响服务的可持续性。 整个机房级别的故障时有发生，每次都引起业务的不可用，对公司的形象与收入都造成严重的影响。如2015年杭州某数据中心光缆被挖断，造成某产品业务几个小时的中断，导致严重的损失； 跨地域的访问，影响用户体验等。 随着全球化脚步的逼近，试想用户客户端与服务一次交互，一次RTT最少需要10ms，若广州到北京网络延迟一般为40ms，当用户客户端需要与服务器产生多次交互时，对用户体验影响就很大，用户体验非常不友好。 OPPO互联网业务发展快速，已经扩展到全球，随之带来的是技术上的多机房架构，对数据的全球多机房同步在一致性、响应时间、吞吐等方面有更高要求。 为了解决以上问题带来的影响，本文将从异地多活底层，数据层面探索，如何给上层业务提供一个安全、可靠、稳定的数据环境，让上层业务可以集中精力专注业务开发，减少对数据多活的关注。 1、面临的挑战 数据多地写入的冲突解决问题 远距离两地传输网络问题 同步过程中数据一致性问题 数据同步的幂等性问题 作为同步中心，关于数据复用问题 基于上述挑战，调研对比相关的几个主流开源产品