Relay

故障现象： 进入slave服务器，运行： mysql> show slave status\G ....... Relay_Log_File: localhost-relay-bin.000001 Relay_Log_Pos: 151 Relay_Master_Log_File: localhost-bin.000002 Slave_IO_Running: Yes Slave_SQL_Running: No Replicate_Do_DB: Replicate_Ignore_DB: ...... 解决办法一、 Slave_SQL_Running: No 1.程序可能在slave上进行了写操作 2.也可能是slave机器重起后，事务回滚造成的. 一般是事务回滚造成的： 解决办法一： mysql> stop slave ; mysql> set GLOBAL SQL_SLAVE_SKIP_COUNTER=1; #客户端运行，用来跳过几个事件，只有当同步进程出现错误而停止的时候才可以执行。 mysql> start slave ; 解决办法二： 首先停掉Slave服务：stop slave ; 到主服务器上查看主机状态： 记录File和Position对应的值 进入master mysql> show master status; +----------------------+----

奥科 利用AudioCodes VolPerfect技术实现卓越的语音质量 •按需可扩展的模块化体系架构 •丰富的数字（E1/T1/J1）和模拟（FXO/FXS）接口 •经济适用的低密度网关 •当电源或网络出现问题时，生命线功能可以转到PSTN •可以转换到PSTN以确保连接 •内置的OSN模块可用于运行第三方的应用程序 •内置的基于DSP的会议模块 Mediant 1000是AudioCodes使用最新技术的节约成本的可用于无线和有线的VoIP媒体网关。智能的封装与一个可堆叠的1U机箱中，被设计用于企业和小型运营商的TDM和IP网络的接口。得益于AudioCodes创新的分组技术，MEDIANT 1000能够快速投放市场，经济可靠的部署下一代网络。 Mediant 1000基于AudioCodes领先而出色的和姓媒体网关技术VoIPerfect架构，MEDIANT 1000可将传统的电话和PBX连接到IP网络。并提供出色的语音质量。除了作为纯媒体网关之外，Mediant 1000于多家网关、交换机、网守、代理服务器、IP话机、会话边界控制器以及防火墙有良好的互通性。 可根据业务增长升级 Mediant 10000在满足服务提供商升级的需求的同时也能满足较小场所的密度需求。简约的模块化网关具有良好的可扩展性，支持1,2,4E1/T1/J1接口，或1至24个模拟FXO/FXS接口

需求：业务场景中有很多需要查询t+1的数据，但又不想影响生产实时的业务，是否可以搭建一个延时的灾备库就可以解决这个问题呢。 问题：如何实现延时？ 解决方向：recovery_min_apply_delay (integer) 这个参数可以实现从库的延时同步。 测试过程： 配置在备库recovery.conf中 recovery_min_apply_delay = 5min 主库插入一条数据，5分钟后从库可以查到该数据，在此期间，不影响从库的使用。 需要注意的是，如果从库配置了synchronous_commit 这个参数，一定要配为on，配为remote_apply时，在主库上插入一条数据，主库会hang住等待5min(等待从库完成apply操作)后，然后才能返回执行成功or失败的结果。 9.4版本之前存在bug，配置好这个参数后，马上重启standby库，连接数据库会报错如下：psql: FATAL: the database system is starting up，这时候需要等待配置时间，然后连接才可以正常使用数据库，但是目前这个bug已经修复了。高版本不存在这个问题。 从库放开给用户使用，带来的问题： 在进行主从复制的时候，如果从库放开给用户使用，很容易产生冲突。举个例子，从库有一个长事务或者长查询正在执行，此时，主库执行 UPDATE 并 VACUUM

