mysql集群

一、Mysql 各个版本区别： 1、 MySQL Community Server 社区版本 ，开源免费，但不提供官方技术支持。 2、 MySQL Enterprise Edition 企业版本 ，需付费，可以试用30天。 3、 MySQL Cluster 集群版 ，开源免费。可将几个MySQL Server封装成一个Server。 4、 MySQL Cluster CGE 高级集群版 ，需付费。 5、 MySQL Workbench （GUI TOOL）一款专为MySQL设计的 ER/ 数据库 建模工具 。它是著名的 数据库设计 工具DBDesigner4的继任者。MySQL Workbench又分为两个版本，分别是社区版（MySQL Workbench OSS）、商用版（MySQL Workbench SE）。 MySQL Community Server 是开源免费的，这也是我们通常用的MySQL的版本。根据不同的操作系统平台细分为多个版本， 二、本文以下载 tar.gz 版本为例演示下载过程： 我们选择GenerallyAvailable（GA）Release 去下载。GA 是指软件的通用版本，一般指正式发布的版本。 Mysql 官网地址： http://www.mysql.com/ 选择 Downloads-->Community-->Mysql Community

博文大纲： 一、PXC介绍 二、部署PXC集群 一、PXC介绍 参考： Percona官方 PXC是一个开源的MySQL高可用解决方案，它将Percona Server和Xtrabackup与Galera库集成，以实现同步多主复制。基于Galera的高可用方案主要有MariaDB Galera Cluster（MGC）和Percona XtraDB Cluster（PXC），目前PXC架构在生产环境中用的更多而且更成熟些，PXC相比那些传统的基于主从模式的集群架构MHA和双主，PXC最突出的特点就是解决了诟病已久的复制延迟问题，基本上可以达到实时同步。而且节点与节点之间，它们互相的关系是对等的。本身Galera Cluster也是一种多主架构。PXC是在存储引擎层实现的同步复制，而非异步复制，所以其数据的一致性是相当高的。 其工作原理如下： 要搭建PXC架构至少需要三台MySQL实例来组成一个集群，三个实例之间不是主从模式，而是各自为主，所以三者之间的关系是对等的，不分主从，这也叫multi-master架构，客户端读写时，连接哪个实例都是一样的，读取到的数据是相同的，写入任意一个实例后，集群会将自己新写入的数据同步到其他实例上，这种架构不共享任何数据，是一种高冗余的MySQL集群架构。 1、PXC优缺点 优点： 实现了MySQL集群的高可用性和数据的强一致性。

集群介绍： Galera是一个MySQL(也支持MariaDB，Percona)的同步多主集群软件，目前只支持InnoDB引擎。 主要功能： 同步复制 真正的multi-master，即所有节点可以同时读写数据库 自动的节点成员控制，失效节点自动被清除 新节点加入数据自动复制 真正的并行复制，行级 用户可以直接连接集群，使用感受上与MySQL完全一致 优势: 因为是多主，所以不存在Slave lag(延迟) 不存在丢失交易的情况 同时具有读和写的扩展能力 更小的客户端延迟 节点间数据是同步的,而Master/Slave模式是异步的,不同slave上的binlog可能是不同的 实现技术: Galera集群的复制功能基于Galera library实现,为了让MySQL与Galera library通讯，特别针对MySQL开发了wsrep API。 实践操作：负载均衡集群搭建 1 .下载mariadb集群 wget http://mirrors.opencas.cn/mariadb/mariadb-galera-10.0.17/bintar-linux-x86_64/mariadb-galera-10.0.17-linux-x86_64.tar.gz 2. 添加mariadb用户和组 groupadd mariadb useradd -g mariadb mariadb 3.

