mysql主从配置

MHA(Master High Availability)目前在 MySQL 高可用方面是一个相对成熟的解决方案, 是一套优秀的作为 MySQL 高可用性环境下故障切换和主从提升的高可用软件。在 MySQL 故障切换过程中,MHA 能做到在 0~30 秒之内自动完成数据库的故障切换操 作,并且在进行故障切换的过程中,MHA 能在最大程度上保证数据的一致性,以达 到真正意义上的高可用。 该软件由两部分组成:MHA Manager(管理节点)和 MHA Node(数据节点)。MHA Manager 可以单独部署在一台独立的机器上管理多个 master-slave 集群,也可以部署在一台 slave 节 点上。 MHA Node 运行在每台 MySQL 服务器上,MHA Manager 会定时探测集群中的 master 节点,当 master 出现故障时,它可以自动将最新数据的 slave 提升为新的 master,然后将 所有其他的 slave 重新指向新的 master。整个故障转移过程对应用程序完全透明。MHA 可 以 与半同步复制结合起来,目前 MHA 主要支持一主多从的架构,要搭建 MHA,要求一个复制集群 中必须最少有三台数据库服务器,一主二从,即一台充当 master,一台充当备用 master,另 外一台充当从库. MHA 切换步骤: 1.从宕机的 master

环境说明: 　　主服务器:CentOS7.5 　　从服务器:Windows10(本地测试机) 1. 配置master(主服务器,CentOS7.5) 1.1 首先查看CentOS上面的MySQL是否启动 systemctl status mysqld 1.2 修改MySQL配置文件 vi /etc/my.cnf 添加以下内容: #服务器唯一id,默认是1(主从都必须不一样) server-id=1000 #启动二进制日志名称为mysql-bin log-bin=mysql-bin #binlog-do-db与binlog-ignore-db互斥,设置其中一个即可 #binlog-do-db=需要同步的数据库名(多个数据库重复设置即可) binlog-do-db=test01 #binlog-ignore-db=不需要同步的数据库01(多个数据库重复设置即可) #binlog-ignore-db=不需要同步的数据库02(多个数据库重复设置即可) #动清理30天之前的log文件(可自由指定时间) expire_logs_days=30 ##启用gtid类型,否则就是普通的复制架构(主从服务器都要配置且相同,要关都关,要开都开) #gtid_mode=on ###强制gtid的一致性 #enforce_gtid_consistency=1 ##当mysql启动或重启时

