mysql主从&shardingsphere分库分表

问题：

1. 公司的mysql主从复制方式怎么查看——这个命令在哪敲

2.公司扩容一个从的时候怎么做的？——

3.公司主从架构模式是什么样的？几主几从

4.公司的业务场景有木有要求写后立马查出数据的

mysql主从架构

mysql主从架构详解

mysql读写分离

mysql主从集群扩容&半同步复制

mysql主从架构的问题

1.mysql同步方式以及半同步复制问题

Q1:半同步复制能保证一定不丢数据吗？

A：不能，因为半同步复制是至少一个slave同步到了，才响应客户端，因此可能slave挂了，但这种可能性很小，且无法避免，所以不考虑

Q2:半同步复制的影响：

A：半同步复制要等slave响应，所以写数据的时候性能会有影响，效率会低一点

主从延迟问题

在高并发场景下，从库的数据一定会比主库慢一些，是有延时的。所以经常出现，刚写入主库的数据可能是读不到的，要过几十毫秒，甚至几百毫秒才能读取到。

压力测试 :

写请求1000/s-2000/s 大概有10 - 30ms左右的延迟。

写请求4000/s - 5000/s 大概有1 - 3秒左右的延迟。

如果主从延迟较为严重，有以下解决方案：

分库，将一个主库拆分为多个主库，每个主库的写并发就减少了几倍，此时主从延迟可以忽略不计。 (即减少binlog同步日志)

打开 MySQL 支持的并行复制，多个库并行复制。如果说某个库的写入并发就是特别高，单库写并发达到了 2000/s，并行复制还是没意义。

重写代码。插入数据时立马查询可能查不到。比如尽量避免插入后就马上读。

如果 强行要求 ：必须插入后，立马要求就能查询到 ，有以下解决方案：

通过数据库中间件，设置读写直连主库。不推荐这种方法，这么搞导致读写分离的意义就丧失了。

如果基于有这样的业务要求。不要试图在数据库层解决并发的读操作问题，至少不要在主从架构的数据库层解决。要在数据库层之上架构一个redis这样的分布式缓存来解决，它是专门干这个的。其性能肯定远高于从备机读取数据。

 2.1主从延时问题的原因以及解决办法part1

2.2主从延时问题的解决办法part2

2.3主从延迟原因

2.4主从延迟数据不一致解决方法

主从延迟的解决方案
 

shardingsphere分库分表

数据库分库分表思路

MySQL数据库之分库分表方案（只看这一个就够了）

多对多业务，数据库水平切分架构一次搞定

分库分表实战--- ShardingSphere实战

一般来说，在系统设计阶段就应该根据业务耦合松紧来确定垂直分库，垂直分表方案，在数据量及访问压力不是特别大的情况，首先考虑缓存、读写分离、索引技术等方案。若数据量极大，且持续增长，再考虑水平分库分表方案。

MySQL-如何分库分表？一看就懂

shardingsphere分片策略

ShardingSphere-JDBC 的4种分片策略

hint：代码写死指定sql访问哪个库表

inline：yml配置 表达式——数据分布均匀，但是扩展难

standard：类定义，自己写实现——可以让数据范围分布，扩展容易（如生成含有年份的id，去处年份部分来分布） & 逻辑再加一层id按照表达式的逻辑 分布 ，就能实现：扩展容易 & 分布均匀

complex：多个字段分库表

shardingsphere主键生成策略（spi可以自定义）

ShardingSphere-JDBC 的3种主键生成策略

主键：uuid、雪花、自定义spi、none（业务构造id，然后setid进去）

ShardingSphere的扩展点

分库分表带来的问题

很多SQL不支持、数据迁移、扩缩容、公共表、读写分离、配置往注册中心集中配置

分布式事务处理

shardingsphere源码

shardingsphere优化

内存限制模式（maxconnectionperquery大，每个连接都持有数据，一条条放到内存中，流失归并，用完一个结果，释放一个内存）：OLAP，适用于实时分析，报表，吞吐量大——流失结果集
连接限制模式（所有结果都先放到内存中）：效率高，试用于大事务——产生内存结果集（可能内存溢出）

区—ShardingSphere之分组group by过多消耗内存的问题

ShardingSphere官网操作指南补充和重点整理-数据分片-内核剖析（五）

maxconnectionperquery & 内存限制模式 & 归并模式——待解决

7. sharding-jdbc源码之group by结果合并(2)

数据库动态扩容缩容

考虑的问题:

2、两个库，四个表。要如何将数据分配均匀?

3、如何定制适合业务场景的数据分片策略?

Q：有哪些常用的数据分片策略?

取模分片、按时间范围分片、按业务要素 (如地区、前缀等)分片。。。。

取模分片：能够将数据分配得尽量的平均，但是不利于扩展。

范围分片：便于扩展但是他的数据分布又不够均匀。

A：是不是可以定制一种分片策略，将这两种分片策略结合起来?比如大 尺度上按范围分片，但是在每个数据范围内，使用取模分片。这种分片 策略要如何在ShardingSphere中实现?

2、旧数据处理方式

如果要在中途进行分库分表，要分为两个步骤:

1. 首先:要评估数据分片方案，对关键的SQL进行整理并分析。分库分表后，有很 多SQL是无法支持的，这些SQL一定要优先从业务中去掉。这个步骤很容易被忽略， 但是一定是必不可少的。有哪些SQL是ShardingSphere不支持的? 参见官网。

2. 然后:当你制定好了分库分表方案后，不要急于迁移旧数据。最好是在业务中对 SQL进行数据双写。即老数据库写一份，新的分片后的数据库也写一份。观察一段 时间，等业务稳定了之后，再考虑全部转移到分片后的新数据库中。这同样需要多 方定制ShardingSphere的分片策略，简单的inline是很难达到这个目的的。

3. 接下来:进行旧数据迁移时，可以采用ShardingProxy来协助进行数据转移。部 署同样分片策略的ShardingProxy，一方面可以在MySQL的客户端工具中快速验证 分片策略，另外可以使用sqoop、keetle等工具来协助进行数据转移。

分库分表带来的问题 定制主键生成策略

主键是分库分表中非常重要的业务要素，通常分库分表都会采用主键来作为分片 键，这个时候主键就不再只是用来提升查询效率了，还需要坚固数据分片的效率。 要如何定制高效的主键生成策略?

很多SQL不支持

例如MySQL里会配for each标签来执行批量SQL，原始数据库是支持的，但是分 库分表不支持。

查询的SQL比较多时，路由策略是否支持? 去官网上查一下分库分表的不支持项。

其他问题

数据迁移、扩缩容、公共表、读写分离、配置往注册中心集中配置

分布式事务处理