mysql windows主从 准备环境 数据库版本 主数据库版本 5.7.21 从数据库版本 5.7.25 只要数据库的前两个版本号一致,那么就可以进行主从同步。 主数据库开启binlog 日志 #mysql binlog 日志 log_bin = C:/Development/mysql/mysql-5.7.25-winx64/log/mysql-bin #服务器标识id server-id = 001 expire_logs_days = 7 max_binlog_size = 100m binlog_format=MIXED 重启服务器，使修改的my.ini 生效 使用下面的语句进行验证是否开启log_bin SHOW VARIABLES LIKE '%log_bin%' 创建从库的登陆用户 GRANT replication SLAVE ON *.* TO repl@'%' IDENTIFIED by '123456' 使用新建用户进行登陆，进行验证 主机数据备份到从库 C:\Development\mysql\mysql-5.7.25-winx64\bin> mysqldump.exe -h localhost -u root -p123456 --databases test_copy | mysql -h 192.168.5.90 -u root -p123456

MySQL 5.7.17主从复制实战(一主多从) 主从复制的原理： 分为同步复制和异步复制，实际复制架构中大部分为异步复制。 复制的基本过程如下： 1).Slave上面的IO进程连接上Master，并请求从指定日志文件的指定位置（或者从最开始的日志）之后的日志内容； 2).Master接收到来自Slave的IO进程的请求后，通过负责复制的IO进程根据请求信息读取制定日志指定位置之后的日志信息，返回给Slave 的IO进程。返回信息中除了日志所包含的信息之外，还包括本次返回的信息已经到Master端的bin-log文件的名称以及bin-log的位置； 3).Slave的IO进程接收到信息后，将接收到的日志内容依次添加到Slave端的relay-log文件的最末端，并将读取到的Master端的 bin-log的文件名和位置记录到master-info文件中，以便在下一次读取的时候能够清楚的告诉Master“我需要从某个bin-log的哪个位置开始往后的日志内容，请发给我”； 4).Slave的Sql进程检测到relay-log中新增加了内容后，会马上解析relay-log的内容成为在Master端真实执行时候的那些可执行的内容，并在自身执行。 一、环境准备 操作系统版本：centos 7.2 服务器架构： Master(主) ip：192.168.2.70 主机名称：node01

查看配置DHCP服务器可用IP地址命令（理论值）： dis ip pool DHCP（Dynamic Host Configure Protocol），动态主机配置协议 从BOOTP（Bootstrap Protocol）协议发展而来（如使用Wireshark抓包，应过滤关键词为 bootp）； UDP封装，服务器= 67 ，客户端= 68 ； 动态分配TCP/IP信息（IP地址、子网掩码、默认网关、DNS服务器等） 分配出去的信息是有 租约 的 DHCP 系统组成 DHCP Client（客户端） 需要动态获得IP地址的主机 DHCPServer（服务器） 能提供DHCP功能的服务器或网络设备 DHCP Relay（中继） 一般为路由器或三层交换机等网络设备 配置DHCP命令 dhcp enable-------------全局模式，开启DHCP总开关 dhcp select interface--进入端口，开启DHCP服务 DHCP报文类型 报文类型 备注 DHCP Discover 客户端用来寻找DHCP服务器 DHCP Offer DHCP服务器用来响应DHCP Discover报文，此报文携带了各种配置信息 DHCP Request 客户端请求配置确认，或者续借租期 DHCP ACK 服务器对Request报文的确认响应 DHCP NAK

MySQL组复制系列文章： MySQL组复制大纲 MySQL组复制(1)：组复制技术简介 MySQL组复制(2)：配置单主模型的组复制 MySQL组复制(3)：配置多主模型的组复制 MySQL组复制(4)：组复制理论透彻分析 这一篇对MySQL组复制做个详细的整理和解释，是 MySQL组复制官方手册 的整理版和总结。 <a name="blog1"></a> 1.组复制插件架构图 MySQL组复制是一个MySQL插件，它基于常规的MySQL复制，利用了基于 行格式的二进制日志和GTID 等特性。下图是MySQL组复制的整体框架图。 以下是对该图中各组件的大致介绍，涉及到的术语先浏览一遍，后面会详细解释。 从上图的最顶端开始，有一系列的API控制组复制插件如何和MySQL Server进行交互(图中灰色方框)。 中间有一些接口可以使信息从MySQL Server流向组复制插件，反之亦然。这些接口将MySQL Server核心部分和插件隔离开来。在Server到插件的方向上，传递一些通知信息，例如server正在启动，server正在恢复，server已准备好接收连接，server将要提交事务等等。另一方向，即插件到server的方向上，插件会通知server对事务进行提交，终止正在进行的事务，将事务放进relay-log中排队等等。 从API往下是一些响应组件

