mysql集群

3 月，跳不动了？>>> 虽然知道处理大数据量时，数据库要做读写分离，但是为什么读写分离可以提高性能呢？ 下面是搜来的一些解释，看看再说！ 一 什么是读写分离 MySQL Proxy最强大的一项功能是实现“读写分离(Read/Write Splitting)”。基本的原理是让主数据库处理事务性查询，而从数据库处理SELECT查询。数据库复制被用来把事务性查询导致的变更同步到集群中 的从数据库。 当然，主服务器也可以提供查询服务。使用读写分离最大的作用无非是环境服务器压力。可以看下这张图： 二 读写分离的好处 1.增加冗余 2.增加了机器的处理能力 3.对于读操作为主的应用，使用读写分离是最好的场景，因为可以确保写的服务器压力更小，而读又可以接受点时间上的延迟。 三 读写分离提高性能之原因 1.物理服务器增加，负荷增加 2.主从只负责各自的写和读，极大程度的缓解X锁和S锁争用 3.从库可配置myisam引擎，提升查询性能以及节约系统开销 4.从库同步主库的数据和主库直接写还是有区别的，通过主库发送来的binlog恢复数据，但是，最重要区别在于主库向从库发送binlog是异步的，从库恢复数据也是异步的 5.读写分离适用与读远大于写的场景，如果只有一台服务器，当select很多时，update和delete会被这些select访问中的数据堵塞，等待select结束，并发性能不高。

写在前面：最早接触的MySQL是在三年前，那时候MySQL还是4.x版本，很多功能都不支持，比如，存储过程，视图，触发器，更别说分布式事务等复杂特性了。但从5.0(2005年10月)开始，MySQL渐渐步入企业级数据库的行列了；复制、集群、分区、分布式事务，这些企业级的特性，使得现在的MySQL，完全可以应用于企业级应用环境(很多互联网公司都用其作为数据库服务器，尽管节约成本是一个因素，但是没有强大功能作后盾，则是不可想象的)。虽然，MySQL还有很多不足，比如，复制、分区的支持都十分有限、查询优化仍需要改进，但是MySQL已经是一个足够好的DBMS了，更何况它是opensource的。这段时间没有事，出于好奇，略微的研究了一下MySQL，积累了一些资料，欲总结出来。这些资料打算分为两部分，上部主要讨论MySQL的优化，其中主要参考了《MySQL Manual》和《High Performance MySQL》，如果有时间，以后在下部分析一下MySQL的源码。如果你是MySQL高手，希望你不吝赐教；如果你是新手，希望对你有用。 第一章、MySQL架构与概念 1、MySQL的逻辑架构 最上面不是MySQL特有的，所有基于网络的C/S的网络应用程序都应该包括连接处理、认证、安全管理等。 中间层是MySQL的核心，包括查询解析、分析、优化和缓存等。同时它还提供跨存储引擎的功能

1，MHA概述 MHA目前在mysql高可用方面是一个相对成熟的解决方案，它由日本DeNA公司youshimaton（现就职于Facebook公司）开发，是一套优秀的作为mysql高可用性环境下故障切换和主从提升的高可用软件。在mysql故障切换过程中，MHA能做到在0-30秒之内自动完成数据库的故障切换操作，并且在进行故障切换操作的过程中，MHA能在最大程度上保证数据的一致性，以达到真正意义上的高可用，MHA里由两个角色一个是MHA Node（数据节点），另一个是MHA Manager（管理节点）。MHA Manager可以单独部署在一台读立的服务器上管理多个master-slave集群，也可以部署在一台slave节点上。 MHA Node运行在每台mysql服务器上，MHA Manager会定时探测集群中的master节点，当master出现故障时，它可以自动将最新数据的slave提升为新的master，然后将所有其他的slave重新指向新的master。整个故障转移过程中对应用程序完全透明。 在MHA自动故障切换过程中，MHA试图从宕机的主服务器上保存二进制日志，最大程度地保证数据的不丢失，但这并不总是可行的。例如，如果主服务器硬件故障或无法通过ssh访问，MHA没法保存二进制日志，只进行故障转移而丢失了最新的数据。使用mysql 5.5的半同步复制