mysql主从介绍 MySQL主从又叫做Replication、AB复制。简单讲就是A和B两台机器做主从后，在A上写数据，另外一台B也会跟着写数据，两者数据实时同步的 MySQL主从是基于binlog的，主上须开启binlog才能进行主从。 主从过程大致有3个步骤 1）主将更改操作记录到binlog里 2）从将主的binlog事件(sql语句)同步到从本机上并记录在relaylog里 3）从根据relaylog里面的sql语句按顺序执行 主上有一个log dump线程，用来和从的I/O线程传递binlog 从上有两个线程，其中I/O线程用来同步主的binlog并生成relaylog，另外一个SQL线程用来把relaylog里面的sql语句执行一遍 两种情况：一种是做备份用，一种是作为读用 配置主 下面配置一主一从： 一台机器（192.168.37.130）作为主，安装mysql 修改my.cnf，增加server-id=130和log_bin=zenwen1(随意定义） #vim /etc/my.cnf //编辑配置文件 修改完配置文件后，启动或者重启mysqld服务 #/etc/init.d/mysqld restart 创建用作同步数据的用户 #mysql -uroot -p5650895 //登录mysql #grant replication slave on *.* to

1 复制概述 Mysql内建的复制功能是构建大型，高性能应用程序的基础。将Mysql的数据分布到多个系统上去，这种分布的机制，是通过将Mysql的某一台主机的数据复制到其它主机（slaves）上，并重新执行一遍来实现的。复制过程中一个服务器充当主服务器，而一个或多个其它服务器充当从服务器。主服务器将更新写入二进制日志文件，并维护文件的一个索引以跟踪日志循环。这些日志可以记录发送到从服务器的更新。当一个从服务器连接主服务器时，它通知主服务器从服务器在日志中读取的最后一次成功更新的位置。从服务器接收从那时起发生的任何更新，然后封锁并等待主服务器通知新的更新。 请注意当你进行复制时，所有对复制中的表的更新必须在主服务器上进行。否则，你必须要小心，以避免用户对主服务器上的表进行的更新与对从服务器上的表所进行的更新之间的冲突。 1.1 mysql支持的复制类型： 　　（１）：基于语句的复制： 在主服务器上执行的SQL语句，在从服务器上执行同样的语句。MySQL默认采用基于语句的复制，效率比较高。 一旦发现没法精确复制时， 会自动选着基于行的复制。 　　（２）：基于行的复制：把改变的内容复制过去，而不是把命令在从服务器上执行一遍. 从mysql5.0开始支持 　　（３）：混合类型的复制: 默认采用基于语句的复制，一旦发现基于语句的无法精确的复制时，就会采用基于行的复制。 　　 1

MHA：Master HA，对主节点进行监控，可实现自动故障转 移至其它从节点；通过提升某一从节点为新的主节点，基于主 从复制实现，还需要客户端配合实现，目前MHA主要支持一 主多从的架构，要搭建MHA,要求一个复制集群中必须最少有 三台数据库服务器，一主二从，即一台充当master，一台充 当备用master，另外一台充当从库，如果财大气粗，也可以用一台专门的服务器来当MHA监控管理服务器 MHA工作原理 1 从宕机崩溃的master保存二进制日志事件（binlog events） 2 识别含有最新更新的slave 3 应用差异的中继日志（relay log）到其他的slave 4 应用从master保存的二进制日志事件（binlog events） 5 提升一个slave为新的master 6 使其他的slave连接新的master进行复制 注意：MHA需要基于ssh，key验证登入方法 相关软件包 MHA监控服务器安装:mha4mysql-manager-0.55-1.el5.noarch，mha4mysql-node-0.54-1.el5.noarch 其他主从集群服务器安装:mha4mysql-node-0.54-1.el5.noarch 下面是实验环境 四台centos-7主机，一台搭建MHA管理服务器，另外三台，做一主二从架构

1. 前言 以前给 Mysql 数据库做主从，都是在主服务器停服的情况下做的。但是最近有一个项目，已经上线几天了，数据库也单服务器跑了几天，才确定要给 Mysql 服务器做一个主从架构，简单的一主一从架构。 项目最好能在不停服的情况下完成 Mysql 主从搭建。后来翻了一些资料，真的找到了可以在线新建或者重做主从的方法。 其实我们以前停服做主从的主要目的是想锁表，是想找到 master_log_file 和 master_log_pos 两个参数。如果有方法在不停服的情况下，能确定这两个参数，那么在线建立主从架构的功能，就可以实现了。 2. 服务器环境以及版本 系统： CentOS7.5 Mysql： 5.6.x 主端： 172.188.26.221 从端： 172.188.26.229 3. 配置准备 注意：主端不停服的前提是，它已经开启了bin-log 日志！！ 如果之前在主库没有开启 bin-log 日志，那就没有办法在新新建了，因为配置 bin-log 日志之后，主库一定要重启才能生效。不过，如果现在的情况是重做主库，那就证明之前是做过主从的，只是可能主从失效了需要重做。这种情况，主库也不需要重启，只要重新备份一下数据库，就可以重建从库了。 下面继续说说具体的主从新建过程。 在主库修改配置文件 my.cnf ，添加开启 bin-log 日志，格式用 row，注意

首先需要的环境：我在本地安装了两个MySQL，分别是5.7和5.5的版本：安装结束后如下： 1、复制原理： 原理： 在MySQL中有一种叫做bin的二进制日志，这个日志文件里面记录了关于此数据库的所有修改的sql语句（包括insert，update，delete，grant等等）。而主从复制就是利用这个二进制bin日志，在主库上创建一个用户，从数据库通过此用户去读取bin日志，然后再在从数据库上再执行一次。 2、主数据库配置文件修改： 我在改配置文件过程中碰到的一个问题就是：我的主数据库选择5.7版本，但是并没有my.ini这个文件，只有my-default.ini.如果你是安装在C盘，你还可能发现一个路径：C:\programData\mysql\my.ini，改这个就好了。 还有其他几个值可以配置： binlog-do-db=su #要同步的数据库名称,多个写多行，如果没配置，则所有都同步； binlog_format=mixed #日志混合 3、主数据库启动过程： cmd以管理员方式运行，然后输入命令：net start MySQL57（安装时自己取的名字），如下： 4、连接主数据库： 启动成功后，连接数据库命令：mysql -u root -p，如下： 这个命令如果环境变量没有配置的话，这个命令是没法用的。 5、为从数据库创建用户： 先可以看一下二进制日志文件的状态，命令为

7. MySQL分库分表 （1） 分库分表概念介绍   MySQL的分库分表有两种方式： 垂直拆分 和 水平拆分 。    垂直拆分 ：垂直拆分就是要 把表按模块划分到不同数据库表中 （当然原则还是不破坏第三范式），这种拆分在大型网站的演变过程中是很常见的。当一个网站还在很小的时候，只有小量的人来开发和维护，各模块和表都在一起，当网站不断丰富和壮大的时候，也会变成多个子系统来支撑，这时就有按模块和功能把表划分出来的需求。其实，相对于垂直切分更进一步的是服务化改造，说得简单就是要把原来强耦合的系统拆分成多个弱耦合的服务，通过服务间的调用来满足业务需求看，因此表拆出来后要通过服务的形式暴露出去，而不是直接调用不同模块的表。（垂直拆分用于分布式场景）    水平拆分 ：解决单表大数据量的问题，水平切分就是要把一个表按照某种规则把数据划分到不同表或数据库里。例如：在大型电商系统中，每天的会员人数不断的增加。达到一定瓶颈后如何优化查询。通过将表数据水平分割成不同的表来实现优化。（实现规则：hash、时间、不同的维度）    通俗理解：水平拆分行，行数据拆分到不同表中， 垂直拆分列，表数据拆分到不同表中。 （2） 水平分表的案例    分表原理： 取模拆分（一致性hash），可以将数据分配的比较均匀。 这里我们以3张表为例： 案例： 首先我创建三张表 user0 / user1 /user2

为什么备份： 灾难恢复：硬件故障（冗余）、软件故障（bug）、自然灾害、******、误操作、... 测试：测试时，为了模仿真实环境中用户访问情况，通常需要用真实数据去做测试。 备份恢复的原则： 策略正确：平时要设计好备份还原所涉及到的人员，确保能做正确的事。 执行不出问题：平时做演练，以确保出现问题时，能做正确的事情。 出问题时做正确的事情。 异地灾备 必要性：防止同一台机器、同一个网络环境中、同一个物理机房不可用导致服务不可用。 备份项：配置文件，周边配置，周期性计划任务。 备份注意事项： 能容忍最多丢失多少数据：决定了使用的备份手段和工具 恢复数据需要在多长时间内完成 电商站点若发生故障，数据恢复时，一小时损失可能数以亿计数据。若用二进制文件恢复，可能恢复时长极长，且可能因业务量大，单条语句写入二进制文件顺序不同导致数据与真实数据不一致。 需要恢复哪些数据 线上生产数据集，线上认证，配置等 数据备份后需要经常测试备份的可用性，另一方面也可以增强恢复操作的效率，在真正需要恢复数据时做到有条不紊。 数据备份的类型 根据备份的数据集的范围可分为完全备份和部分备份 完全备份：备份整个数据集 部分备份：备份整个数据集中的一部分，如部分表。 全量备份、增量备份、差异备份 全量备份：备份全部数据 增量备份：备份自上一次完全备份或增量备份以来变化的那部分数据 差异备份

各位兄弟们，时隔多日老张又与大家见面啦。每次与大家见面，都会有好消息告诉大家，这次也不例外。前段时间出版了《MySQL王者晋级之路》一书，反响还不错。争取今年再出版一本MongoDB运维实战的书籍，供给那些想要学习NoSQL的同学们作为工作中的参考。 现在正赶上世界杯，老张最喜欢的球队是葡萄牙——最爱C罗，喜欢他那种在比赛中好强不服输的精神。我们做技术也是一样，不要因为一点困难，就放弃了当初的梦想。只有不断努力，提升自己，才能在更好的平台上实现自我价值。 今儿，老张给大家介绍一款MySQL的一款中间件的产品——ProxySQL，它是灵活强大的MySQL代理层。像C罗一样的强大，可以实现读写分离，支持Query路由功能，支持动态指定某个SQL进行cache，支持动态加载配置、故障切换和一些SQL的过滤功能。还有一些同类产品比如DBproxy、MyCAT、OneProxy等。但经过反复对比和测试之后，决定给大家介绍一款性能不谙的MySQL中间件产品ProxySQL。 有关ProxySQL更多的详细信息可访问： https://github.com/sysown/proxysql/wiki 。 接下来通过实战来全面了解一下ProxySQL的特性和使用场景，先介绍一下环境，我们的系统是CentOS6.7，MySQL版本是5.7.14，准备一主两从架构来配合ProxySQL。 环境配置：