把主站点 A 的所有应用负载切换到备用站点 B。在备用站点 B 新发生的数据改动会被 Q 复制捕获并发送出去。由于主站点 A 不可用，所以改动的数据会被暂存在站点 B 的 MQ 消息队列中。
升级主站点 A 的数据库服务器，并进行数据完整性测试和系统测试。
主站点 A 完成数据库升级后重新启动数据库。
站点 B 停应用。
主站点 A 重新启动 Q 复制程序（包括 MQ），暂存在站点 B 的 MQ 消息队列中的数据会被传送到站点 A，并被站点 A 的 Q 复制程序应用到数据库上。等待备用站点 B 上的所有数据改动都已被 Q 复制应用到主站点 A 的数据库上。
复制完成后把所有应用负载切换回主站点 A。
此时就完成了数据库升级和应用恢复。这时站点 A 上的数据改动源源不断被复制到站点 B，站点 B 可以用作热备或者查询用途。
利用 Q 复制的数据库升级过程中的各个阶段的业务停顿情况如表 2 所示。
表 2. 利用 Q 复制的数据库升级造成的业务停顿
No.操作站点 A
业务状态站点 B
业务状态业务停顿时间1升级前准备工作正常--2站点 A 停应用停顿-2 分钟3站点 A 到站点 B 的数据复制完成停顿-5 分钟4站点 A 停数据库服务器和停 Q 复制停顿-5 分钟5站点 B 启应用停顿-5 分钟6站点 A 升级数据库服务器；
并进行数据完整性验证测试，系统测试等。停顿
（3~5 个小时）正常-7站点 A 启动数据库服务器停顿正常-8站点 B 停应用停顿停顿2 分钟9站点 A 重新启动 Q 复制；
等待站点 B 到站点 A 的数据复制完成。停顿停顿10~30 分钟10站点 A 启应用停顿停顿5 分钟11站点 A 应用恢复之后正常--从图 3 和表 2 中可以看到，利用 Q 复制的数据库升级过程，在主站点 A 升级数据库服务器期间，业务和应用程序正常运行在站点 B 上，所以业务停顿时间只发生在两个小阶段。第一个小阶段是主站点 A 停应用到备份站点 B 启应用的过程；第二个小阶段是主站点 A 的数据库服务器升级完成后，备份站点 B 停应用到主站点 A 启应用的过程。这两个时间段都很短，大概只有十几分钟，从而整体的业务停顿时间由 3~5 个小时降低到 30 分钟左右。
与传统升级过程相比的优势利用 Q 复制的数据库升级过程有着显著的优势，因数据库升级引起的停机能在数分钟内完成站点间应用切换，可以实现很短的计划内停机时间，并且没有数据丢失。优势如下：
数据库服务器升级期间，业务正常运行，满足了用户的迫切需求。
业务停顿时间短，整体的业务停顿时间由 3~5 个小时降低到 30 分钟左右。
非常有效的降低了数据库升级的实施风险，提高了业务处理能力。如果升级过程中遇到预料之外的问题或者突发事件，可以让业务继续运行在站点 B 上，客户不会受损失。这样客户可以有更宽裕的时间和更好的灵活性来处理紧急事件。这个优势对于客户来说至关重要。
