mysql集群

主从复制原理：在主数据库执行后，都会写入本地的日志系统A中。假设，实时的将变化了的日志系统中的数据库事件操作，在主数据库的3306端口，通过网络发给从数据。从数据库收到后，写入本地日志系统B，然后一条条的将数据库事件在数据库中完成。那么，主数据库的变化，从数据库也会变化，这样就是所谓的MYSQL的复制。 读写分离可以提高数据库的读写性能。 实验环境 iptables和selinux关闭 redhat6.5 主数据库 server2 172.25.12.2 从数据库 server3 172.25.12.3 实验所需的的rpm包 mysql-community-client-5.7.17-1.el6.x86_64.rpm mysql-community-common-5.7.17-1.el6.x86_64.rpm mysql-community-libs-5.7.17-1.el6.x86_64.rpm mysql-community-libs-compat-5.7.17-1.el6.x86_64.rpm mysql-community-server-5.7.17-1.el6.x86_64.rpm 1.数据库的配置 安装数据库 /etc/init.d/mysqld start 修改密码： grep password /var/log/mysqld.log 查看那数据库的临时密码 2017

在实际的生产环境中，如果对mysql数据库的读和写都在一台数据库服务器中操作，无论是在安全性、高可用性，还是高并发等各个方面都是不能满足实际需求的。因此，一般通过主从复制的方式来同步数据，再通过读写分离来提升数据库的并发负载能力。 Mysql主从复制和读写分离 l 主从复制： Mysql的主从复制和mysql的读写分离两者有紧密的联系，首先要部署主从复制，只有主从复制完成了，才能再此基础上进行数据的读写分离。 Mysql支持的复制类型： 1、 基于语句的复制：在主服务器上执行的sql语句，在从服务器上会执行同样的语句。Mysql默认采用基于语句的复制，效率比较高，但是有时不能实现精准复制。 2、 基于行的复制：把改变的内容复制过去，而不是把命令在从服务器上执行一遍。 3、 混合类型的复制：默认采用基于语句的复制，一旦发现基于语句的复制不能精准复制时，就会采用基于行的复制。 l 主从复制的过程： 1、 在每个事物更新数据完成之前，master在二进制日志记录这些改变，写入二进制日志完成后，master通知存储引擎提交事物。 2、 Slave将master的binary log复制到其中的中继日志。首先从mysql服务器开始一个工作线程I/O线程，I/O线程在master上打开一个普通的连接，然后开始binlog dump process。Binlog dump

目录 mysql主从复制和读写分离实战 mysql主从复制 Master配置 Slave1配置 Slave2配置 主从复制测试 mysql读写分离 mysql_proxy配置 读写分离测试 mysql主从复制和读写分离实战 一般情况下，mysql都是通过主从复制实现数据同步，再通过读写分离实现数据库高可用能力。当然主从复制和读写分离的作用不仅仅是这些。 这里提供了一个mysql主从复制和读写分离模型：(本次是一主二从模型) Master：172.25.254.7 slave1：172.25.254.8 slave2：172.25.254.9 mysql_proxy：172.25.254.10 所有服务都是在rhel7.0操作系统上运行， Java web app：是客户端请求，会对数据库发起读写操作请求，具体是发送SQL指令 Mysql Proxy：对读写操作请求的SQL指令进行路由，使得 读写分离 direct：一个负载分发引擎，对Mysql Proxy分发得读操作，按照一定得算法进行分发至后端得从服务器 master：主服务器，主要接受用户的写操作，并且负责将二进制日志同步给从服务器 slave-n：从服务器，主要负责用户的读操作(分担主服务器的读写压力)，并且负责重放master的写操作，还能实现容灾能力，保证高可用(如果主服务器挂掉，slvae顶上去) mysql主从复制

