1、如果用ROSE之类的双机系统做双机冗余，涉及到的进程监视点调试极其麻烦，不是资深的原厂认证工程师根本就搞不定，对于可靠性上来说倒是绝对满足没有问题，但可维护性来说实在是件要命的事。
10年积累的网站设计、成都网站设计经验，可以快速应对客户对网站的新想法和需求。提供各种问题对应的解决方案。让选择我们的客户得到更好、更有力的网络服务。我虽然不认识你，你也不认识我。但先网站设计后付款的网站建设流程，更有汤原免费网站建设让你可以放心的选择与我们合作。
2、你可以考虑用VMWARE ESX做双机集群，然后把POSTGRESQL的WIN2K3虚拟机放在双机集群上，做虚拟机进程的动态漂移，这根本就不需要去针对进程监视做那一大堆的调试，当集群里一台服务器DOWN掉的时候，而且还要恰好你的应用虚拟机进程现在就跑在DOWN掉的这台上，那么在1秒内会动态漂到另一台并行的服务器上，几乎是无缝的，但在管理机的VSPHARE上可以实时看到，我认为这个方案比传统双机要好得多，而且ESX也不贵，调试比双机冗余来得简单，网上还有大堆的破解。
楼主想用PostgreSQL集群功能目前行PostgreSQL standby功能看原文档介绍 目前PostgreSQL做负载均衡集群案前读写离案楼主
虽然 kubernetes 社区一直在努力使得有状态应用成为一等公民，也推出了 statefulset 控制器支持 pod 的顺序部署，稳定的域名访问和存储访问。但鉴于 MySQL 部署运维的多样性和复杂性，在 kubernetes 上部署 MySQL 仍然要面临众多挑战。
1、业务流量入口的配置方式
传统虚拟机环境下，我们通过虚IP的方式，让业务应用都配置事先定义的一个虚IP为链接数据库的地址，然后由高可用服务保证虚IP始终能被路由到master数据库。在kubernetes中，出现了一层网络插件屏蔽了底层网络拓扑，高可用服务管理虚IP的方式需要随之适应调整，比如通过service结合标签完成虚IP的漂移，但service本身是kubernetes提供的一项功能，其可靠性和性能都取决于kubernetes服务的稳定。以性能来说，service是kubeproxy组件通过配置iptables实现的，当iptables规则较多时不可避免的会产生时延，需要我们针对性的解决。
2、容器隔离带来的监控视野问题
在 kubernetes 中，如果将 MySQL 制作为 container 运行在一个 pod 中，container 会将 MySQL 进程和运行环境隔离在一个单独的 namespace 中。监控组件在获取 MySQL 的一些 metirc 时，可能不得不进入与 MySQL 同一个 namespace 中，在部署和设计监控组件时需要考虑到这些限制。
3、存储在 kubernetes 中，支持配置各种不同的存储。
如果使用本地存储 local persistent volume，则需要绑定 MySQL 在一个固定的节点，这就完全浪费了 kubernetes 灵活调度的天然优势；而如果使用远程共享存储，确实是将 MySQL 进程与其存储完全解耦，使得 MySQL 进程可以在任意节点调度，然而考虑到高 I/O 吞吐量的情况，就不是那么美好了。设计时需要考量远程存储是否能够满足 MySQL 的带宽要求。
4、高可用/备份恢复
kubernetes 提供的 statefulset 控制器只能提供最基本的部署，删除功能，无法实现完善的 MySQL 集群高可用/备份恢复操作。对于有状态应用的部署，仍需要定制开发，所以多数公司提供了定制的 operator 来完成应用容器的管理。比如 etcd operator，MySQL operator，后文将为大家详述我测试使用 MySQL operator 的一些记录。
楼主想用PostgreSQL集群功能目前行PostgreSQL standby功能看原文档介绍 目前PostgreSQL做负载均衡集群案前读写离案楼主
