三台服务器怎样实现mysql数据同步？可不可以互为主从？

可以一台做主机，两台做备机。
myql支持双向复制，就是互为主从。方法与主从同步一样，就是在备机上新建一个用户做主机，原来的主机做备机进行同步。
但是一般不建议互为主从，因为这样比较危险，一般主机用于数据更新，备机用于数据查询。最大效率提高数据库性能。

微软的MSCS, 赛门铁克的Veritas Storage Foundation，易腾数信的EterneCluster，SteelEye的LifeKeeper，
下面介绍下详细情况：
MSCS，微软自带的不过要在Server版本中才有，他的群集服务充当后端群集，可为数据库、消息传递以及文件和打印服务等应用程序提供高可用性。当任一节点（群集中的服务器）发生故障或脱机时，MSCS 将尝试最大程度地减少故障对系统的影响。
Veritas Storage Foundation，它提供了业界领先的异构存储管理和高可用性的软件解决方案，解决了企业如何合理保护和备份关键信息数据， 如何高效管理异构硬件环境，以及如何提高应用系统和数据库可用性的问题。
Veritas SFHA 主要包括以下五个组件：Veritas Volume Manager (VxVM)， Veritas File System (VxFS)，Veritas Cluster Server (VCS)，Veritas Storage Foundation Cluster File System (SFCFS)， Veritas Storage Foundation for Oracle RAC (SFRAC)
EterneCluster，易腾数信新一代的双机热备产品，具有人性化，高可配置性， *** 作简单，还支持基于多机的多机热备。可实现整个系统的不间断运行，从而保证整个系统对外服务的正常，为企业24小时×365天的关键业务应用提供了强大的保障。
LifeKeeper，使用户的服务器、 *** 作系统、数据库系统以及关键的数据及应用程序保持7天×24小时连续不间断，提供9999%的高可用性。
这些是做双机热备的几款软件，这几款软件都可以实现数据同步功能。

Linux自带了ntp服务 -- /etc/initd/ntpd，这个服务不仅可以设置让本机和某台/某些机器做时间同步，他本身还可以扮演一个time server的角色，让其他机器和他同步时间。
配置文件就是/etc/ntpconf。
为了测试，设置让node2 -- 1921681102和node1 -- 1921681101做时间同步。第一步，node1做time server，node1本身不和其他机器时间同步，就是取本地时间。所以，先把node1机器的时间调准了：
[root@node1 ~]date -s 08/03/2011
[root@node1 ~]date -s 11:12:00
[root@node1 ~]clock -w[root@node1 ~]hwclock --systohc
后两个命令是把设置的时间写到硬件时间中去（也就是CMOS里面的时间）。
第二步，然后将node1配置成一个time server，修改/etc/ntpconf，[root@node1 ~]vi /etc/ntpconf其他的配置不怎么需要改，只需要关注restrict的配置：
1 注释掉原来的restrict default ignore这一行，这一行本身是不响应任何的ntp更新请求，其实也就是禁用了本机的ntp server的功能，所以需要注释掉。

1、使用第三方同步软件
2、服务器后端挂存储设备，通过异地部署存储设备，两地复制（同步或者异步）
3、通过本地专业的备份软件将数据备份到本地另外设备，将备份设备的数据通过block级别的异地复制也可以达到
成本而言1-3，越来越高

用同步软件不就搞定了，省的瞎折腾了啊
我现在用的Bestsync2011同步软件，我觉得还蛮好用的，速度比较快，日志功能很强大，反正如果同步有任何错误，你能查看到每个文件的同步状态。
for example: 你可以把软件安装在服务器上，建立1个任务，来将这两台服务器进行实时同步。
1 在主菜单里面点 编辑-->追加任务
文件夹1选择 服务器A需要同步的文件夹位置
文件夹2选择 服务器B需要同步的文件夹位置
方向为由文件夹2到文件夹1
然后选择 完成 按钮
在主菜单上，点选 开始 按钮， 这样， A与B上的文件就完全一致了。
2 在任务列表中，双击你刚刚建立的这个任务，然后会d出属性对话框

翻到 “日程” 那页
勾选上 “文件一旦变化，立即同步”这个选项
最后点击 确定 按钮
这样，只要服务器A的指定文件夹一旦变化，就实时同步到服务器B了以此类推
他们新浪微博上要好多教程，你不清楚可以去看那上的手册。。。
是否可以解决您的问题？

不管是否是微服务架构，应用的各个模块之间都需要频繁的通信、协作、共享数据，实现系统的整体价值。区别点在于单体应用是通过本地方法调用来完成；在微服务中是通过远程API调用完成。
而共享数据最贱的方式就是采用共享数据库模式，也就是单体应用中最常用的方式，一般只有一个数据库，如图一库多服和一库一服的方式:
一库多服的架构模式通常会被认为是微服务架构下的反范式，它的问题在于：
稳定性：单点故障，一个数据库挂掉，整批服务全部停止。服务独立性被扼杀？
耦合性：数据在一起，会给贪图方便的开发或者DBA工程师编写很多数据间高度依赖的程序或者工具；
扩展性：无法针对某一个服务进行精准优化或扩展，服务会大体分为两个读多写少、写多读少，数据库优化是根据服务而来的，不是一篇而论。
所以随行付内部一般推荐的做法：是为每一个微服务准备一个单独的数据库，即一库一服模式。这种模式更加适合微服务架构，它满足每一个服务是独立开发、独立部署、独立扩展的特性。当需要对一个服务进行升级或者数据架构改动的时候，无须影响到其他的服务。需要对某个服务进行扩展的时候，也可以手术式的对某一个服务进行局部扩容。
那么问题来了，在改造中我们发现，以下问题，诞生了该项目：
报表中心和前端详细页都存在SQL Join方式，经历我们一库一服的拆分后，无法在继续使用SQL Join方式了
数据中心，做得是数据聚合，数据拆分后，给数据中心带来了很大的麻烦
微服务之后，各个应用模块对数据库的要求出现了分歧，数据库类型多元化自主选择还是统一
等等

---