mysql5.7支持两种事务同步 主从复制有两种方式：基于日志（binlog）、基于 GTID（全局事务标示符）。本次采用基于日志（binlog）的方式。 在以前的mysql版本中，读写分离的实现一般都是基于日志的主从复制实现的，这样会产生一个问题，就是master宕机之后，slave由于同步延时的问题，会导致master和slave内容不同，甚至会多个slave之间互相不同。所以为了解决这个问题，再mysql5.7.6版本之后加入了基于GTID的事务控制，具体的说就是每个事务由一个唯一的gtid标识，当slave都成功执行之后master才写入硬盘完成该事务，如果master突然宕机，那么就自动回滚。数据的一致性得到保证。 操作方法和普通的基于日志的主从复制差不了很多，主要就是打开两个开关 enforce_gtid_consistency = ON gtid_mode = ON 那么就具体的介绍一下这种主从同步的搭建过程。 Master： 首先要修改mysql的配置文件，我这里的配置文件路径为/etc/mysql/mysql.conf.d/mysqld.cnf，基于docker，不同的版本位置可能会不一样，windows下多数都叫my.cnf，下载地址：https://hub.docker.com/r/alexzhuo/mysql/。 这里只截取要修改的那一段 修改前：

　　纠结了好久，还是花钱了3个4核8G的阿里云主机，且行且珍惜，下面正式进入CDH的搭建hadoop集群的过程。 　　下面安装过程比较长，所以一定要有耐心。 一、CDH介绍 　　以下是官网给的介绍：个人感觉就是对hadoop的继承环境的封装 二、为什么选择CDH？ 　　Cloudera 常年坚持季度发型update版本，年度发行Release版本，更新速度比Aapche官方快，而且在实际使用过程中CDH表现无比稳定。 　　CDH支持yum/apt包，tar包，rpm包，cloudera manager四种方式安装。可以获取最新特性和最新Bug修复，安装维护方便，节省运维时间。另外集群搭建更加方便。 　　• 版本划分清晰 　　 • 版本更新速度快 　　 • 支持Kerberos安全认证 　　 • 文档清晰 　　 • 支持多种安装方式（Cloudera Manager方式） 三、CDH的版本选择　　 　　CDH4.x--->4.8.6 　　CDH5.x ： 优选 5.4.8 5.8.0 5.12.0 不建议选择5.11.0,有坑 （ 这里我选用5.10.0 ） 四、安装准备 1.节点准备 　　由于是个人测试环境，所以购买了3台阿里云的主机，主要配置如下： 　　 2.节点规划 　　h adoop0 01 :mysql cm-server cm-agent Namenode

一.知识剖析: MHA（Master High Availability）目前在MySQL高可用方面是一个相对成熟的解决方案，它由日本DeNA公司youshimaton（现就职于 Facebook公司）开发，是一套优秀的作为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,要求一个复制集群中必须最少有三台数据库服务器，一主二从，即一台充当master，一台充当备用master，另外一台充当从库 注意： 1.需要奇数个结点 2.每一个节点都要安装master和master

[client] 1.登陆过程自动化（这样做可以让你在命令行登陆的时候免去输入用户名和密码） host="mysql服务器地址" user="用户名" password=“密码” 2.自动切换数据库（这样做可以避免每次进入都要use 某数据库） database="你的数据库名字" [mysqld] auto-rehash 启用TAB键自动补齐 skip-locking #避免MySQL的外部锁定，减少出错几率增强稳定性。 skip-name-resolve #禁止MySQL对外部连接进行DNS解析，使用这一选项可以消除MySQL进行DNS解析的时间。但需要注意，如果开启该选项，则所有远程主机连接授权都要使用IP地址方式，否则MySQL将无法正常处理连接请求！ back_log = 384 #back_log参数的值指出在MySQL暂时停止响应新请求之前的短时间内多少个请求可以被存在堆栈中。 如果系统在一个短时间内有很多连接，则需要增大该参数的值，该参数值指定到来的TCP/IP连接的侦听队列的大小。不同的操作系统在这个队列大小上有它自 己的限制。 试图设定back_log高于你的操作系统的限制将是无效的。默认值为50。对于Linux系统推荐设置为小于512的整数。 key_buffer_size = 384M #key_buffer_size指定用于索引的缓冲区大小

