车联网1.x至2.x数据库升级方案

部署文档

变更历史

引言

  目前企业现场大部分的车联网系统版本都是1.x，基于统一维护管理策略，要将1.x版本统一升级为2.x。在整个升级方案中，除了应用服务的升级，主要还涉及到1.x的数据迁移和数据转换等工作。其中大数据存储(hbase、hfds)等存储结构没有变动，无需升级。
  数据库迁移，保留原先1.x的库，2.x采用的新建的库名，然后通过迁移工具实现两库之间的数据转换与拷贝。

1. 部署前准备

1.1 功能清单确定

1.1.1 参与人员

项目经理： 高静

1.1.2 前置步骤

无

1.1.3 工作内容

项目经理经过和商务、客户进行沟通，达成一致意见，提供出2.x系统的功能清单 

1.1.4 工作目标

项目经理提供完整的功能清单

1.2 LOGO资源

1.2.1 参与人员

项目经理： 高静

1.2.2 前置步骤

无

1.2.3 工作内容

项目经理和开发确认，升级2.x需要的相关资源文件，比如图标，背景图之类的，然后和UI设计人员进行沟通，输出相关资源文件

1.2.4 工作目标

项目经理提供相关资源文件,交给开发人员

1.3 提供初始系统

1.3.1 参与人员

技术人员： 陈鹏

1.3.2 前置步骤

无

1.3.3 工作内容

采用最新的数据库脚本创建数据库，并采用当前最稳定的2.x版本，搭建2.x系统。提供系统地址给开发人员处理功能清单及用户权限的划分。

1.3.4 工作目标

提供2.x数据库及系统平台，满足开发人员处理功能清单，及Logo替换处理测试

1.4 根据功能清单调整菜单

1.4.1 参与人员

开发负责人：杨永刚 

1.4.2 前置步骤

* 1.1、1.2、1.3

1.4.3 工作内容

* 开发人员根据项目经理提供的功能清单，进行调整系统菜单。
* 开发人员使用项目经理提供的Logo图片，进行替换测试。

1.4.4 工作目标

提供2.x数据库及系统平台，满足开发人员处理功能清单，及Logo替换处理测试

1.5 准备并提供部署清单

1.5.1 参与人员

开发负责人：杨永刚 

1.5.2 前置步骤

无

1.5.3 工作内容

* 收集1.x升级2.x系统的应用清单，提供给QA及运维人员

1.5.4 工作目标

输出升级应用清单

1.6 现场外网端口提前开通

1.5.1 参与人员

项目经理：高静 

1.5.2 前置步骤

无

1.5.3 工作内容

* 向客户沟通，提前申请开通17070端口，指向WEB服务器（供测试人员核对数据用）

1.5.4 工作目标

提前开通外网端口

2. 数据库迁移阶段

2.1 停止必要服务应用

2.1.1 参与人员

运维人员：未定 

2.1.2 前置步骤

无

2.1.3 工作内容

停掉所有与数据库存在交互可能的应用服务，避免在迁移过程中，存在读写数据操作，导致产生不可预知的后果。涉及的应用服务包括如下：
* kafkaService 
* Openservice
* Storm
* SynService
* admin
* Spark
停掉以上服务，并不影响迁移过程的车辆接入，不会导致车辆实时数据丢失。

切记：一定要确认以上服务在迁移前关闭，所以停服务时必须再三确认服务是否已关闭。

2.1.4 工作目标

停掉所有和数据库存在交互的应用服务，避免迁移过程中存在读写操作

2.2 evsmc数据库备份

2.2.1 参与人员

DBA：崔明空 

2.2.2 前置步骤

2.1

2.2.3 工作内容

备份1.x的数据库，避免在迁移过程中，出现意外情况，导致数据丢失，造成不可挽救的后果 

2.2.4 工作目标

备份1.x数据库，应对意外情况

2.3 创建并初始化evsmc2库

2.3.1 参与人员

DBA：崔明空 

2.3.2 前置步骤

2.2

2.3.3 工作内容

* 创建evsmc2库，并使用开发提供的SQL脚本进行初始化数据库
* 创建ev2的mysql用户，权限为evsmc库仅读权限，evsmc2读写权限

2.3.4 工作目标

创建2.x数据库，并且提供2.x用户给数据迁移人员

2.4 数据库迁移

2.4.1 参与人员

技术人员：陈鹏 

2.4.2 前置步骤

2.3

2.4.3 工作内容

