Relay

MySQL 5.7 MGR 1、背景 主从复制，一主多从，主库提供读写功能，从库提供只读功能。当一个事务在master 提交成功时，会把binlog文件同步到从库服务器上落地为relay log给slave端执行，这个过程主库是不考虑从库是否有接收到binlog文件，有可能出现这种情况，当主库commit一个事务后，数据库发生宕机，刚好它的binlog还没来得及传送到slave端，这个时候选任何一个slave端都会丢失这个事务，造成数据不一致情况。 为了避免出现主从数据不一致的情况，MySQL引入了半同步复制，添加多了一个从库反馈机制，即半同步复制。这个有两种方式设置： 主库执行完事务后，同步binlog给从库，从库ack反馈接收到binlog，主库提交commit，反馈给客户端，释放会话； 主库执行完事务后，主库提交commit ，同步binlog给从库，从库ack反馈接收到binlog，反馈给客户端，释放会话； 但是，虽然满足了一主多从，读写分析，数据一致，但是，依旧有两个弊端： 写操作只能在master上； 如果master宕机，需要人为选择新主并重新给其他的slave端执行change master； 为了解决一系列问题，官方推出了MySQL Group Replication，从group replication发布以后，就有3种方法来实现MySQL的高可用集群：

多操作系统平台资产风险状况研究：微软漏洞最多 Kenna Security 发布了一份新的报告指出，70％ 的微软资产至少具有一个高风险漏洞。在研究期间，研究人员共发现了微软资产中的 2.15 亿个漏洞，其中已完成修复的漏洞有 1.79 亿个，占比 83％。其余未修补的 3600 万个漏洞要高于 Mac、Linux 和 Unix 资产的总和。 来源：开源中国 这恐怕更多反映的是微软资产占比最多。 用户 6 年前给 OneDrive 提了条建议 微软：今年搞定了 早在 2014 年 8 月份，就有用户在官方社区建议微软给 OneDrive 网盘增加增量同步的功能。6 年后，也就是 2020 年 4 月 24 日，微软官方人员回复了这个帖子，带来了一个好消息——OneDrive 网盘的个人版、商业版都已经支持增量同步功能了，祝大家“玩得开心”。 来源：快科技 据说巨人的神经链路比较长，当他的脚被蛇咬了一口之后，要几个月之后才能感觉到疼。 艺术家免费分享了打造复古计算机和游戏系统的纸模型工艺包 如果你正在寻找一种怀旧的方法或想在新冠病毒封锁期间做一些巧妙的事情，那么为什么不利用一些简单的纸质模型工具来打造一台老式电脑或游戏系统呢？Rocky Bergen 的个人网页查看： http://rockybergen.com/papercraft 来源：cnBeta.COM 可以用纸模来过家家

为什么基于Docker搭建？ 资源有限 虚拟机搭建对机器配置有要求，并且安装mysql步骤繁琐 一台机器上可以运行多个Docker容器 Docker容器之间相互独立，有独立ip，互不冲突 Docker使用步骤简便，启动容器在秒级别 利用Docker搭建主从服务器 首先拉取docker镜像,我们这里使用5.7版本的mysql： docker pull mysql:5.7 然后使用此镜像启动容器，这里需要分别启动主从两个容器 Master(主)： docker run -p 3339:3306 --name mysql-master -e MYSQL_ROOT_PASSWORD=123456 -d mysql:5.7 Slave(从) docker run -p 3340:3306 --name mysql-slave -e MYSQL_ROOT_PASSWORD=123456 -d mysql:5.7 Master对外映射的端口是3339，Slave对外映射的端口是3340。因为docker容器是相互独立的，每个容器有其独立的ip，所以不同容器使用相同的端口并不会冲突。这里我们应该尽量使用mysql默认的3306端口，否则可能会出现无法通过ip连接docker容器内mysql的问题。 使用docker ps命令查看正在运行的容器： 此时可以使用Navicat等工具测试连接mysql

