新业务系统后端是MySQL, 加上nginx做负载均衡吧。个人建议套用传统数据库经验，先对照着去理解MySQL体系架构 形态，选用的高可用架构特点；然后对照着去学运维管理上的差异（启停维护，容量管理，日常监控、数据库应用 异常处理和性能分析）都有哪些项。... (more)

仲裁一般是占>1/2的多数派存货，按这个原则，你描述的这种同城双活，通常两个中心除了有RAC节点，也会对称的一边一套存储， 一般建议引入一个第3站点， 第3站点的主要作用上为Oracle RAC提供 一个仲裁存储节点。这个第3站点，如果有物理上的第3个数据中心最好，如果没有也可以是逻辑... (more)

理解您的需求是从易用性和可管理性的角度来看切换的解决方案。VM Recovery Manager是个挺好的选择，相对与传统的监控和管理方式，它增加了VM失效检测、跨站点的定制化脚本切换、应用监控和设置多种迁移策略的功能，而且是简洁的图形管理界面。... (more)

抖动通常是不可避免的，即便是运营商提供质量再好的裸光纤连接，还是或多或少会存在抖动。如果频率不是很高，不至于引起网络长时间超时的话，都属于在可控范围内。理论上每100KM距离，RTT往返延迟为1MS，但一次通讯，往往会存在多次RTT，所以带来的延迟是不可避免的。网络上最好还是基于... (more)

存储复制过程中链路的抖动不会丢数据，抖动结束后数据会追齐！

这问题比较宏观，同城双活概况上来讲要考虑的层次有： 网络层 应用层 数据库层  - 存储层 这几层的实现难度是不同的，通常网络层和应用层比较容易实现，成熟的产品和方案也比较多，因为这两层只分发请求，不处理请求，比较容易横向扩展，也基本不存在相互间需要同步数据的问题。问题中... (more)

您谈到了双活 同时 还有业务切换，那么我理解还是主备的模式，不然完全的双活系统就不存在切换的问题。核心业务切换，前提一定是业务的分级和分组之后的切换，不然只是某个业务切换了，其他的相关业务还留在原中心，这样的切换也没什么意义。至少要保证一组相关的业务一起切换。如... (more)

数据中心的双活，不同的客户有不同的理解，通常的理解是指两个数据中心均处于运行状态，可以同时承担一定的业务能力。但根据备中心能够承载的业务能力来区分，又可以分为以下几种： 主备模式：即生产中心完全承载主生产任务，备中心只是进行数据的同步或异步复制，保证灾难时备中心的数... (more)

IBM i 平台经过 30 年的发展，在业务连续性方案上已经非常成熟，综合起来，业务连续性技术主要分为以下三类： 基于逻辑复制（ Logical Replication ）的技术，其原理是将数据库日志从源端复制到目标端，代表产品有 MIMIX 、 OMS 、 iCluster 、 QuickEDD 等。 基于 PowerHA （存储拷贝... (more)

您这个问题有点儿大，我尝试从我的角度来回答一下。目前看到的同城双活的用户，很多是指同城双中心都可以提供服务，但针对于某一个具体业务而言，并非是双中心都数据库均衡负载提供服务。可能一边提供服务，另一边数据级同步复制的情况比较多。在这种情况下业务连续性和健壮性，还是... (more)