1、准备 下载mysql-cluster-gpl-7.6.13-el7-x86_64.tar.gz，下载地址 https://dev.mysql.com/downloads/cluster/7.6.html 。 准备3台Linux主机， 保证防火墙对1181和3306端口例外 。 主机名 IP地址 作用 172.16.43.142 管理节点 172.16.43.148 数据节点、SQL节点 172.16.43.149 数据节点、SQL节点 2、安装管理节点（Management Node） 1）创建文件/var/lib/mysql-cluster/config.ini mkdir /var/lib/mysql-cluster vi /var/lib/config.ini 文件内容为（配置说明见： https://dev.mysql.com/doc/refman/5.7/en/mysql-cluster-install-configuration.html ）： [ndbd default] NoOfReplicas=2 [ndb_mgmd] NodeId=1 HostName=172.16.43.142 DataDir=/var/lib/mysql-cluster [ndbd] NodeId=2 HostName=172.16.43.148 DataDir=/var/mysql

【问题】 有台MySQL 5.6.21的数据库实例以写入为主，IO %util接近100% 写入IOPS很高 【分析过程】 1、通过iotop工具可以看到当前IO消耗最高的mysql线程 2、查看线程49342的堆栈，可以看到正在进行redo log的刷新，对应的是9号文件 3、9号文件对应的是redo log的第一个文件 为什么mysql进程会频繁的刷新redo log文件，要结合redolog的刷盘策略来分析，关键是innodb_flush_log_at_trx_commit参数， 默认是1，最安全，但在写压力大的情况下，也会带来较大的性能影响，每次事务提交时MySQL都会把log buffer的数据写入log file，并且flush(刷到磁盘)中去。 结合这个集群的写入场景来看，大部分都是小事务的写入，每次事务提交都会触发刷盘动作，这种场景下通过增大innodb_log_buffer_size和innodb_log_file_size的优化效果不明显 【优化方案】 1、应用层面，对于写压力大的系统，可以将单条的insert语句优化为小批量的insert语句，这样事务commit的次数减少，redo log刷盘减少，性能理论上会有提升 2、MySQL层面，对于日志类型的系统，如果允许宕机的情况下少量数据丢失，可以将innodb_flush_log_at_trx

前言：前面介绍了Java、JVM相关方面的题目，该篇介绍数据库方面相关的题目，这里数据库为MySql，因为笔者或朋友在面试过程中都是涉及MySql的相关知识点。 数据库篇 在数据库题目中，由于现在大部分公司都是使用MySql作为数据库，因此笔者及其朋友所遇到的问题也都是MySql相关的知识点。 1）MySql中索引的基本定义，优劣势，以及索引优化。 索引是帮助Mysql高效获取数据的 数据结构 ，因此，索引的 本质 就是数据结构，索引的目的在于提高 查询 效率，可类比字典。 索引： 排好序的快速查找的数据结构。 用途： 排序 + 快速查找 。注意，是两种功能。 数据库除了存储数据本身之外，还维护着一个满足特定查找算法的数据结构，这些数据结构以某种方式指向数据，这样就可以在这些数据结构的基础上实现高级查找算法，这种 数据结构 就是索引。 MySql索引通常是指 B+树 索引。 索引优势： 类似书籍的目录，提高数据检索的效率，降低数据库的 IO 成本（因为数据最终是存储在 磁盘 上的）。 通过索引列对数据进行排序，降低数据排序的成本，降低了 CPU 的消耗（因为排好序，查询速度增加）。 索引劣势： 索引也是 一张表 ，保存了主键与索引字段，并指向实体表的记录，所以索引列也是要 占用磁盘空间的 。 虽然提高了 查询速度 ，但是会 降低更新速度（因为数据更新后，需要重新对索引排序） ，如

PolarDB是阿里云基于MySQL推出的云原生数据库（Cloud Native Database）产品，通过将数据库中计算和存储分离，多个计算节点访问同一份存储数据的方式来解决目前MySQL数据库存在的运维和扩展性问题；通过引入RDMA和SPDK等新硬件来改造传统的网络和IO协议栈来极大提升数据库性能。代表了未来数据库发展的一个方向。本系列共2篇文章，主要分析为什么会出现PolarDB以及其技术实现。 由于PolarDB并不开源，因此只能基于阿里云公开的技术资料进行解读。这些资料包括从去年下半年开始陆续在阿里云栖社区、云栖大会等场合发布的PolarDB相关资料，以及今年以来公开的PolarDB后端共享存储PolarFS相关文章。 PolarDB出现背景 MySQL云服务遇到的问题 首先来了解下为什么会出现PolarDB。阿里云数据库团队具备国内领先的技术能力，为MySQL等数据库在国内的推广起到了很大的作用。在阿里云上也维护了非常庞大的MySQL云服务（RDS）集群，但也遇到了很多棘手的问题。举例如下： 实例数据量太大，单实例几个TB的数据，这样即使使用xtrabackup物理备份，也需要很长的备份时间，且备份期间写入量大的话可能导致redo日志被覆盖引起备份失败； 大实例故障恢复需要重建时，耗时太长，影响服务可用性（此时存活节点也挂了，那么完蛋了）。时间长有2个原因

