mysql主从复制 分库 分区 分表

MySql主从复制流程

转载：http://www.cnblogs.com/nulige/p/6034301.html

MySQL的主从复制是MySQL本身自带的一个功能，不需要额外的第三方软件就可以实现，其复制功能并不是copy文件来实现的，而是借助binlog日志文件里面的SQL命令实现的主从复制，可以理解为我再Master端执行了一条SQL命令，那么在Salve端同样会执行一遍，从而达到主从复制的效果。

binlog的格式：

statement:记录的是修改SQL语句
row：记录的是每行实际数据的变更
mixed：statement和row模式的混合

5.0后默认是row格式，所以应该是传给slave每行数据的变更。

复制过程有一个很重要的限制——复制在slave上是串行化的，也就是说master上的并行更新操作不能在slave上并行操作。

MySQL的主从复制是一个异步的复制过程，数据库从一个Master复制到Slave数据库，在Master与Slave之间实现整个主从复制的过程是由三个线程参与完成的，其中有两个线程(SQL线程和IO线程)在Slave端，另一个线程(IO线程)在Master端。

MySQL主从复制之前我们需要先启动Master数据库然后再启动Salve数据库，然后在Salve数据库中执行start slave;，执行完成之后，流程就如下了：

1. Salve的IO线程会读取mastr.info文件中配置好的主库信息，比如说存放的有：Master数据库的用户名、密码、端口、还有Master的binlog索引位置；
2. 拿到信息之后就带着信息去链接Master的主库IO线程
3. 当主库的IO线程先检查SLave传过来的配置信息是否正确，如果正确，就拿着Slave传过来的binlog索引位置和Master库的binlog文件中最后一个索引位置进行对比，如果一致就陷入等待状态，等待Master的binlog索引位置更新；
4. 如果不一致就把Slave传过来的binlog索引位置往后的所有SQL语句包括最后一条SQL语句的索引位置发送个给Slave的IO线程；
5. Slave的IO线程拿到信息之后，先把Master传过来的binlog索引在Slave的master.info文件中进行更新；
6. 然后再把Master传过来的SQL语句写入到relay文件中，然后继续循环执行第二个步骤；
7. Slave的SQL线程会一直持续的观察relay日志文件中是否有改动，如果没有就继续监听；
8. 如果发现relay中有变动，那么就获取变动的内容转换为SQL语句，并且把SQL语句在Salve的数据库中进行执行

分区 分表 分库

转载：https://blog.csdn.net/qq_28289405/article/details/80576614

https://blog.csdn.net/kingcat666/article/details/78324678

1.分区的概念

数据分区是一种物理数据库的设计技术，它的目的是为了在特定的SQL操作中减少数据读写的总量以缩减响应时间。

        分区并不是生成新的数据表，而是将表的数据均衡分摊到不同的硬盘，系统或是不同服务器存储介子中，实际上还是一张表。另外，分区可以做到将表的数据均衡到不同的地方，提高数据检索的效率，降低数据库的频繁IO压力值，分区的优点如下：

1、相对于单个文件系统或是硬盘，分区可以存储更多的数据；

2、数据管理比较方便，比如要清理或废弃某年的数据，就可以直接删除该日期的分区数据即可；

3、精准定位分区查询数据，不需要全表扫描查询，大大提高数据检索效率；

4、可跨多个分区磁盘查询，来提高查询的吞吐量；

5、在涉及聚合函数查询时，可以很容易进行数据的合并；

2.分区的分类

1.水平分区
这种形式分区是对表的行进行分区，通过这样的方式不同分组里面的物理列分割的数据集得以组合，从而进行个体分割（单分区）或集体分割（1个或多个分区）。所有在表中定义的列在每个数据集中都能找到，所以表的特性依然得以保持。
举个简单例子：一个包含十年发票记录的表可以被分区为十个不同的分区，每个分区包含的是其中一年的记录。（朋奕注：这里具体使用的分区方式我们后面再说，可以先说一点，一定要通过某个属性列来分割，譬如这里使用的列就是年份）
2.垂直分区
这种分区方式一般来说是通过对表的垂直划分来减少目标表的宽度，使某些特定的列被划分到特定的分区，每个分区都包含了其中的列所对应的行。
举个简单例子：一个包含了大text和BLOB列的表，这些text和BLOB列又不经常被访问，这时候就要把这些不经常使用的text和BLOB了划分到另一个分区，在保证它们数据相关性的同时还能提高访问速度。
在数据库供应商开始在他们的数据库引擎中建立分区（主要是水平分区）时，DBA和建模者必须设计好表的物理分区结构，不要保存冗余的数据（不同表中同时都包含父表中的数据）或相互联结成一个逻辑父对象（通常是视图）。这种做法会使水平分区的大部分功能失效，有时候也会对垂直分区产生影响。

3.分区、分表、分库理解

分区

就是把一张表的数据分成N个区块，在逻辑上看最终只是一张表，但底层是由N个物理区块组成的

分表

就是把一张表按一定的规则分解成N个具有独立存储空间的实体表。系统读写时需要根据定义好的规则得到对应的字表明，然后操作它。

分库

一旦分表，一个库中的表会越来越多

4.单机数据库的瓶颈

