mysql双主配置很简单，似乎大家都只关心他的安装和部署，大家可以用他来做双活的方案，并没有深刻的思考过生产环境后续管理的风险和如何规避这些问题。
创新互联是专业的蒲县网站建设公司，蒲县接单;提供做网站、成都做网站,网页设计,网站设计,建网站,PHP网站建设等专业做网站服务;采用PHP框架,可快速的进行蒲县网站开发网页制作和功能扩展;专业做搜索引擎喜爱的网站,专业的做网站团队,希望更多企业前来合作!
log-slave-updates = true
auto_increment_offset = 1 #另外一个主B是2，其他一样。
auto_increment_increment = 2
replicate-ignore-db = mysql
replicate-ignore-db = sys
replicate-ignore-db = information_schema
replicate-ignore-db = performance_schema
replicate-ignore-db = undolog
replicate_wild_ignore_table = mysql.%
replicate_wild_ignore_table = sys.%
replicate_wild_ignore_table = information_schema.%
replicate_wild_ignore_table = performance_schema.%
replicate_wild_ignore_table = undolog.%
双主如果一边更新表结构，一边在写入，即使你认为你的的sql没有问题。但是mysqlbinlog的写入日志不是这样的，比如row格式，需要回放的日志如下下面，你修改表结构之前是可以插入的，中间查多一列的话，你的列对不上了，导致1167错误。目前有两种办法可以规避这个问题：
如果忽略了一些库，比如mysql的库，创建账号的时候，就需要两边创建。
主要是数据中心的同步问题,一般双活都要跨机房、跨城市。数据同步是大问题。 而且现在也没有几家公司的mysql集群是双活架构
2.问题列表
问题提出者进度结论备注
问题提出者进度结论备注
中台只需要业务支持还是存储也要部署HNC 汪晓明 待讨论专项：核心链路梳理
两轮车hnc双活对成本的要求是如何的 王勇 已完成
两轮车线上部署方案以及打包脚本改造 圆圆 待讨论专项：核心链路梳理
两轮车所有外部服务+接口依赖梳理 圆圆 待讨论专项：核心链路梳理
备机房如果只保证主链路，如何降低业务开发人员的感知和复杂度 田玉磊 已完成业务无感知应是基本原则。
Api Router目前如何工作已完成卫民已做解答
TCP和IOT层是否要做双机房 田玉磊 已完成至少第一阶段不会双活 彭帝 判断
本机房优先的路由策略(如何判断是本机房服务，如何控制权重) 陈鹏志 需改造路由需要改造，
权重可以通过按照城市维度控制粒度
专项：dubbo双活方案
跨机房部署是否有独立的注册中心，zk是否会成为服务规模瓶颈 陈鹏志 已完成仅仅用作服务发现，不会影响性能。专项：ZK双活方案
KOP支持多注册中心下 陈鹏志 需改造专项：dubbo双活方案
DBProxy是否有现成的多机房方案 陈鹏志 需改造专项：DB双活方案
多机房网络是否经过NAT映射 陈鹏志 已完成没有
同城双活目标，原则 侯云飞 已完成稳定性OKR（ 服务端 ）决定目标
确定主链路，主链路和非主链路之间是否可以解耦降级 侯云飞 需改造
互联网流量如何打到多个机房，支持哪些策略 侯云飞 已完成卫民已解答
机房收到流量后，路由到LA上，LA采用什么技术 侯云飞 已完成卫民已解答
zk集群每个机房一套，在部署时，如何保证服务配置在不同机房路由到不同zk集群 侯云飞 专项：打包部署方案
DDMQ同一名称的队列如果是多机房多实例，那么当某一机房故障时，会损失一部分消息，是否可接受 侯云飞
mysql、gift、codis、mongo、kschedual双活 侯云飞 需改造
有些服务甚至依赖hbase，是否需要双活 侯云飞 需改造专项：核心链路梳理
请求路由sharding方案，并不是所有接口都有城市ID，是否有多套 吴文豪 需改造专项：路由策略
一旦链路上存在未双活服务，存在跨机房调用，耗时不可控，也达不到同机房闭环的初衷 吴文豪 已完成同城双活，跨机房调用RT增加1~2ms，不影响用户体验
业务调用中台，中台回调业务地址是VIP，运维层面能不能做到指定，还是需要改造 吴文豪 需改造专项：路由策略
MQ是否已经存在跨机房，这部分如何处理 吴文豪 需改造专项：MQ双活方案
业务方需要在切换机房时主动切换dbproxy的vip 田玉磊 已完成不同机房会有不同配置
机房故障到切换主库之间，会有短暂的服务无法写入的情况，如何保证数据的强一致性？ 田玉磊 需改造专项：DB双活方案
dubbo如果部署双活注册中心，需要使用多活服务的消费者必须重新配置上线，
将来多活时还要调整，这虽然和我们的原则冲突，应该可以接受
侯云飞 需改造专项：Dubbo双活方案
一、分库分表的必要性
分库分表技术的使用，主要是数据库产生了瓶颈，如单库的并发访问或单表的查询都超出了阈值。对系统使用造成一定的影响，不得已而产生的技术。
通过分库分表技术来解决此类问题，但正因为使用此技术，会产生ACID一系列的问题，各类中间件解决此类问题各有各的优势。
提示：如场景无必要，千万不要使用分库分表。
二、分库分表的思路
1、垂直区分
垂直分库：从业务角度，一个库分成多个库，如把订单和用户信息分成两个库来存储。这样的好处就是可以微服务了。每块的业务单独部署，互不影响，通过接口去调用。
垂直分表：把大表分成多个小表，如热点数据和非热点数据分开，提高查询速度。
2、水平区分
水平分表：同一业务如数据量大了以后，根据一定的规则分为不同的表进行存储。
水平分库：如订单分成多个库存储，分解服务器压力。
以上一般来说，垂直分库和水平分表用的会多些。
三、分库分表的原理分析
分库分表常用的方案：Hash取模方案和range范围方案；
路由算法为最主要的算法，指得是把路由的Key按照指定的算法进行存放；
1、Hash取模方案
根据取余分配到不同的表里。要根据实际情况确认模的大小。此方案由于平均分配，不存在热点问题，但数据迁移很复杂。
2、Range范围方案
range根据范围进行划分，如日期，大小。此方案不存在数据迁移，但存在热点问题。
四、分库分表的技术选型
1、技术选型
解决方案主要分为4种：MySQL的分区技术、NoSql、NewSQL、MySQL的分库分表。
（1）mysql分区技术：把一张表存放在不同存储文件。由于无法负载，使用较少。
（2）NoSQL（如MongoDB）：如是订单等比较重要数据，强关联关系，需约束一致性，不太适应。
（3）NewSql(具有NoSQL对海量数据的存储管理能力，还保持了传统数据库支持ACID和SQL等特性):如TiDB可满足需求。
（4）MySQL的分库分表：如使用mysql,此种方案为主流方式。
2、中间件
解决此类问题的中间件主要为：Proxy模式、Client模式。
（1）Proxy模式
（2）Client模式
把分库分表相关逻辑存放在客户端，一版客户端的应用会引用一个jar，然后再jar中处理SQL组合、数据库路由、执行结果合并等相关功能。
（3）中间件的比较
由于Client模式少了一层，运维方便，相对来说容易些。
五、分库分表的实践
根据容量（当前容量和增长量）评估分库或分表个数 - 选key（均匀）- 分表规则（hash或range等）- 执行（一般双写）- 扩容问题（尽量减少数据的移动）。
在这里我们选用中间件share-jdbc。
1、引入maven依赖
2、spring boot规则配置
行表达式标识符可以使用${...}或$-{...}，但前者与Spring本身的属性文件占位符冲突，因此在Spring环境中使用行表达式标识符建议使用$-{...}。
3、创建DataSource
通过ShardingDataSourceFactory工厂和规则配置对象获取ShardingDataSource，ShardingDataSource实现自JDBC的标准接口DataSource。然后即可通过DataSource选择使用原生JDBC开发，或者使用JPA, MyBatis等ORM工具。