目录 一、MySQL InnoDB Cluster介绍 二、环境准备 三、将MGR节点加入MySQL Cluster 四、问题汇总 五、性能测试 六、个人总结 一、MySQL InnoDB Cluster介绍 MySQL InnoDB Cluster是MySQL官方推出完整的高可用性解决方案，MySQL InnoDB Cluster由三大组件组成： MySQL Shell ， MySQL Router ， MySQL Group Replication 。每个MySQL服务器实例都运行MySQL Group Replication，它提供了在InnoDB集群内复制数据的机制，具有内置故障转移功能。 MySQL Cluster的部署有两种方式，一种是直接部署MySQL InnoDB Cluster，一种是基于现有的MySQL Group Replication部署，本文采用基于现有的MySQL Group Replication部署 InnoDB Cluster不支持MySQL NDB Cluster 二、环境准备 主机名 IP地址 角色 oratest51 172.16.9.51 primary oratest52 172.16.9.52 seconde test61 172.16.9.61 seconde node4 172.16.8.68 MySQL Router 操作系统

数据库存储引擎 对于初学者来说我们通常不关注存储引擎，但是 MySQL 提供了多个存储引擎，包括处理事务安全表的引擎和处理非事务安全表的引擎。在 MySQL 中，不需要在整个服务器中使用同一种存储引擎，针对具体的要求，可以对每一个表使用不同的存储引擎。 存储引擎简介 MySQL中的数据用各种不同的技术存储在文件(或者内存)中。这些技术中的每一种技术都使用不同的存储机制、索引技巧、锁定水平并且最终提供广泛的不同的功能和能力。通过选择不同的技术，你能够获得额外的速度或者功能，从而改善你的应用的整体功能。 存储引擎说白了就是如何存储数据、如何为存储的数据建立索引和如何更新、查询数据等技术的实现方法。 例如，如果你在研究大量的临时数据，你也许需要使用内存存储引擎。内存存储引擎能够在内存中存储所有的表格数据。又或者，你也许需要一个支持事务处理的数据库(以确保事务处理不成功时数据的回退能力)。 InnoDB InnoDB是一个健壮的事务型存储引擎，这种存储引擎已经被很多互联网公司使用，为用户操作非常大的数据存储提供了一个强大的解决方案。我的电脑上安装的 MySQL 5.6.13 版，InnoDB就是作为默认的存储引擎。InnoDB还引入了行级锁定和外键约束，在以下场合下，使用InnoDB是最理想的选择： 更新密集的表。InnoDB存储引擎特别适合处理多重并发的更新请求。 事务

关系型数据库： 1、 以行和列的二维表格来表示的。 2、 通过结构化查询语句（SQL语句）查询的数据库。 3、 关系型数据库的代表作Oracle和MySQL 非关系型数据库：不仅仅是关系型数据库，对关系型数据库的补充。 WEB2.0时代：以用户为主体（大量的读写，高并发，数据一致性） Memcached： 纯内存的，特点快，数据会丢失。新浪基于memcached开发了一个开源的项目Mencachedb，通过为memcached增加Berkeley DB的持久化存储机制和异步复制机制，使Mencached具备事务恢复、持久化存储能力和分布式复制能力。 Redis： 数据存储在内存，定时刷新到磁盘上。 MongoDB: 基于关系型和非关系型之间的数据库。 MySQL数据库发布版本介绍： Alpha版 一般内部运行，不对外公开。主要是开发者自己对产品进行测试，检查产品是否存在缺陷、错误等 Beta 一般是完成功能开发和所有测试工作之后的产品，不会存在较大的功能或性能的BUG。并且邀请或者提供给用户进行体验与测试，以便更全面的测试软件的不足之处或存在的问题 RC 属于生产环境发布之前的一个小版本或称之为候选版，是根据beta版测试结果收集到的BUG和缺陷进行修复和完善后的一个版本。 GA 软件正式发布的产品，一般情况，企业生产环境都会选择GA版。 MySQL产品三条路线 第一条5.0