MySQL5.7多源复制配置过程 ~ ~ MySQL多源复制使Slave可以并行接收来自多个直接Master的事务。多源复制可用于将多个服务器备份到单个服务器、合并表分片并将数据从多个服务器合并到单个服务器。在应用事务时，多源复制不会实现任何冲突检测或解决方案，如果需要则这些任务将由应用程序。 在多源复制拓扑中，Slave会为其接收事务的每个Master创建一个复制通道。 角色 IP M1 192.168.75.132 M2 192.168.75.130 S 192.168.75.131 一、基础配置说明 1）服务器设置 多源复制拓扑至少需要配置两个主服务器和一个从属服务器。在这里假设两个主服务器为master1和master2，以及一个从服务器slavehost。从服务器将从每个主机复制一个数据库，即从master1复制db1，从master2复制db2。 2）binlog设置 多源复制拓扑中Master端可以配置为基于GTID的复制或基于二进制日志位置的复制,但不运行混用。 Master配置: log_bin =/data/mysql_5.7.22/mysql-bin binlog_format =ROW 3）复制信息存储设置 在多源复制拓扑中的Slave需要设置master_info_repository和relay_log_info

分布式系统如果保证接口的幂等性？ 数据设置状态值 数据库设置唯一性 每个数据请求有唯一性标识 分布式session如何处理？ tomcat+redis，TomcatRedisSessionManager,将所有部署的tomcat都将session存储到redis即可。使用方法不变，是Tomcat封装的类将session存储到了redis，依赖web容器 spring session +redis：spring 将session存储到redis 分库分表 为什么要分库分表？表数据量达到上千万级别，数据库磁盘消耗高，QPS响应慢，需要通过分库分表来优化 分库分表中间件？中间件有client类型，proxy类型 什么是垂直分和水平分？ 如何平滑的执行分库分表？ 启动多个线程读取原始数据到数据中间件中 双写迁移方案： 分库分表之后全局唯一ID如何生成（主键自增ID）？ 全局表：生成主键ID的全局数据库A，每次都去数据库A里面得到主键ID，然后再去其他数据库insert 数据。瓶颈：单库，适用于 并发量小，数据大的情况，每秒最高并发最大为几百的合适。 uuid ：本地生成，不基于数据库，存储空间大，字段太长，做为主键性能差 利用redis的incr原子性操作自增 MySQL多实例主键自增 ：优点：解决了单点问题，缺点:确定了步长 无法再次扩容 什么是读写分离？为什么要有读写分离？ 数据库一般

第二十九节 MySQL数据库企业级应用实践 一，概述 1.1 MySQL介绍 MySQL属于传统关系型数据库产品，它开放式的架构使得用户选择性很强，同时社区开发与维护人数众多。其功能稳定，性能卓越，且在遵守GPL协议的前提下，可以免费使用与修改，也为MySQL的推广与使用带来了更多的利好。在MySQL成长与发展过程中，支持的功能逐渐增多，性能也不断提高，对平台的支持也越来越多。 MySQL是一种关系型数据库管理系统，关系型数据库的特点是将数据保存在不同的表中，再将这些表放入不同的数据库中，而不是将所有数据统一放在一个大仓库里，这样的设计增加了MySQL的读取速度，而且灵活性和可管理性也得到了很大提高。访问及管理MySQL数据库的最常用标准化语言为SQL结构化查询语言。 1.2 MariaDB 数据库的诞生背景介绍 自甲骨文公司收购MySQL后，其在商业数据库与开源数据库领域市场的占有份额都跃居第一，这样的格局引起了业内很多的人士的担忧，因为商业数据库的老大有可能将MySQL闭源。为了避免Oracle将MySQL闭源，而无开源的类MySQL数据库可用，MySQL社区采用分支的方式来避开这个风险。MariaDB数据库就这样诞生了，MariaDB是一个向后兼容，可能在以后替代MySQL的数据库产品，其官方地址为：https://mariadb.org/ 。不过，这里还是建议大家选择更稳定

MySQL数据库的主从复制方案，和使用scp/rsync等命令进行的文件级别复制类似，都是数据的远程传输，只不过MySQL的主从复制是其自带的功能，无需借助第三方工具，而且，MySQL的主从复制并不是数据库磁盘上的文件直接拷贝，而是通过逻辑的binlog日志复制到要同步的服务器本地，然后由本地的线程读取日志里面的SQL语句重新应用到MySQL数据库中。 1.1.1 MySQL主从复制介绍 MySQL数据库支持单向、双向、链式级联、环状等不同业务场景的复制。在复制过程中，一台服务器充当主服务器（Master），接收来自用户的内容更新，而一个或多个其他的服务器充当从服务器（Slave），接收来自主服务器binlog文件的日志内容，解析出SQL重新更新到从服务器，使得主从服务器数据达到一致。 如果设置了链式级联复制，那么，从（slave）服务器本身除了充当从服务器外，也会同时充当其下面从服务器的主服务器。链式级复制类似A→B→C的复制形式。 1.1.2 MySQL主从复制的企业应用场景 MySQL主从复制集群功能使得MySQL数据库支持大规模高并发读写称为可能，同时有效地保护了物理服务器宕机场景的数据备份。 应用场景1：从服务器作为主服务器的实时数据备份 主从服务器架构的设置，可以大大加强MySQL数据库架构的健壮性。例如：当主服务器出现问题时

