mysql主从配置

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的高可用集群：

1、搭建mysql服务器，并实现主主复制、半同步复制 存储引擎： 表类型：也称为“表类型”，表级别概念，不建议在同一个库中的表上使用不同的ENGINE； CREATE TABLE ... ENGINE[=]STORAGE_ENGINE_NAME ... SHOW TABLE STATUS 常见的存储引擎： MyISAM, Aria, InnoDB, MRG_MYISAM, CSV, BLACKHOLE, MEMORY, PERFORMANCE_SCHEMA, ARCHIVE, FEDERATED InnoDB：InnoBase Percona-XtraDB, Supports transactions, row-level locking, and foreign keys 数据存储于“表空间(table space)"中： (1) 所有数据库中的所有类型为InnoDB的表的数据和索引存储于同一个表空间中； 表空间文件：datadir定义的目录中 文件：ibdata1, ibdata2, ... (2) innodb_file_per_table=ON，意味着每表使用单独的表空间文件； 每表的数据文件（数据和索引，存储于数据库目录）存储于自己专用的表空间文件中，并存储于数据库目录下: tbl_name.ibd 表结构的定义：在数据库目录，tbl_name.frm 事务型存储引擎

环境： linux，mysql5.5.21 错误： Host is blocked because of many connection errors; unblock with 'mysqladmin flush-hosts' 原因： 　　同一个ip在短时间内产生太多（超过mysql数据库max_connection_errors的最大值）中断的数据库连接而导致的阻塞； 解决方法： 1、提高允许的max_connection_errors数量（治标不治本）： 　　① 进入Mysql数据库查看max_connection_errors： show variables like '%max_connection_errors%'; 　 ② 修改max_connection_errors的数量为1000： set global max_connect_errors = 1000; 　　③ 查看是否修改成功： show variables like '%max_connection_errors%'; 2、使用 mysqladmin flush-hosts 命令清理一下hosts文件（不知道mysqladmin在哪个目录下可以使用命令查找： whereis mysqladmin ）； 　　① 在查找到的目录下使用命令修改：/usr/bin/ mysqladmin flush-hosts

Mysql 数据库双机热备的配置方法 mysql数据库没有增量备份的机制，当数据量太大的时候备份是一个很大的问题。还好mysql数据库提供了一种主从备份的机制，其实就是把主数据库的所有的数据同时写到备份数据库中。 1。mysql数据库没有增量备份的机制，当数据量太大的时候备份是一个很大的问题。还好mysql数据库提供了一种主从备份的机制，其实就是把主数据库的所有的数据同时写到备份数据库中。实现mysql数据库的热备份。 2。要想实现双机的热备首先要了解主从数据库服务器的版本的需求。要实现热备mysql的版本都要高于3.2，还有一个基本的原则就是作为从数据库的数据库版本可以高于主服务器数据库的版本，但是不可以低于主服务器的数据库版本。 3。设置主数据库服务器： a.首先查看主服务器的版本是否是支持热备的版本。然后查看my.cnf(类unix)或者my.ini(windows)中mysqld配置块的配置有没有log-bin(记录数据库更改日志)，因为mysql的复制机制是基于日志的复制机制，所以主服务器一定要支持更改日志才行。然后设置要写入日志的数据库或者不要写入日志的数据库。这样只有您感兴趣的数据库的更改才写入到数据库的日志中。 server-id=1 //数据库的id这个应该默认是1就不用改动 log-bin=log_name //日志文件的名称，这里可以制定日志到别的目录

MySQL主从同步的作用 1、可以作为一种备份机制，相当于热备份 2、可以用来做读写分离，均衡数据库负载 MySQL主从同步的步骤 一、准备操作 1、主从数据库版本一致，建议版本5.5以上 2、主从数据库数据一致 二、主数据库master修改 1、修改MySQL配置：my.ini # 日志文件名 log-bin = mysql-bin # 主数据库端ID号 server-id = 1 2.重启mysql，创建用于同步的账户： cmd窗口连接mysql： # 创建slave帐号slave_account，密码123456 ，账号密码可自定义 mysql>grant replication slave on *.* to 'slave_account'@'%' identified by '123456'; # 更新数据库权限 mysql>flush privileges; 3.查询master的状态 mysql> show master status; +------------------+----------+--------------+------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | +------------------+----------+--------------+--

MySQL主从复制的类型 基于语句的复制（默认） 在主服务器上执行的语句，从服务器执行同样的语句 基于行的复制 把改变的内容复制到从服务器 混合类型的复制 一旦发现基于语句无法精确复制时，就会采用基于行的复制 主从复制的工作过程 MySQL读写分离原理 读写分离就是只在主服务器上写，只在从服务器上读 主数据库处理事务性查询，从而数据库处理select查询 数据库复制被用来把事务性查询导致的变更同步到集群中的从数据库 实验环境 amoeba服务器（192.168.142.160） master服务器（192.168.142.151） slave1服务器 （192.168.142.163） slave2服务器 （192.168.142.145） client客户端 （192.168.142.143） 1，在master服务器上安装ntp时间服务器 [root@ameoba ~]# yum install ntp -y ##安装时间服务器 [root@master1 ~]# vim /etc/ntp.conf ##在server下添加 server 127.127.13.0 ##本地是时间源 fudge 127.127.13.0 stratum 8 ##设置时间层级为8 [root@master1 ~]# systemctl start ntpd ##启动时间服务 [root