写在前面：最早接触的MySQL是在三年前，那时候MySQL还是4.x版本，很多功能都不支持，比如，存储过程，视图，触发器，更别说分布式事务等复杂特性了。但从5.0(2005年10月)开始，MySQL渐渐步入企业级数据库的行列了；复制、集群、分区、分布式事务，这些企业级的特性，使得现在的MySQL，完全可以应用于企业级应用环境(很多互联网公司都用其作为数据库服务器，尽管节约成本是一个因素，但是没有强大功能作后盾，则是不可想象的)。虽然，MySQL还有很多不足，比如，复制、分区的支持都十分有限、查询优化仍需要改进，但是MySQL已经是一个足够好的DBMS了，更何况它是opensource的。这段时间没有事，出于好奇，略微的研究了一下MySQL，积累了一些资料，欲总结出来。这些资料打算分为两部分，上部主要讨论MySQL的优化，其中主要参考了《MySQL Manual》和《High Performance MySQL》，如果有时间，以后在下部分析一下MySQL的源码。如果你是MySQL高手，希望你不吝赐教；如果你是新手，希望对你有用。 第一章、MySQL架构与概念 1、MySQL的逻辑架构 最上面不是MySQL特有的，所有基于网络的C/S的网络应用程序都应该包括连接处理、认证、安全管理等。 中间层是MySQL的核心，包括查询解析、分析、优化和缓存等。同时它还提供跨存储引擎的功能

# Mysql数据库表引擎与字符集  ### 1.服务器处理客户端请求 其实不论客户端进程和服务器进程是采用哪种方式进行通信，最后实现的效果都是：**客户端进程向服务器进程发送一段文本（MySQL语句），服务器进程处理后再向客户端进程发送一段文本（处理结果）。**那服务器进程对客户端进程发送的请求做了什么处理，才能产生最后的处理结果呢？客户端可以向服务器发送增删改查各类请求，我们这里以比较复杂的查询请求为例来画个图展示一下大致的过程：  > 虽然查询缓存有时可以提升系统性能，但也不得不因维护这块缓存而造成一些开销，比如每次都要去查询缓存中检索，查询请求处理完需要更新查询缓存，维护该查询缓存对应的内存区域。从MySQL 5.7.20开始，不推荐使用查询缓存，并在MySQL 8.0中删除。 ### 2.存储引擎 `MySQL`服务器把数据的存储和提取操作都封装到了一个叫`存储引擎`的模块里。我们知道`表`是由一行一行的记录组成的，但这只是一个逻辑上的概念，物理上如何表示记录，怎么从表中读取数据，怎么把数据写入具体的物理存储器上，这都是`存储引擎`负责的事情。为了实现不同的功能，`MySQL`提供了各式各样的`存储引擎`

Galera Cluster简介 Galera Cluster是集成了Galera插件的MySQL集群，是一种新型的，数据不共享的，高度冗余的高可用方案，目前Galera Cluster有两个版本，分别是Percona Xtradb Cluster和MariaDB Cluster，Galera本时是具有多主特性，即采用Multi-master的集群架构，是一个即稳健，又在数据一致性、完整性及高性能方面有出色表现的高可用解决方案 Galera Cluster内部机制 Galera Cluster种每个MySQLServer之间相互为主主的关系，当客户端发送指令到一个数据库时，数据库将数据修改后返回一个OK，表示用户的请求已经被收到，但是事务并没有结束依旧可以撤销。当事务结束时用户发送一个commit(提交)，服务器收到后会将数据的更新发送给其他的MySQLServer，此时会开启一个全局性的事务ID给组内的其他服务器，其他服务器会查看是否有事务冲突，如果没有冲突就确认更改成功。 Galera Cluster特点 多主架构：真正的多点读写的集群，在任何时候读写数据都是最新的 同步复制：集群不同节点之间数据同步，没有延迟，在数据库挂掉之后，数据不会丢失 并发复制：从节点APPLY数据时，支持并行执行有更好的性能。 故障切换：数据库故障时，因为支持多点写入，切换容易 热插拔：在服务期间