http://linux.vbird.org/linux_basic/0120howtolinux/0120howtolinux_1.php 一﹐先看如下兩本﹕ > 《精通區域網路》(Mastering Local Area Network) 儒林 (SYBEX) 翻譯出版 > 《TCP/IP 通訊協定入門與應用》博碩文化出版 這裡﹐基本上要能蓋起書本回答如下問題﹕ > 1) 什麼是網路﹖(LAN/WAN/MAN/Internet) > 2) 有哪些 Topologies﹖(BUS/Star/Ring) > 3) Network Media 有哪些﹖(Coaxial, UTP/STP, FiberOptic, Wireless, etc.) > 4) Major NOS (Network Operating System) > 5) Peer-to-Peer 和 Client/Server > 6) Protocol Binding 概念 (Netbios, TCP/IP, IPX/SPX) > 7) OSI Layer 基本概念 > 8) Encapsulation / Decapsulation 概念 > 9) BaseBand / BroadBand communication ( TDM / FDM ) > 10) CSMACD / Token Bus / Token

MGR配置_5.7.24 一、MGR基本原则要求 1)表必须使用Innodb存储引擎； 2)表必须有显示的主键； 3)仅支持IPv4网络； 4)网络性能良好；成员服务器之间hostname互通、网络延时低、目标端口开放。 A）关闭防火墙或开放后面设置得MGR通信端口: # service iptables stop # chkconfig --level 35 iptables off B）如果不想更改服务器hostname，这可以使用report_host参数指定数据通信专用主机名称，并在/etc/hosts中添加相应得地址解析。 # vim /etc/hosts 127.0.0.1 mgr21 这里使用mgr21作为MGR集群内部通信使用的主机名。 注意：千万不能写成真实IP(192.168.0.21 mgr21)，这样修改完在服务器重启后，主机名会被修改(至少Centos6里会这样)。 二、各个成员必须拥有的前提配置 开启binlog ==> log_bin=ON bin的ROW格式 ==> binlog_format=ROW Slave开启binlog ==> log_slave_updates=ON GTID模式开启 ==> gtid_mode=ON 复制信息库 ==> master_info_repository=TABLE 和 relay_log_info

一. 单个数据库服务器的缺点 数据库服务器存在单点问题 数据库服务器资源无法满足增长的读写请求 高峰时数据库连接数经常超过上限 二. 如何解决单点问题 增加额外的数据库服务器，组建数据库集群 同一集群中的数据库服务器需要具有相同的数据 集群中的任一服务器宕机后，其它服务器可以取代宕机服务器 三. MySQL主从复制架构 1. 主库将变更写入到主库的binlog中 一些MySQL版本并不会开启二进制日志，所以一定要检查是否开启 如果刚开始没有开启，后面再进行开启的话，需要重启数据库才能生效，而且数据库的重启往往会对业务造成很大的影响 尽管二进制日志对性能有稍许的影响，所以还是建议大家无论是否使用复制功能，都要开启Mysql二进制日志，因为 增量备份也需要二进制日志 2. 从库的IO线程在指定位置读取主库binlog内容存储到本地的中继日志（Relay Log）中 要完成二进制日志的传输过程，MySQL会在从服务器上启动一个工作线程，称为IO线程，这个IO线程会跟主数据库建立一个普通的客户端连接，然后在主服务器上启动一个特殊的二进制转储线程称为binlogdown线程 从库上的IO线程通过这个二进制转储线程来读取主库上的二进制事件，如果该事件追赶上主库，则会进入sleep状态，直到主库发起信号通知有新事件产生时，才会被唤醒，relay log的格式和binlog格式是完全相同的，