MySQL中的查询语句执行分析 select * from T where id =1; 基本架构 示意图 客户端 连接器 查询缓存 分析器 优化器 执行器 存储引擎 存储引擎 存储引擎 MySQL大致可以分为Server层和存储引擎层 Server层包括：连接器、查询缓存、分析器、优化器、执行器等，Server层是通用的，可以配合不同的存储引擎使用。 存储引擎层负责数据的存储和提取，其支持：InnoDB(默认的存储引擎)、MyISAM、Memory等多个存储引擎。 连接器 负责客户端和服务端的连接，验证用户名和密码，获取拥有的权限信息，如果在获取连接之后做出权限变更，对于未关闭的连接，是感知不到权限的变化的。 连接关闭时间由参数 wait_timeout 控制，默认值是8小时。 连接分为短连接和长连接，区别在于，长连接存活时间比较长，可以供更多的查询使用，而短连接经过几次查询就会断开了，下次查询需要重新获取连接。 由于建立连接的过程比较耗时，建议使用长连接，但是过多的使用长连接会导致内存占用会变大。两个解决问题的办法： 定期断开长连接释放内存资源. 执行mysql_reset_connection来重新初始化连接资源，使其恢复到刚刚创建完连接的状态，且不需要重新连接和权限验证等。 查询缓存 MySQL在拿到一个查询语句后，首先会查询缓存中是否存在之前执行过的同样的sql

原文: Docker实战之MySQL主从复制 前言 曾几何时，看着高大上的架构和各位前辈高超的炫技，有没有怦然心动，也想一窥究竟？每当面试的时候，拿着单应用的架构，吹着分库分表的牛X，有没有心里慌的一批？ 其实很多时候，我们所缺少的只是对高大上的技术的演练。没有相关的业务需求，没有集群环境，然后便只是Google几篇博文，看下原理，便算是了解了。然而真的明白了吗？众多的复制粘贴中，那篇文章才对我们有用，哪些又是以讹传讹？ 所幸容器技术的快速发展，让各种技术的模拟成为现实。接下来Docker相关的一系列文章，将以实战为主，帮助大家快速搭建测试和演练环境。 Docker文件编排 由于是测试为了演练用，这里用docker-compose进行配置文件的编排，实际的集群环境中并不是这么部署的。 编排docker-compose-mysql-cluster.yml,安装master和slave节点 version: '3' services: mysql-master: image: mysql:5.7 container_name: mysql-master environment: - MYSQL_ROOT_PASSWORD=root ports: - "3307:3306" volumes: - "./mysql/master/my.cnf:/etc/my.cnf" - "./mysql

前言 曾几何时，看着高大上的架构和各位前辈高超的炫技，有没有怦然心动，也想一窥究竟？每当面试的时候，拿着单应用的架构，吹着分库分表的牛X，有没有心里慌的一批？ 其实很多时候，我们所缺少的只是对高大上的技术的演练。没有相关的业务需求，没有集群环境，然后便只是Google几篇博文，看下原理，便算是了解了。然而真的明白了吗？众多的复制粘贴中，那篇文章才对我们有用，哪些又是以讹传讹？ 所幸容器技术的快速发展，让各种技术的模拟成为现实。接下来Docker相关的一系列文章，将以实战为主，帮助大家快速搭建测试和演练环境。 Docker文件编排 由于是测试为了演练用，这里用docker-compose进行配置文件的编排，实际的集群环境中并不是这么部署的。 编排docker-compose-mysql-cluster.yml,安装master和slave节点 version: '3' services: mysql-master: image: mysql:5.7 container_name: mysql-master environment: - MYSQL_ROOT_PASSWORD=root ports: - "3307:3306" volumes: - "./mysql/master/my.cnf:/etc/my.cnf" - "./mysql/master/data:/var/lib

在上一篇文章中描述了MySQL HA on Azured 设计思路，本篇文章中将描述具体的部署，每个组件的安装和配置。 整体的设计架构如下： 下面将是所有组件的安装配置过程，所有的虚拟机是CentOS 6.5的操作系统。Azure上虚拟机的新建、Vnet的配置等本文就不再涉及。如有需要，请参考张磊同学的博客： http://www.cnblogs.com/threestone 配置Azure Internal Load Balance及添加硬盘 本文采用Xplate CLI部署Internal Load balancer，其地址为静态的10.1.1.200，Distribution模式采用sourceIP。 首先创建ILB： azure service internal-load-balancer add -a 10.1.1.200 -t Subnet-2 mysql-ha mysql-ha-ilb info: service internal-load-balancer add command OK 创建Endpoint和LoadBalanceSet azure vm endpoint create -n mysql -o tcp -t 3306 -r tcp -b mysql-ha-lbs -i mysql-ha-ilb -a sourceIP mysql-ha1 3306