假设现有两个机房，需要做到数据同步。 以下是架构图（实际架构图根据现有机房架构和实际会比下图复杂，但整体思路不变）： Mycat、Canal、Otter是关键的三项技术： Mycat：数据库分库分表中间件，可以管理一个mysql集群，屏蔽了mysql集群，对外伪装成mysql server，用户无感知mysql集群。 Canal：阿里巴巴开源产品，可以读取mysql二进制日志文件，并解析成想要的数据。 Otter：阿里巴巴开源产品，配合Canal可以做到读取二进制文件，解析出增量数据sql，然后执行sql到指定连接。 流程： 1、用户插入一条数据到mycat 2、mycat解析sql，分配sql到指定mysql数据库 3、mysql（假设M1接收到数据）数据库接收数据，根据主从配置，写出二进制日志。 4、mysql（M2）读取二进制日志同步数据，mysql（S）读取二进制日志同步数据，并写出二进制日志 5、Canal读取二进制日志，解析成sql 6、Otter接到sql，获取连接，在机房B的mycat上执行sql 7、Otter收到sql执行回执，执行完毕。 注： 本文给予思路及具体技术方案，具体技术的应用及使用，请自行google。 来源： oschina 链接： https://my.oschina.net/u/2358114/blog/678100

MySQL多实例安装配置 什么是MySQL多实例？ 多实例就是在一台机器上开启多个不同服务端口，运行多个MySQL服务进程，这些服务通过进程通过不同饿socket监听不同的服务端口来提供各自的服务 这些MySQL多实例是公用一套MySQL安装程序，使用不同的my.conf配置文件，启动文件，数据文件。在提供服务同时，多实例MySQL在逻辑上看来就是各自独立的。但是他们是公用资源，所以会有影响。 多实例的作用与问题 1、 有效的利用服务器资源 当单个服务器资源有剩余时，可以充分利用剩余资源提供更多服务。 2、 节约服务器资源 当资金紧张但是数据库又需要各自尽量独立提供给服务，而且需要主从同步等技术时，多实例就很适合 3、 资源互相抢占问题 当某个服务实例并发很高或者有慢查询时，整个实例就会消耗更多的内存、CPU、磁盘io资源，导致服务器上其他实例提供服务的质量下降。这就相当于大家住在一个房子里，做一件事，其他人就需要等待 MySQL配置方案 多配置文件部署方案 通过配置多个配置文件及多个启动程序来实现多实例的方案； 以端口形式划分，3306，3307端口创建实例目录，每个目录下都有各自的实例的数据文件（data），实例的配置文件（my.conf），实例的启动文件（mysql） 单一配置文件部署方案 mysqld_multi 缺点，耦合性太高 安装多实例的数据库

一、MHA 简介 MHA（Master High Availability）目前在 MySQL 高可用方面是一个相对成熟的解决方案， 是一套优秀的作为 MySQL 高可用性环境下故障切换和主从角色提升的高可用软件。在 MySQL 故障切换过程中，MHA 能做到在 0~30 秒之内自动完成数据库的主从故障切换操作，并且在进行故障切换的过程中，MHA 能在最大程度上保证数据的一致性，以达到真正意义上的高可用。 MHA 由两部分组成：MHA Manager（管理节点）和 MHA Node（数据节点）。MHA Manager可以单独部署在一台独立的机器上管理多个 master-slave 集群，也可以部署在一台 slave 节点上。MHA Node 运行在每台 MySQL 服务器及 Manager 服务器上，MHA Manager 会定时探测集群中的 master 节点，当 master 出现故障时，它可以自动将拥有最新数据的 slave 提升为新的 master，然后将所有其他的 slave 重新指向新提升的 master。整个故障转移过程对应用程序层面完全透明。 在 MHA 自动故障切换过程中，MHA 会试图从宕机的主服务器上保存二进制日志，最大程度的保证数据不丢失，但这种操作是有概率性的。MHA 可以与半同步复制结合起来。如果只有一个 slave 已经收到了最新的二进制日志，MHA

Hello everyone! 今天介绍一下 Linux 下如何实现主从同步 读写分离 <master上进行写操作，同步数据库，slave上进行读操作，可以极大的提升性能> ok-----begin 首先前提工作是 准备两台虚拟机(centos7) 同时两台虚拟机上必须装有相同版本的 MySQL 主 master ip:172.16.65.22 从 slave ip:172.16.65.21 两台机子都可以互相ping同 / 关闭防火墙 然后开始写配置文件 寻找自己的路径 vim /etc/my.cnf 编辑 添加配置如图 找不见的话 执行 whereis my.cnf 各项工作准备完毕后 在master上创建一个同步权限的账户 用来同步数据 创建新用户create user 'user'@'X.X.X.X' identified by 'password'; 这条是编辑新密码 update user set authentication_string=PASSWORD('密码') where user='用户名';查看主库状态 　show master status; mysql> show master status; +------------------+----------+--------------+------------------+---------------