MySQL组复制系列文章： MySQL组复制大纲 MySQL组复制(1)：组复制技术简介 MySQL组复制(2)：配置单主模型的组复制 MySQL组复制(3)：配置多主模型的组复制 MySQL组复制(4)：组复制理论透彻分析 MySQL的组复制可以配置为 单主模型 和 多主模型 两种工作模式，它们都能保证MySQL的高可用。以下是两种工作模式的特性简介： 单主模型：从复制组中众多个MySQL节点中 自动选举 一个master节点，只有master节点可以写，其他节点自动设置为read only。当master节点故障时，会自动选举一个新的master节点，选举成功后，它将设置为可写，其他slave将指向这个新的master。 多主模型：复制组中的任何一个节点都可以写，因此没有master和slave的概念，只要突然故障的节点数量不太多，这个多主模型就能继续可用。 虽然多主模型的特性很诱人，但缺点是要配置和维护这种模式，必须要深入理解组复制的理论，更重要的是，多主模型限制较多，其一致性、安全性还需要多做测试。 而使用单主模型的组复制就简单的太多了，唯一需要知道的就是它会自动选举master节点这个特性，因为它的维护一切都是自动进行的，甚至对于管理人员来说，完全可以不用去了解组复制的理论。 虽然单主模型比多主模型的性能要差，但它没有数据不一致的危险，加上限制少，配置简单

转载自：http://www.cnblogs.com/zhangzihong/p/10443526.html 一、简介 MySQL Group Replication（简称MGR）字面意思是mysql组复制的意思,但其实他是一个高可用的集群架构,暂时只支持mysql5.7和mysql8.0版本. 是MySQL官方于2016年12月推出的一个全新的高可用与高扩展的解决方案,提供了高可用、高扩展、高可靠的MySQL集群服务. 也是mysql官方基于组复制概念并充分参考MariaDB Galera Cluster和Percona XtraDB Cluster结合而来的新的高可用集群架构. MySQL Group Replication是建立在基于Paxos的XCom之上的，正因为有了XCom基础设施，保证数据库状态机在节点间的事务一致性，才能在理论和实践中保证数据库系统在不同节点间的事务一致性。 由一般主从复制概念扩展,多个节点共同组成一个数据库集群，事务的提交必须经过半数以上节点同意方可提交,在集群中每个节点上都维护一个数据库状态机，保证节点间事务的一致性。 优点: 高一致性，基于原生复制及paxos协议的组复制技术. 高容错性，有自动检测机制，当出现宕机后,会自动剔除问题节点,其他节点可以正常使用(类似zk集群),当不同节点产生资源争用冲突时,会按照先到先得处理

转载： https://www.cnblogs.com/luoahong/articles/8043035.html MGR简介 MySQL Group Replication（下简称：MGR）是MySQL官方推出的一种基于Paxos协议的状态机复制。在MGR出现之前，用户常见的MySQL高可用方式，无论怎么变化架构，本质就是Master-Slave架构。MySQL 5.7版本开始支持无损半同步复制（lossless semi-sync replication），从而进一步提示数据复制的强一致性。 MGR与其他复制的对比介绍 MySQL异步复制 master事务的提交不需要经过slave的确认，slave是否接收到master的binlog，master并不care。slave接收到master binlog后先写relay log，最后异步地去执行relay log中的sql应用到自身。由于master的提交不需要确保slave relay log是否被正确接受，当slave接受master binlog失败或者relay log应用失败，master无法感知。 假设master发生宕机并且binlog还没来得及被slave接收，而切换程序将slave提升为新的master，就会出现数据不一致的情况！另外，在高并发的情况下，传统的主从复制，从节点可能会与主产生较大的延迟