• 单个表数据量越大，读写锁，插入操作重新建立索引效率越低。
• 单个库数据量太大（一个数据库数据量到1T-2T就是极限）
• 单个数据库服务器压力过大
• 读写速度遇到瓶颈（并发量几百）

5.使用分区

什么时候考虑使用分区？

• 一张表的查询速度已经慢到影响使用的时候。

• sql经过优化

• 数据量大

• 表中的数据是分段的

• 对数据的操作往往只涉及一部分数据，而不是所有的数据

分区解决的问题

主要可以提升查询效率

分区的实现方式（简单）

mysql5 开始支持分区功能  MERGE等

CREATE TABLE sales (
id INT AUTO_INCREMENT,
amount DOUBLE NOT NULL,
order_day DATETIME NOT NULL,
PRIMARY KEY(id, order_day)
) ENGINE=Innodb 
PARTITION BY RANGE(YEAR(order_day)) (
PARTITION p_2010 VALUES LESS THAN (2010),
PARTITION p_2011 VALUES LESS THAN (2011),
PARTITION p_2012 VALUES LESS THAN (2012),
PARTITION p_catchall VALUES LESS THAN MAXVALUE);

6.使用分表

什么时候考虑分表？

• 一张表的查询速度已经慢到影响使用的时候。

• sql经过优化

• 数据量大

• 当频繁插入或者联合查询时，速度变慢

分表解决的问题

分表后，单表的并发能力提高了，磁盘I/O性能也提高了，写操作效率提高了

• 查询一次的时间短了
• 数据分布在不同的文件，磁盘I/O性能提高
• 读写锁影响的数据量变小
• 插入数据库需要重新建立索引的数据减少

分表的实现方式（复杂）

需要业务系统配合迁移升级，工作量较大

7.分区 分表异同

分区和分表的区别与联系

• 分区和分表的目的都是减少数据库的负担，提高表的增删改查效率。

• 分区只是一张表中的数据的存储位置发生改变，分表是将一张表分成多张表。
• 当访问量大，且表数据比较大时，两种方式可以互相配合使用。

• 当访问量不大，但表数据比较多时，可以只进行分区。

常见分区分表的规则策略（类似）

1. Range（范围）
2. Hash（哈希）
3. 按照时间拆分
4. Hash之后按照分表个数取模
5. 在认证库中保存数据库配置，就是建立一个DB，这个DB单独保存user_id到DB的映射关系

8.分库

什么时候考虑使用分库？

• 单台DB的存储空间不够
• 随着查询量的增加单台数据库服务器已经没办法支撑

分库解决的问题

其主要目的是为突破单节点数据库服务器的 I/O 能力限制，解决数据库扩展性问题。 

垂直拆分

将系统中不存在关联关系或者需要join的表可以放在不同的数据库不同的服务器中。

按照业务垂直划分。比如：可以按照业务分为资金、会员、订单三个数据库。

需要解决的问题：跨数据库的事务、jion查询等问题。

水平拆分

例如，大部分的站点。数据都是和用户有关，那么可以根据用户，将数据按照用户水平拆分。

按照规则划分，一般水平分库是在垂直分库之后的。比如每天处理的订单数量是海量的，可以按照一定的规则水平划分。需要解决的问题：数据路由、组装。

读写分离

对于时效性不高的数据，可以通过读写分离缓解数据库压力。需要解决的问题：在业务上区分哪些业务上是允许一定时间延迟的，以及数据同步问题。

思路

垂直分库-->水平分库-->读写分离

9.拆分后面临的问题

1 事务问题。

在执行分库分表之后，由于数据存储到了不同的库上，数据库事务管理出现了困难。如果依赖数据库本身的分布式事务管理功能去执行事务，将付出高昂的性能代价；如果由应用程序去协助控制，形成程序逻辑上的事务，又会造成编程方面的负担。

2 跨库跨表的join问题。

在执行了分库分表之后，难以避免会将原本逻辑关联性很强的数据划分到不同的表、不同的库上，这时，表的关联操作将受到限制，我们无法join位于不同分库的表，也无法join分表粒度不同的表，结果原本一次查询能够完成的业务，可能需要多次查询才能完成。

3 额外的数据管理负担和数据运算压力。

额外的数据管理负担，最显而易见的就是数据的定位问题和数据的增删改查的重复执行问题，这些都可以通过应用程序解决，但必然引起额外的逻辑运算，例如，对于一个记录用户成绩的用户数据表userTable，业务要求查出成绩最好的100位，在进行分表之前，只需一个order by语句就可以搞定，但是在进行分表之后，将需要n个order by语句，分别查出每一个分表的前100名用户数据，然后再对这些数据进行合并计算，才能得出结果。

4.数据一致性

分库分表，读写分离使用了分布式，分布式为了保证强一致性，必然带来延迟，导致性能降低，系统的复杂度变高。

解决方案：

对于不同的方式之间没有严格的界限，特点不同，侧重点不同。需要根据实际情况，结合每种方式的特点来进行处理。

选用第三方的数据库中间件（Atlas，Mycat，TDDL，DRDS），同时业务系统需要配合数据存储的升级。使用类似TCC-Transcation的分布式事务处理机制。

10.总结

总的来说，优先考虑分区。当分区不能满足需求时，开始考虑分表，合理的分表对效率的提升会优于分区。

来源：oschina

链接：https://my.oschina.net/u/4329403/blog/4106705