恳求数据库归档读写分离解决方案！

[xuyi1979]

在维护一个老项目，业务数据库很大（近百G），想做如下处理：
1、先将业务数据库备份并还原到查询数据库中。
2、然后将业务数据库中的历史业务数据（例如一年前的数据）删除并压缩数据库。
3、最终建立业务数据库和查询数据库的关系，并定时将业务数据库的所有修改数据同步到查询数据库中。
请各位高手集思广益，第三步如何实现？

[0与1之间]

不同服务器，做复制订阅，实时同步，一边写入一边读取

[xuyi1979]

我把实际情况说明一下，该数据库运行了3年多，其中一些主要业务表（十几个表）每个表都有几百万或千万行数据，每个表字段也有近100个，而且业务表之间还有相互关联，我想的方案是由于历史数据不常用，因此专门部署程序服务器连接查询数据库用于全部查询，而业务操作数据库只保留一年的数据，这样业务操作的速度和效率会有很大提升。而 发布订阅 必须是两个数据库完全一样，我希望的只是业务操作数据库增量同步到查询数据库，业务操作数据库定期做清理控制大小来保证业务操作效率，请教大家有什么建议？

[Tiger_Zhao]

历史服务器上订阅，产生一个业务数据库的副本，通过定时任务把业务数据库副本上的数据导入/合并到历史数据库中。
数据不一致，总要写些代码的。

[卖水果的net]

对数据同步的实时性，是什么要求，发布订阅，应该可以满点你的这个需求；

[shoppo0505]

引用 楼主 xuyi1979 的回复:

在维护一个老项目，业务数据库很大（近百G），想做如下处理： 1、先将业务数据库备份并还原到查询数据库中。 2、然后将业务数据库中的历史业务数据（例如一年前的数据）删除并压缩数据库。 3、最终建立业务数据库和查询数据库的关系，并定时将业务数据库的所有修改数据同步到查询数据库中。 请各位高手集思广益，第三步如何实现？

个人经验，数据库的实际大小和性能并没有关系。 但是表格中的数据量影响性能的比重很大。 也就是说，设计数据库的时候，就需要考虑工作表和备份表的设计。而不是分割数据放入不同的数据库。

[Tiger_Zhao]

如果分服务器，那么当年业务/历史业务分离有可能提高性能。
如果还是同一个服务器，分离后唯一好处大概就是做一次完全备份的数据量小了（当然备份时间就少了）
——但是你又要把数据同步过去，历史业务也要备份，没好处啊！

[唐诗三百首]

有2个问题需考虑: 1.确认数据定时同步作业是否可行,即各种数据都可实现增量同步(而非全量同步). 2.前端程序修改和测试, 原先连1个服务器,现在2个,依什么规则判断应连接的服务器?

[Mirror然]

可以做2个库 一个业务数据 一个查询数据 上百G 不是很大 一般硬件配置都没问题，根据需求在做分布 同步