在线系统迁移与升级方案
系统迁移方案
系统迁移方案1.引言本迁移方案旨在将现有系统（旧系统）迁移至新系统，以提高工作效率、降低成本、优化业务流程。
本迁移方案将详细描述迁移的策略、计划、风险管理、测试计划和实施计划，以确保项目顺利完成。
2.项目概述项目名称：系统迁移项目目标：将现有系统迁移至新系统，提高工作效率、降低成本、优化业务流程。
项目范围：包括旧系统的数据、应用、网络等全部迁移至新系统。
项目时间表：预计耗时6个月，分为准备阶段、迁移阶段和测试阶段。
项目预算：总预算为100万元人民币。
3.迁移策略3.1 迁移方法：采用逐步迁移策略，按照业务重要性、数据量大小和系统复杂度等因素，分批次迁移。
3.2 迁移步骤：a) 数据备份：对旧系统的数据、配置等进行全面备份。
b) 硬件和网络升级：升级至新系统的硬件和网络。
c) 系统安装与配置：安装新系统，并进行相关配置。
d) 数据迁移：将备份的数据导入新系统。
e) 功能测试：对新系统进行功能测试，确保各项功能正常。
f) 性能测试：对新系统进行压力测试，确保系统稳定性和性能。
g) 用户培训：对用户进行新系统的培训，确保用户能够熟练使用。
h) 正式上线：在确保一切正常后，正式上线新系统。
3.3 迁移工具：采用专业的迁移工具，以确保数据完整性和一致性。
4.迁移计划4.1 准备阶段（1个月）：a) 成立项目组，明确各成员职责。
b) 制定详细的项目计划和时间表。
c) 准备所需的硬件和软件环境。
d) 收集旧系统的数据和配置信息。
e) 对旧系统进行全面备份。
4.2 迁移阶段（3个月）：a) 根据业务重要性、数据量大小和系统复杂度等因素，制定详细的迁移计划。
b) 分批次进行数据迁移、硬件和网络升级、系统安装与配置等工作。
c) 在每批次迁移完成后，进行功能测试和性能测试，确保各项功能正常。
应用系统迁移设计方案
应用系统迁移设计方案一、概述随着技术的不断发展，企业往往面临着将旧的应用系统迁移到新的平台或环境中的需求。
应用系统迁移设计方案是为企业提供有效的指导和规划，确保系统迁移的顺利进行。
本文将详细介绍一种典型的应用系统迁移设计方案。
二、项目背景企业现有的应用系统已经运行多年，系统性能较低，无法满足日益增长的业务需求。
为了提高系统性能和稳定性，企业决定将应用系统迁移到云平台上。
迁移后的系统将能够实现弹性伸缩、高可用性和备份恢复等功能。
三、迁移目标1.提高系统性能和稳定性2.实现高可用性和备份恢复3.方便系统扩展和升级四、迁移策略1.采用云平台选择一家可信赖的云服务提供商，搭建适合企业需求的云平台。
云平台应提供虚拟机、存储、数据库等基础服务，同时支持弹性伸缩、高可用性和备份恢复等功能。
2.数据备份在迁移前，对现有系统的数据进行完整备份，以保证数据的安全和完整性。
同时，建立定期备份和灾难恢复机制，确保系统在遭受意外情况下能够迅速恢复。
3.重构应用程序根据迁移目标和云平台的特点，对现有的应用程序进行重构。
重构应用程序需要考虑以下几点：-将应用程序解耦，将原来的单体应用拆分为模块化的服务，以实现高可用性和容错能力。
-将应用程序从物理机环境中解脱出来，将其部署到云平台上。
-使用云平台提供的弹性伸缩功能，在业务高峰期自动扩展系统资源。
-针对系统瓶颈进行优化，提高系统的性能和响应速度。
4.迁移验证在重构完成后，进行系统迁移验证。
验证过程中需要检查系统是否按照预期的方式运行，并根据实际情况进行调整和优化。
五、项目计划1.迁移前准备-确定迁移的目标和需求，制定详细的迁移计划。
-评估云平台供应商的性能和稳定性，选择最适合的供应商。
-建立充分的沟通渠道，确保所有相关方的共识和理解。
2.数据备份和迁移-进行完整备份，确保数据的安全和完整性。
-将备份数据迁移到云平台上，确保数据迁移的正确性。
3.应用程序重构和迁移-根据迁移策略进行应用程序重构。
系统迁移方案
1. 1 系统数据迁移方案1.1.1 存储设备之间的复制利用存储设备上的复制软件，在源存储设备和目标存储设备之间进行直接的数据复制。
示例：在两台XP磁盘阵列之间用Continuous Access软件进行数据复制。
适用范围：源存储设备与目标存储设备必须是同种存储设备；源主机与目标主机必须是同种操作系统优势：复制效率最高；无须主机参与分；停机时间短劣势：适用范围最小基本步骤：配置目标存储设备建立源设备与目标设备的复制关系数据复制源主机停止应用运行断开复制关系目标主机接管目标存储设备目标主机启动应用运行1.1.2 基于主机的数据复制利用主机上的数据复制软件（包含的操作系统之内的如HPUX上的MirrorDisk，或者第三方的中间件如TDMF），在源存储设备和目标存储设备之间进行直接的数据复制。
示例：用一台主机上的MirrorDisk软件实现一台EVA5000到一台XP12000的数据迁移。
适用范围：源存储设备与目标存储设备可以是同种或者异种存储设备；源主机与目标主机必须是同种操作系统。
优势：停机时间短复制效率较高劣势：需要主机参与限制条件较多基本步骤：配置目标存储设备在主机上安装复制软件建立源设备与目标设备的复制关系数据复制源主机停止应用运行断开复制关系目标主机接管目标存储设备目标主机启动应用运行1.1.3 基于应用层的数据迁移从源数据中抽取逻辑数据到中间文件，然后在目标主机上利用应用软件读取数据中间文件，并在目标存储设备上重建目标数据。
示例：在一台AIX主机上从一台FastT500上的DB2数据库中抽取数据到文本文件，并通过FTP传送到一台HPUX主机上，HPUX主机读取该文本文件，并把数据插入到Oracle数据库中。
适用范围：源存储设备与目标存储设备可以是同种或者异种存储设备；源主机与目标主机可以是同种或者异种操作系统。
优势：适用范围最宽劣势：需要设计专用的数据迁移软件；需要较长的停机时间。
基本步骤：配置目标存储设备源主机停止应用运行在源主机上抽取应用数据到文本文件中把文本文件复制到目标主机在目标主机上读取文本文件，并插入到目的系统中目标主机启动应用进行测试目标主机启动应用运行1.1.4 基于主机的数据复制迁移方案Tapestry数据迁移管理器（DMM）是一个简单而强大的数据迁移工具，可提供高效的异构数据迁移，为用户提供了更多的存储灵活性，降低了成本。
系统迁移的解决方案
系统迁移的解决方案系统迁移是指将现有的系统或应用迁移到新的平台或环境中。
这种迁移可能涉及硬件和软件的更新、升级，也可能涉及整个系统的重构或重新设计。
无论迁移的规模和复杂程度如何，都需要一套有效的解决方案来确保迁移过程顺利进行，同时保证新系统的稳定性和可靠性。
系统迁移的解决方案通常包括以下几个方面：需求分析和规划、方案设计和实施、风险评估和应对，及迁移后的测试和验证。
在下文中我们将介绍这些方面，并提出一系列实用的建议和经验分享。
需求分析和规划在进行系统迁移之前，首先需要进行一次全面的需求分析，以了解迁移的目的和范围。
这就需要深入了解现有系统的情况，包括其架构、功能、性能、安全性、可靠性等各个方面。
同时还需要关注迁移后的目标系统，包括新平台或环境的技术特点、性能特征、系统要求等。
在需求分析的基础上，制定详细的迁移规划。
这就需要明确定制迁移的目标和计划，制定迁移的时间表和步骤，明确各个阶段的任务和责任人，以及所需的资源和预期风险。
需要注意的是，迁移规划应该是一个逐步的过程，需要逐步细化，不断优化。
方案设计和实施系统迁移的方案设计和实施是迁移过程中最为关键的环节。
在方案设计阶段，需要结合需求分析的结果，确定全面的技术解决方案。
这就需要考虑现有系统的特点和要求，并结合新系统的特点和环境，制定出最为合适的方案。
在实施阶段，需要以方案设计为基础，进行实际的迁移操作。
这就意味着可能需要对系统进行重新搭建，或对现有系统进行升级、替换或重构。
无论是哪种情况，都需要严格按照规划和设计的步骤进行，确保迁移的过程稳定、有序进行。
需要注意的是，在系统迁移的方案设计和实施过程中，可能会涉及到大量的技术问题，包括系统架构、数据迁移、应用集成、性能调优、安全设置等。
这就需要技术人员具备全面的技术理论知识和丰富的实践经验，以保证迁移过程的有效实施。
风险评估和应对系统迁移的过程中，难免会面临各种风险和挑战。
因此，在迁移的整个过程中，需要进行全面的风险评估和应对。
服务器迁移中的操作系统升级与迁移
服务器迁移中的操作系统升级与迁移在服务器迁移过程中，操作系统的升级和迁移是一个重要的环节。
本文将重点讨论服务器迁移中操作系统升级与迁移的相关内容，包括迁移前的准备工作、迁移过程中的注意事项以及升级后的配置与验证。
一、迁移前的准备工作在进行服务器迁移之前，必须对目标服务器上的操作系统做好备份，并确保备份的完整性和可恢复性。
同时，还需要考虑以下几个因素：1. 确定目标操作系统版本：根据实际需求和系统要求，选择合适的操作系统版本。
考虑到软件兼容性和稳定性，建议选择当前较为稳定和成熟的版本。
2. 确定迁移方式：根据实际情况选择合适的迁移方式，包括物理迁移和虚拟机迁移。
物理迁移适用于服务器硬件更换的情况，而虚拟机迁移适用于同一硬件平台上的操作系统迁移。
3. 准备迁移工具和介质：根据选择的迁移方式，准备相应的迁移工具和介质，如硬盘克隆工具或虚拟机迁移工具。
二、迁移过程中的注意事项在进行操作系统升级和迁移时，需要注意以下几个关键点：1. 数据备份与迁移：在升级和迁移操作系统之前，务必对重要数据进行备份，并在迁移后进行数据的验证和恢复。
2. 网络连接与配置：在迁移过程中，要确保目标服务器与其他服务器或网络设备之间的连接正常。
检查网络配置，并根据需要重新配置网络参数。
3. 应用程序兼容性：在迁移过程中，需要验证应用程序在新操作系统上的兼容性。
如有必要，进行相应的调整和配置。
4. 安全性考虑：在迁移过程中，注意确保系统的安全性。
更新或配置防火墙、安全补丁等安全机制，以保护服务器免受潜在的网络威胁。
三、升级后的配置与验证完成操作系统的升级和迁移后，需要进行相应的配置和验证工作，以确保服务器的正常运行。
1. 更新系统补丁：安装最新的操作系统补丁，以修复已知的漏洞和缺陷，提高系统的稳定性和安全性。
2. 配置系统参数：根据实际需求和性能要求，适当调整系统参数，如内存、磁盘空间、网络参数等。
3. 验证系统功能：对服务器的各项功能进行验证，包括网络连接、存储访问、系统日志等。
系统迁移的解决方案
系统迁移的解决方案随着信息技术的不断发展，企业的业务应用系统也需要不断升级和迁移。
系统迁移是指将已有的应用系统从一个平台或环境迁移到另一个平台或环境，例如从物理服务器迁移到虚拟化环境，从传统的本地数据中心迁移到云平台等。
系统迁移可能是由于硬件设备的老化、业务需求的变化、厂商推出新版本等原因所导致的。
无论是哪种原因，系统迁移都需要谨慎和周全的规划，以确保迁移过程顺利、效率高，同时保证数据的安全和完整性。
本文将针对系统迁移的解决方案进行讨论，涵盖了系统迁移前的准备工作、迁移方案的选择、迁移过程中的风险控制、以及迁移后的监控和维护等方面。
希望通过本文内容的分析和总结，读者能够更好地了解系统迁移的复杂性与挑战性，并在实际工作中更好地应对系统迁移过程中出现的问题。
一、系统迁移前的准备工作1.确定迁移的目的和需求在进行系统迁移之前，首先要明确迁移的目的和需求。
企业可能会追求成本的节约、性能的提升、可扩展性的增强等不同的目标。
明确迁移的目的和需求，有助于选择合适的迁移方案，避免迁移后出现不必要的问题。
2.进行风险评估和成本估算在进行系统迁移之前，应当对迁移过程中可能出现的风险和成本进行评估。
迁移过程可能会导致业务中断、数据丢失、系统性能下降等问题，因此需要提前评估并制定相应的应对措施。
同时，对迁移可能带来的成本进行估算，有助于制定合理的迁移预算。
3.制定详细的迁移计划在进行系统迁移之前，需要制定详细的迁移计划，包括迁移的时间表、迁移的步骤、迁移的人员和资源等。
迁移计划需要充分考虑到业务的需求和实际情况，确保迁移过程可以顺利进行。
4.进行数据备份和恢复方案的制定在进行系统迁移之前，应当对现有系统的数据进行备份，并制定恢复方案。
数据备份是保证迁移安全性和完整性的重要手段，因此需要对备份数据的可靠性和恢复性进行充分考虑。
5.确定迁移的技术平台和工具在进行系统迁移之前，需要确定迁移的技术平台和工具。
不同的迁移目标和需求可能需要选择不同的迁移工具和技术平台，因此需要根据具体情况进行选择和评估。
系统迁移的解决方案
系统迁移的解决方案一、系统迁移的背景和意义随着科技的不断发展，企业在市场竞争中需要不断更新自己的信息化系统，以满足业务发展的需要。
系统迁移是企业信息化系统升级或迁移的过程，对于企业来说是一项重要的决策和工作。
合理的系统迁移可以带来更高效、更稳定的信息系统，提高企业的竞争力和生产效率。
因此，如何实现顺利的系统迁移成为了企业关注的焦点。
二、系统迁移的挑战和风险系统迁移是一项复杂的工程，可能会面临很多挑战和风险。
主要表现在以下几个方面：1.数据迁移：数据是企业的核心资产，而且往往存在大量的历史数据需要迁移。
数据迁移可能面临数据格式不一致、数据量巨大等问题，需要保证迁移过程中数据的完整性和准确性。
2.系统兼容性：新系统与旧系统的兼容性是一个重要问题。
新系统可能与旧系统的硬件、软件环境不完全一致，需要保证新系统能够正常运行并且与其他系统协同工作。
3.迁移成本：系统迁移可能需要购买新的软硬件设备、进行员工培训等，可能需要耗费大量的资金和人力资源。
4.业务中断：系统迁移期间，企业的业务可能会受到一定的影响，需要尽量减少业务的中断时间，降低对业务的影响。
5.安全风险：系统迁移可能会导致信息安全的风险，需要确保迁移过程中数据的安全性，避免数据泄露或丢失。
面对这些挑战和风险，企业需要制定合理的系统迁移方案，以应对各种可能的问题。
三、系统迁移的解决方案1.系统迁移规划与准备系统迁移之前，企业首先需要进行充分的规划和准备工作。
这包括以下几个方面：（1）明确迁移目标：企业需要明确系统迁移的目标，包括为什么要进行迁移、迁移后希望达到什么样的效果等。
（2）评估旧系统：对企业旧系统进行充分的评估，了解旧系统的特点、优缺点、存在的问题等，为制定迁移方案提供依据。
（3）沟通和协调：系统迁移需要涉及到多个部门和岗位，需要加强沟通和协调，确保各个部门的利益得到平衡，提高迁移的顺利进行。
2.数据迁移数据迁移是系统迁移的关键环节，可能是最为复杂的工作之一。
oa系统迁移实施方案
oa系统迁移实施方案OA系统迁移实施方案。
一、背景。
随着企业发展和业务需求的变化，原有的OA系统已经无法满足当前的业务需求，因此需要进行系统迁移和升级。
二、目标。
1. 实现OA系统的平稳迁移，确保业务不受影响；2. 提升OA系统的性能和稳定性，满足企业日益增长的业务需求；3. 确保迁移后的系统能够更好地支持企业的管理和决策。
三、迁移方案。
1. 确定迁移时间节点，在业务低谷期进行迁移，最大程度减少对业务的影响；2. 制定详细的迁移计划，包括迁移的具体步骤、时间安排、人员分工等；3. 确保数据安全，在迁移过程中，要对数据进行备份，并确保数据的完整性和安全性；4. 迁移测试，在正式迁移之前，进行系统迁移的测试，确保迁移后系统的正常运行；5. 培训和支持，对迁移后的新系统进行培训，确保员工能够熟练使用新系统，并提供必要的技术支持。
四、实施步骤。
1. 系统评估和准备，对当前的OA系统进行评估，确定需要迁移的内容和数据；2. 迁移计划制定，制定详细的迁移计划，包括时间安排、人员分工、数据备份等；3. 数据备份，在迁移前，对现有系统的数据进行备份，确保数据的完整性和安全性；4. 系统迁移，按照迁移计划，进行系统迁移，包括数据迁移、软件升级等；5. 系统测试，对迁移后的系统进行测试，确保系统的正常运行；6. 培训和支持，对员工进行新系统的培训，并提供必要的技术支持；7. 系统上线，迁移完成后，将新系统正式上线运行。
五、风险和对策。
1. 数据丢失风险，在迁移前进行充分的数据备份，确保数据的安全性；2. 系统运行不稳定，在迁移后进行系统测试，及时发现和解决系统运行的问题；3. 员工适应不良，提前进行系统培训，确保员工能够快速适应新系统的使用。
六、总结。
OA系统的迁移是一项复杂的工程，需要充分的准备和周密的计划。
通过本次迁移实施方案的制定和执行，我们将确保OA系统的平稳迁移，提升系统的性能和稳定性，为企业的发展和管理提供更好的支持。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
广研的搬迁方案
方案三： ✓ 同样需要架设一套基本与现有QQMAIL相同的系统：在
广州架设服务器，安装QQMAIL应用模块(WEBMAIL、 SMTP/POP3等)； 在深圳枢纽架设服务器，安装QQMAIL后台存储； ✓ 利用枢纽带宽，把旧系统数据同步到枢纽新存储上； ✓ 搬迁安装后台存储的服务器到广州，修改广州新系统 的配置，让应用与后台存储完成接合 ✓ 再使用工具软件进行深广新旧系统数据增量同步； ✓ DNS切换，新系统提供服务；
广研的搬迁方案
方案二： ✓ 在广州IDC机房架设基本满足QQMAIL系统运营和存所
有QQMAIL数据的设备 ✓ 在新设备上架设QQMAIL应用 ✓ 使用工具软件让深圳与枢纽的数据进行同步 ✓ 保证两地数据一致和应用一致后，修改DNS指向 ✓ QQMAIL服务由广州设备接替
一次迁移所有用户数据，操作时间长，风险不可控， 没长期需要而临时扩充带宽浪费资源
Server Client
10个1.0 9个1.0 7个1.0 10个1.1 …
1个1.1 3个1.1
100万1.0 100万1.0 90万1.0 …
…
n个1.1 10万1.1
Dayn
10个1.1 100万1.1
小版本迭代升级
单机软件发布
时间 W1 W2 W3 W4 W5 W6 W7 W8 W9 … Wn 单机 α1 α2 α3 α4 α5 α6 α7 α8 α9 … αn
Client屏 蔽v1.1特
性
Server假 装v1.0
同时包括 v1.0和v1.1 的逻辑代码
“协议跑得比server快，server跑得比client快”
QQServer代码例子
int CheckPassword(CONFIG* pstConfig, char *sPasswdHash, char *sMd5Value) {
谢谢
β版本
系统测试
β1
时间跨度大，bug多
β2
Full Testing
β3
时间窗
R
快速验证
R1
R2
时间短，bug少
Day1(1%-10%) Day2(10%-20%)
Dayn(20%-100%)
“时间剪载功能”
灰度割 接
总结
➢迁移 避免物理搬迁 减少物理复制 由应用做平滑扩容
➢升级 多版本兼容 灰度割接 小版本迭代
➢ 方案：用10Mbit的网络带宽分批传输5Gbytes的数据，计划 数据传输需要时间1个多小时，共停止系统3个小时，结果…
网络质量抖动，传输用了3个多小时 数据倒入数据库，完成倒入接近85%时，数据库崩溃 数据库修复用了3个多小时 继续倒入直到完成为止(幸运的是当时设备及数据库都没有大的损坏)
物理搬迁，容易做成物理损坏 任一台机器物理损坏都会导致迁移失败
总结广研的方案
物理搬迁，风险大，而且劳民伤财。
在线系统平滑升级
在线系统升级要求
➢尽量保持7×24小时服务 ➢用户不受任何影响或影响很小
DB平滑扩容
➢QQGame的DB分裂，不需停止用户的游戏过程
Db11 db12
db12
S1
S2
➢请用5分钟设计一个平滑扩容的方案
如果事情可能出错，就一定会出错。
一刀切迁移？
旧client 旧Server
旧DB
有BUG会导致 数据丢失、 支撑不了压
力
一刀切
旧系统
➢结果是…
➢回滚 ➢新系统无法上线测试
数据库缺少 必要数据
新client 新Server
新DB 新系统
失败案例 (2)
➢ 某美国软件开发商给日本网络运营商开发了新的邮件系统，需要用新 的系统替换旧的系统
盒装软件 发行软件
β1 一旦出错，β2付出
的成本非常高
build50 次 固定时间 出β版
制作光盘， RTM
“千里走钢丝”
β3 Goldenβ
代码越多，出 错的机会越大
网络软件快速验证
时间 W1 W2 W3 W4 W5 W6 W7 W8 W9 … Wn α版本 α1 α2 α3 α4 α5 α6 α7 α8 α9 … αn
Client v1.0
Server v1.0
Client v1.1
Server v1.1
➢请用5分钟设计一个多版本兼容方案
多版本支持
Client v1.0 1.0逻辑
Server拒 绝非v1.0
特性
Server v1.0 1.0逻辑
Client v1.1 1.0逻辑 1.1逻辑
Server v1.1 1.0逻辑 1.1逻辑
深圳电信枢纽机房
2M专线
➢23台备用机器 广州电信较场西机房
➢ 请用15分钟设计一个系统搬迁方案
提纲
搬迁和割接的风险 广研的搬迁方案 在线系统平滑升级 小版本迭代升级
迁移割接的目标
➢用户体验更好 ➢减低搬迁的费用及风险 ➢不采用任何可能做成错误或损失的迁移方式
搬迁和割接的风险
设备迁移?
错综复杂 的机房
在线系统迁移与升级
练习题
➢ QQMAIL系统提供 @ 域名的邮件服务，原来是的网站部维护， 后来转由广州研发中心维护
➢ 广州研发中心为了日常维护方便，建议将QQMail从深圳枢纽机房搬迁 到广州电信较场西机房
➢注册用户约6千万 ➢开通用户数约4千万 ➢邮件存储总使用空间约13T ➢64台在用机器
➢多版本不兼容 ➢RTX3.61和RTX2005
➢多版本兼容 ➢QQServer ➢QQGame
RTX2005不 兼容 RTX3.61
✓ QQServer支持超 过100个Client版 本
✓ QQGame支持超过 6个Client版本
灰度割接
旧client
5%
19050%%
旧Server
先割一少部 分用户
…
if (pstConfig->stCinfo.shVersion < 900) {
if (OicqDecrypt3(…)) {
… } else return 0; } else { if (OicqDecrypt3(…)) {
… } else return 0; }
return 1; }
多版本支持
IDC1
IDC2
➢结果可能是…
拨错线（电线、网线） 整柜跳线 搬错设备 运输过程摔坏
物理设备搬迁
数据迁移？
有限的专 线网络带
宽
IDC1
海量的数 据
IDC2
➢结果是…
全套的设备投入
漫长的等待
复杂的增量同步
不可遇见的风险
失败案例 (1)
➢ 某运营商原来的用户数据是集中式处理，需要按省处理，新 系统在各省已建设完成，需要通过网络进行数据迁移操作。
旧系统
➢好处是…
再用少部分 用户压力， 方便测试新
系统
➢用户体验影响最小 ➢设备投入少
➢不存在大风险，随时可以回滚
➢容易对新系统的测试及问题定位
新client 5%
新Server
新系统
灰度割接
Hale Waihona Puke ➢分时间的逐步升级步骤➢有10台server ➢有100万个client
Day1 Day2 Day3 Day4 …
新系统存在bug是难以避免。
广研的搬迁方案
广研的搬迁方案
方案一： ✓ 搬迁前准备，QQMAIL数据与应用完成备份； ✓ QQMAIL系统停服务； ✓ 修改DNS指向； ✓ 设备停机、下架、装车、由深圳搬运至广州、上架、
开机； ✓ QQMAIL在广州重新架设，重新提供服务；
没回退性，风险太大，绝对不可行
DB平滑扩容
➢QQGame的DB分裂
只读不 改
Proxy
修改路由 指到新的 DBSrv
作应用级 Cache
DBSrv11/12
DBSrv12
Insert 到DB
Db11 db12
db12
后台同步迁移(insert)
S1
S2
主键 保证 唯一
多版本支持
➢QQGame软件版本升级，不需强制用户升级Client