FLUSH TABLES WITH READ LOCK简称(FTWRL)，该命令主要用于备份工具获取一致性备份(数据与binlog位点匹配)。 由于FTWRL总共需要持有两把全局的MDL锁，并且还需要关闭所有表对象，因此这个命令的杀伤性很大，执行命令时容易导致库hang住。如果是主库，则业务无法正常访问；如果是备库，则会导致SQL线程卡住，主备延迟。本文将详细介绍FTWRL到底做了什么操作，每个操作的对库的影响，以及操作背后的原因。 FTWRL做了什么操作？ FTWRL主要包括3个步骤： 1.上全局读锁(lock_global_read_lock) 2.清理表缓存(close_cached_tables) 3.上全局COMMIT锁(make_global_read_lock_block_commit) FTWRL每个操作的影响 上全局读锁会导致所有更新操作都会被堵塞；关闭表过程中，如果有大查询导致关闭表等待，那么所有访问这个表的查询和更新都需要等待；上全局COMMIT锁时，会堵塞活跃事务提交。由于FTWRL主要被备份工具使用，后面会详细解释每个步骤的作用，以及存在的必要性。FTWRL中的第1和第3步都是通过MDL锁实现，关于MDL的实现，我之前总结了 MDL锁的文章 ，这里主要介绍清理表缓存的流程。 清理表缓存 每个表在内存中都有一个table_cache

MySQL-cluster 架构，节点，节点作用 原理： SQL 节点： 给上层应用层提供 sql 访问。 管理节点（ MGM ）： 管理整个集群。 启动，关闭集群。 通过 ndb_mgmd 命令启动集群 存储 / 数据节点： 保存 cluster 中的数据。 数据节点，可以提供副本。实现数据冗余。 NDB 引擎：是一种 “ 内存中 ” 的存储引擎 ， 它具有可用性高和数据一致性好的特点。 NDB 引擎 MySQL Cluster 使用了一个 专用的基于内存的存储引擎 ——NDB 引擎，这样做的好处是速度快， 没有磁盘 I/O 的瓶颈， 但是由于是基于内存的，所以数据库的规模受系统总内存的限制， 如果运行 NDB 的 MySQL 服务器一定要内存够大，比如 4G, 8G, 甚至 16G 。 NDB 引擎是分布式的，它可以配置在多台服务器上来实现数据的可靠性和扩展性， 理论上 通过配置 2 台 NDB 的存储节点就能实现整个数据库集群的冗余性和解决单点故障问题。 小结：共三层节点 1． 管理节点（ MGM ，对内管理存储节点） 2． 存储节点（ NDB 存储引擎，对接管理节点和 SQL 节点，用于存储数据） 3．SQL 节点（对外接口 API ） 优缺点 优点 1． 高吞吐量和低延迟，使用 NDB 存储引擎（基于内存），存储数据速度快，没有 IO 瓶颈 2．灵活的分布式体系架构

前言 工作的这些年发现一个比较奇怪的现象就是身边无论是工作十多年的老兵，还是初级刚入行的程序员，在高谈阔论技术和趋势的时候都是人工智能，大数据，区块链，各种框架，语言，算法，AI，BI，CI，DI…… 等等，倒是发现很少有人关注数据库，不知道是因为数据库感觉太低端还是太低调，总是不容易被人提起 技术就是这样，不太关注的地方就不会重视，越是不被重视的地方，掉进坑里的概率就会越大，所以就在这里给大家简单聊聊在使用数据库过程中有哪些防掉坑指南，也可以对刚入行的小朋友有一个提醒的作用，万丈高楼平地起，一定要先打好基础再去考虑上层的建筑，不要舍本逐末 本章主要分以下四个小节（预计读完 5 分钟左右）： 数据库为什么重要 数据库有哪些使用技巧 数据库有哪些容易掉进去的坑？ 深入学习数据库的建议 数据库为什么重要 很多人在开发过程中不太关注数据库，对于表结构的设计也没什么讲究大多属于“能用就行”，但是根据作者将近十年的开发经验来看的话，只要你是从事 Web 相关领域开发你就无法避免不和数据库打交道， 在Web开发中大多功能操作本质上都是对数据库进行操作 ，不管你用是 Pythod，Java，Ruby 等语言进行 Web 开发，你其实都是在面向数据库进行编程，很多 Web 框架作者为了避免程序员接触数据库的相关知识甚至还封装了一层 ORM （Object Relational Mapping