* 使用迁移工具，将1.x的数据库，处理之后拷贝到2.x数据库

2.4.4 工作目标

完成数据库升级迁移

3. 数据核对阶段

3.1 备份admin为admin1x

3.1.1 参与人员

运维人员：未定 

3.1.2 前置步骤

2.4

3.1.3 工作内容

• 拷贝1.x的admin为admin1x，即cp -rf /opt/web_app/admin /opt/web_app/admin1x
• 修改admin1x的tomcat端口，由原先的7070改为17070。（tomcat配置文件需要修改几个端口，避免和2.x的tomcat存在冲突。具体查询相关技术文档）
• 启动admin1x的tomcat
• 确认此tomcat开放的17070通过外网可以访问（供核对数据用）

3.1.4 工作目标

备份1.x的admin并启动，满足通过外网访问

3.2 部署2.x的admin

3.2.1 参与人员

运维人员：未定 

3.2.2 前置步骤

3.1

3.2.3 工作内容

• 部署QA提供的admin应用包，部署目录为/opt/web_app/admin
• 必须确保admin和admin1x目录/webapps/ROOT/WEB-INF/classes/redis.properties的配置项redis.database=x不能相同，不然会产生冲突。
• 启动admin的tomcat，确认能通过原先的8000端口能正常访问2.x系统

切记：数据库配置必须指向新库evsmc2

3.2.4 工作目标

备份2.x的admin并启动，满足通过外网访问，**并且将1.x和2.x系统的访问地址提供给测试人员**

3.3 核对数据

3.3.1 参与人员

测试人员：李丛丛 

3.3.2 前置步骤

3.2

3.3.3 工作内容

• 根据1.x升级2.x提测范围，进行数据核对；
• 动态数据核对不在此步骤进行

1.x系统： http://xxx.xxx.xxx.xxx:17070/
2.x系统： http://xxx.xxx.xxx.xxx:8000/

测试账号事先由项目经理提供，系统访问地址由运维人员提供

3.3.4 工作目标

确认数据库迁移之后，数据一致性得到保障

4 运维部署

4.1 配置及服务调整

4.1.1 参与人员

测试人员：未定 

4.1.2 前置步骤

3.3

4.1.3 工作内容

• 将openservice的数据库配置改为指向新库evsmc2
• 停掉/opt/web_app/admin1x服务

友情提示：旧版本的openservice没有读写数据库，如果是旧版本，则不需要处理

4.1.4 工作目标

提前处理，避免未升级的服务应用出现配置遗漏修改的问题。

4.2 根据清单部署2.x应用

4.2.1 参与人员

测试人员：未定 

4.2.2 前置步骤

4.1

4.2.3 工作内容

• 根据开发提供的部署清单，进行服务升级部署操作

4.1.4 工作目标

完成全部2.x相关服务升级    

4.3 确认服务状态

4.3.1 参与人员

运维人员：未定 

4.3.2 前置步骤

4.2

4.3.3 工作内容

全面排查一下各个服务的配置及运行状态，排查范围包括如下但不限于此：

• SaveService（启动可能会出现失败，特别关注）
• KafkaServie
• SynService（启动可能会出现失败，特别关注）
• 国标终端直连
• Storm：（之前部署由于各种原因，出现过几次服务不正常情况，特别关注）
• Openservice

4.3.4 工作目标

确保服务正常运行  

5 测试阶段

5.1 全面测试

5.1.1 参与人员

测试人员：李丛丛 
开发人员：郭良

5.1.2 前置步骤

4.3

5.1.3 工作内容

根据功能清单进行总体测试，测试应包括如下几点：

• 平台功能正常使用，不出现致命Bug
• 车辆直连接入功能正常使用
• 平台转发正常使用

5.1.4 工作目标

确保2.x平台正常运行  

6 验收阶段

6.1 项目经理确认

6.1.1 参与人员

项目经理：高静 

6.1.2 前置步骤

5.1

6.1.3 工作内容

测试完成后，由项目经理确认升级状态，项目经理工作应包括：

• 若系统存在部分不影响使用bug，应确认升级工作完成，Bug后续跟进修改。
• 若升级后，出现了严重问题，比如车辆无法接入及转发，项目经理和客户沟通，决定是回滚还是排查紧急处理bug
• 若升级完，一切正常，则升级工作结束

5.1.4 工作目标

针对升级后各种情况能够采取不同的措施，为升级工作提供有力支持。