mysql 主从和分片
2017-12-24 09:49:31 0 举报AI智能生成
登录查看完整内容
为你推荐
查看更多
mysql 分库分表
作者其他创作
大纲/内容
mysql 主从和分片
开源实现
mysql Fabric
TDDL
Cobar
Atlas
Heisenberg
Vitess
多分片sql
select 普通，有序或无序
select 聚合
select 分页
select group
select group +聚合
一些数据
单机tps
应用tps 上限
情况
单台机器限制
访问量限制
表太大或者表太多
单台机器cpu和io都有上限，主要是io
全局主键问题
uuid
自建sequence表
flickr 多台机器得到步长不一样的数据
twitter方案 41位时间到毫秒+10机器+（线程号）12顺序
主从
概述
主从复制过程，是异步复制
三个线程，主io，从io，sql IO
类型
逻辑复制，基于sql的复制，问题 日期和next-key等不好处理
基于行的复制，binlog，5.0+支持
混合先sql，若无法精确采用行复制
复制过程
创建复制用户，可以选择那些表做主从
master 记录binary log
slave 通过 i/o线程拷贝master的log到自己的中继日志（relay log）
slave通过sql 线程 重做中继日志，是两者一致
复制是串行的，因此master的并行操作，在slave无法体现
配置过程
master建复制账号
拷贝数据
冷拷贝
热拷贝，myiSAm 可通过mysqlhotcopy 命令
使用mysqldump
配置master 开启binlog
配置slaver 开启relaylog，设置只读
异常情况
从库提升到主库，reset slave all
其他
master master 结构
master，master，slaver 结构
水平拆封
分区
Range
Hash
Key
List
Composite
分区or分表
优点
增删改索引消耗小
写操作的锁开销变小
垂直切分
业务相关表
一些字典共享表可缓存或者都复制一份
关联打断越多，影响join就多
根据活跃度来区别
冷数据适合做主从用myisam
热数据适合做master分表，用innoDB
更加活跃的数据考虑用缓存定时同步到DB
考虑 字段大小和访问频度
方式
hash
分布均匀，但扩容麻烦
需要迁移数据
新数据写扩容表，然后写映射表
hash后节点扩容问题解决方案
按用户id范围使用不同的hash策略
对2的倍数取余，可向前兼容
通过多级进行细粒度切分
过程，节点分组组内hash ，不同组hash不一样
可自定义分片中数据量
可以回收数据量
业务区分，如号段
存在热点数据，分布不均
热点数据分离
初始全分离
定时迁移分离
日期热点
热点历史数据分离
方案1：定时迁移数据，mysql删除数据导致数据碎片问题
方案2：分区或分表，分区解决io，分表提升并发分表可以merge，但有局限，分区一般不超过20
shardibatis 有些sql不支持
mysql merge 存在单点问题
自己代码实现
方案3 定时建表
每个季度一张表
表名采用sql变量动态获取
分片表，表中保存分区信息
优点：扩容方便，缺点：性能差，多一次查询
注意的问题
老分区有可能删除数据较多，有回收的需要
最好要能限制分区的数据上限
尽量均匀分布避免热点
问题与解决
完整性
事务问题
分布式事务
分拆小事务，通过程序处理
跨节点join问题
程序处理，先单表查id再二次查询
单表 count，order by，group by，聚合函数 等
分发加合并
索引映射表
通过某字段查到主键id，然后在通过id再查
缓存映射法：性能原因可考虑用全缓存代替映射表，先全缓存，后有修改添加到缓存
函数映射法
通过函数某字段生成id，需要时通过函数算出id，
也可抽取部分基因，融入id中后几位，如此可通过该字段hash到分库
业务与运营库分离（前后台分离）
多对多之数据冗余方案
对于某表可能进行分库要非常小心
双写两张表，如何保证一致性
在线修改表字段方法
新表+触发器+迁移数据+rename
version + json 数据方式，不支持索引
行转列方式，数据量膨胀
写库不建索引
切分原则
先垂直在水平切分
职业：暂无
0 条评论
回复 删除
下一页
