搜索
关于多发布单订阅：建立的关键点：1.集团订阅多个分厂的发布，有且仅对一个分厂的发布进行初始化。该分厂的发布数据库如果有数据，数据会经过初始化同步到集团数据库。2.各分厂在建立发布订阅之后更新的数据才会同步到集团订阅数据库，而之前的数据则不会同步到集团订阅数据库（需要手动操作导入到集团数据库中）（解释”有且仅对一个分厂的发布进行初始化”：1.必须对某个分厂进行初始化，这个操作用来生成发布快照，因为事务发布是建立在发布快照基础之上的。只有生成了快照，分厂发布与集团订阅之间才能建立联系，如果没有进行初始化生成快照，发布与订阅之间就不会建立联系；2.有且只能对一个分厂初始化。如果对第一个分厂的订阅初始化之后，第二个分厂也进行初始化，结果会是:第二个分厂与集团订阅建立了联系而第一个分厂与集团订阅没有了联系。因此，若实现集团订阅多个分厂的发布，只能是在对第一个分厂订阅初始化之后，其余的分厂不再进行初始化）方案：方案一：在分厂发布数据库里没有数据的情况下建立发布订阅;在建立发布订阅时分厂发布数据库的表只有表结构而没有数据。所有的数据在建立发布订阅之后插入到分厂发布数据库中。（包括历史数据和新采集数据）在往分厂发布数据库插入历史数据之前，需要先停止代理，等历史数据插入完成后再启动代理。打个比方：数据就像是突然而来的洪水，若不停止代理，就会冲毁大坝（建立起来的发布订阅结构）。对于每次手动对分厂发布数据库数据的增删改都应该停止代理再进行操作。另外，对于历史数据导入时，数据脚本不宜太大（一个600M的数据脚本没法执行，因为没有足够的内存执行程序，服务器运行脚本容量的上限未知）方案二：在分厂发布数据库里有数据（暂且称为历史数据）的情况下建立发布订阅。这种情况下，第一个分厂的历史数据会通过初始化这个步骤同步到集团订阅数据库，其余的分厂在建立发布订阅之前先通过数据库的导出导入功能（分厂发布数据库的历史数据导出，集团订阅数据库导入），将数据导入集团订阅数据库中，之后，再给其余分厂建立发布订阅。条件：这种方案要求分厂发布数据库在没有数据采集，也即分厂发布数据库静止的情况下进行。（因为建立发布订阅也要生成日志文件，size在变化就生成不了日志文件，于是建立过程会报错！）注意：1.在停止数据采集的情况下建立发布订阅，会导致部分采集数据的丢失。（在对第一个分厂建立发布订阅时需要停止数据的采集，从第二个开始就不需要了，因为从第二个开始，发布订阅的建立不需要生成日志文件）根据实际情况，采用方案二比较合理，操作也相对简单以下是亮哥的几个问题及我的回复问题：1、对于事务型的同步，是按照周期同步，还是发布者数据表内容变化的时候立即同步？2、单向发布的时候，发布者向订阅者同步数据，但订阅者相应的表中有订阅者本身的数据（多于发布者的数据），是否这些数据都会被覆盖？3、是否测了，大数据同步所用的时间（避免长时间断网，忽然联网后造成网络堵塞或者服务器忙）。4、表结构变化时，同步的能否顺利进行（表结构变化后两边的结构也是一样）5、对于单向同步，如果发布者数据无变化，但是订阅者数据变化了，是否会把订阅者的数据又同步回来。回复：1.是按照周期同步的，数据的增加信息和表结构的更改信息是要排队同步的，有时间的先后顺序2.是会覆盖，建立发布订阅最好订阅数据库是空的，不是空的也会抹去。解决办法是先将订阅数据库中的数据导出，建立好发布订阅之后再插入进去。3.断网一段时间后再接通后，大数据会继续同步。如果出现未知原因导致发布订阅破坏，可重新建立发布订阅不影响订阅数据库，但会造成一些数据丢失，可以查询发布数据库将丢失的数据收到插入到订阅数据库4.不影响,会顺利同步5.我们所用的事务或者快照发布不会，是从发布者到订阅者单向的；如果采用合并发布就会出现，订阅者数据变化，订阅者的数据又同步回发布数据库。事务发布没有下行，但合并发布有下行。