主从数据库的建立一般基于以下三个方面考虑：
1、容灾：备库在异地，主库不存在了，备库可以立即接管，无须恢复时间
2、负载均衡：主库做增删改，备库做查询，这样很多查询业务不占用主库资源
3、数据集中和分发：此种模式主要用于数据从分公司集中到总公司，或从总公司分发到分公司，
前提是公司需要同步的数据很少，另外各公司间业务系统不是同一家公司开发的
读写分离简单的说是把对数据库读和写的操作分开对应不同的数据库服务器，这样能有效地减轻数据库压力，也能减轻io压力。
主数据库提供写操作，从数据库提 供读操作，其实在很多系统中，主要是读的操作。
当主数据库进行写操作时，数据要同步到从的数据库，这样才能有效保证数据库完整性。
Quest SharePlex就是比较牛的同步数据工具，听说比oracle本身的流复制还好，MySQL也有自己的同步数据技术。
mysql只要是通过二进制日志来复制数据。通过日志在从数据库重复主数据库的操作达到复制数据目的。
这个复制比较好的就是通过异步方法，把数据同步到从数据库。
主数据库同步到从数据库后，从数据库一般由多台数据库组成这样才能达到减轻压力的目的。
读的操作怎么样分配到从数据库上？应该根据服务器的压力把读的操作分配到服务器，而不是简单的随机分配。
mysql提供了MySQL-Proxy实现读写分离操作。不过MySQL-Proxy好像很久不更新了。oracle可以通过F5有效分配读从数据库的压力。
读写分离（Read/Write Splitting）。
1.原理：让主数据库（master）处理事务性增、改、删操作（INSERT、UPDATE、DELETE），而从数据库（slave）处理SELECT查询操作。
2.诞生原因：
2.1 为了确保数据库产品的稳定性，很多数据库拥有双机热备功能。
也就是，第一台数据库服务器，是对外提供增删改查业务的生产服务器；第二台数据库服务器，
仅仅接收来自第一台服务器的备份数据（注意，不同数据库产品，第一台数据库服务器，向第二台数据库服务器发送备份数据的方式不同）。
当第一台数据库崩溃后，第二台数据库服务器，可以立即上线来代替第一台数据库服务器，并且，在第一台数据库服务器崩溃后，宝贵的数据，
依然会存在于第二台数据库服务器里（根据目前业界的备份数据发送方式来看，当第一台数据库崩溃后，第一台数据库里的仍然会有少量的新数据，
没能来得及被发送到第二台数据库服务器，所以，这部分数据就丢失了）。
2.2 一般来说，为了配置方便，以及稳定性，这两台数据库服务器，都用的是相同的配置（思考一下，如果两台服务器的配置不同，会导致什么结果）。
2.3 从上文的描述中，大家能看到，在实际运行中，第一台数据库服务器的压力，远远大于第二台数据库服务器。
因此，很多人希望合理利用第二台数据库服务器的空闲资源。那么，第二台数据库服务器能做些什么事情呢？
2.4 从数据库的基本业务来看，数据库的操作无非就是增删改查这4个操作。但对于“增删改”这三个操作，
如果是双机热备的环境中做，一台机器做了这三个操作的某一个之后，需要立即将这个操作，同步到另一台服务器上。
单向的同步，不复杂。但如果两台机器都需要向对方进行同步，那逻辑就非常复杂，而且还会大大降低性能。
（从保证ACID特性的角度，思考一下为什么双向同步会非常复杂且低性能？而单向同步却不会？）出于这个原因，
第二台备用的服务器，就只做了查询操作。进一步，为了降低第一台服务器的压力，干脆就把查询操作全部丢给第二台数据库服务器去做，第一台数据库服务器就只做增删改了。
2.4 到这一步，就实现了所谓的读写分离。这样做，缺点也非常明显了。
本来第二台数据库服务器，是用来做热备的，它就应该在一个压力非常小的环境下，保证运行的稳定性。
而读写分离，却增加了它的压力，也就增加了不稳定性。因此，读写分离，实质上是一个在资金比较缺乏，但又需要保证数据安全的需求下，在双机热备方案上，做出的一种折中的扩展方案。
资料来源自网络