我们在数据库的应用里，经常会使用到数据同步的场景， 从简单的单主单从同步， 到从单主多从， 再到多主多从等。 不同的数据库同步架构，都是为了解决不同的业务需求， 读写分离， 同城多活，异地多活等等。
常用的数据同步方式大概分为两种：
1、基于共享存储 ， 以oracle的 RAC为代表
2、基于数据的复制， 以mysql的binlog复制为代表
目前互联网行业使用最多的数据库就是mysql， 因此基于mysql数据库，业内也拓展出了一系列基于复制的数据同步架构。 无论基于数据库的上层架构如何设计， 都离不开binlog日志的同步。
如：
1、基于MySQL原生复制主主/主从同步方案
2、基于Galera replication方案
3、基于Mysql5.7之后的Group Replication方案
4、基于canal，otter的增量binlog解析同步方案
5、consul + haproxy 的服务注册发现和自动切换方案
6、sharding-proxy/ mycat 等中间件的路由方案
7、Tungsten Replicator
等等。 这些方案有个特点，就是根据具体需求去设计，满足特定条件，特定场景下的某些业务。
但这些方案我们今天都不谈，今天要讲的是如何搭建一个和任何业务技术需求都无关的binlog server。 它可以说是数据资产的集中化管理， 不同的业务线可以针对自己的业务需求从binlog server拉取相对应的增量数据信息， 比如读写分离的需求， 大数据的流数据需求， 甚至是特定场景下的双活多活需求，都可以基于binlog server去做。 而且， 从binlog server里同步数据，不会对生产的主库产生任何影响。
而且基于binlogserver可以灵活的进行架构设计，延伸出一系列有意思且好用的数据架构， 大家可以看看booking的架构师以前写的一篇文章：
目前搭建binlog server的技术有以下几种：
1、基于google 开源的mysql-ripple，
相关介绍可参考： https://github.com/google/mysql-ripple
2、github开源软件kingbus
相关介绍可参考： https://github.com/flike/kingbus
3、基于Mariadb的中间件Maxscale
这三种binlogserver MaxScale的使用最为广泛，也最为稳定，有官方持续支持，目前发布版本为2.4， 上面Booking使用的也是maxscale.
而且max不只能用来做binlogserver， 还可以实现读写分离、负载均衡、请求路由、数据库监控等，可谓中间件之利器。
所以后面接下来就介绍下 基于Maxscale的使用。
