数据库的扩展性，怎么升级

哪些扩展？

1 数据库结构改变，直接改结构的话，在并发量大时，会锁表

2 水平扩展，分多个库，

3 底层存储介质变更，比如从myqsl变到mongodb

 

解决方案:

1 停服务迁移

2 数据库结构变更可以用online-schema-change,不用停服就能修改的方案（注意在流量少的时候做）

3 水平扩展怎么解决？追日志方案（平滑）

 

 

 

 

 1) 写一个记录增，删，改，日志记录的小脚本，只需要记得是哪个库，哪张表，哪条数据的主键

2) 写一个脚本功能，把旧库的数据，慢慢的迁移到新库来

3) 追日志方案，2步做完之后，就把第1步写的日志记录作用到新库里面，出现冲突的化以旧库为准，或者从第2步开始重来

4) 再写个小脚本，做新旧数据的对比，

5）对比完全一致时，旧库做秒级的ready only, 数据指向新库

4 双写方案

 1) 服务对增/删/改，进行新旧数据库的同时写入。

2) 写一个脚本功能，把旧库的数据，慢慢的迁移到新库来，这样当数库全部迁移过来时，原则上新旧数据库会一模一样，举例：已经同步过来的数据跟未同步过来的数据，通过双写，加同步之扣，最终数据会一致。

3) 再写个小脚本，做新旧数据的对比，

4）对比完全一致时，旧库做秒级的ready only, 数据指向新库

5 秒级成倍扩容，必须是翻倍扩容，前提是实现了高可用

 

 这是业务场景

业务做了水平切用为2个库，同时做了高可用

第一步：修改配置,打断高可用，

 

 

 这里相当于，以前%2=0的两台高可用服务器，变成了%4=1和%4=2指向的两台服务器，因为这两台服务器数据一模一样，

第二步：重启配置，所有路由过来时，数据都是正常的

 

第三步：解除以前的数据同步，删除每个库的多余数据，比如%4=0的，我就可能把%4=2的数据给删除掉，然后重新做新的高可用