Ychun

网易游戏高级运维工程师，负责多个游戏产品的运维工作；关注自动化、容器、业务全链路监控等领域

背景介绍

本文开始之前，总结一下传统数据库更新比较经典的对话，如下：

Q：小杨同学，DB更新脚本执行失败，麻烦看看
A：查看日志后，sql文件没有use db语句

Q：小杨同学，DB更新脚本已经执行完毕，怎么数据没有更新呢？
A：没修改version.txt文件，qa更新还是按照旧的sql文件进行更新

Q：小杨同学，QA刚把sql文件执行顺序弄错了，可能需要恢复数据重新更新
A：需要从备份恢复数据

Q：小杨同学，QA刚重复更新了一个sql文件，不知道有没有问题
A：需要花一些时间去review sql脚本，定位重复更新是否有问题

Q：小杨同学，麻烦更新下苹果/安卓审核服的DB，几个月没更新需要补好几个版本
A：得查下外服最近的更新记录，慢慢补上……

数据库更新，一直是运维人员重点关注的工作之一，因此数据库更新的目标要达到：避免重复更新，漏更新，更新顺序错乱；能够记录更新历史，确保更新有迹可查；sql 符合一定的规范，以便于自动执行和处理。

传统数据库更新现状：维护一个 version.txt(记录更新目录 /sql 文件更新顺序) 文件，sre 编写数据库更新脚本，每次都要设定一个比较复杂的更新流程：和程序约定好 sql 文件命名规范 -> 程序上传 sql 文件 -> 特定服务器下载文件到指定目录 -> 数据库备份 -> 更新脚本执行数据库更新 -> 有问题排查或用备份恢复，而且还有各种意料之外的事情发生，在有限的维护时间内处理其实是有相当大难度。

传统数据库更新痛点：

1）程序忘记修改 version.txt 文件；

2）程序 sql 文件忘记添加 use db 语句；

3）程序误删相关目录或者文件；

4）qa 没有按照顺序更新或者重复更新；

5）sre 需要花很多时间分析 sql 内容定位问题并恢复数据；

开源数据库管理工具 Flyway 可以轻松完成数据库版本更新功能，解决传统数据库更新的痛点，而且能够做到：

1）不会重复更新；

2）更新顺序不会发生错乱；

3）能够记录更新历史；

4）数据库更新版本能够和程序版本一一对应；

Flyway 工作原理

Flyway 的每个更新叫做一个 migration，在执行 migration 的时候会指定更新哪个数据库，然后去对应的目录寻找 sql 文件来进行更新。Flyway 会自动在数据库中新建一个名为 "flyway_schema_history" 的表（备注：Flyway V5.0 之前的版本，表名叫做 schema_version），该表会记录当前已更新的 sql 信息，下次会接着按照 sql 版本的顺序往下更新，如下所示：

上图 table 中的部分重点列的数据的含义：

• version：不同的版本号

• description：本次版本更新的描述，按照 sql 文件命名规范，从 sql 文件名中提取的内容

• script：执行的脚本名

• installed_by：执行脚本的数据库用户名

• installed_on：开始执行 sql 的时间

• execution_time：脚本执行时间 (毫秒 )

• success：执行结果，1 表示执行成功

flyway 根据 flyway_schema_history 表中的信息记录，在每次执行 migtation 的时候，只执行之前没有执行过的 sql，并且按照 Vsersion 的顺序执行；要使 flyway 能够获取到上图 table 中的相关信息，sql 目录结构和 sql 文件命名必须满足其规范 ;

1）目录结构

-/flyway/sql/
|-- database_01/                   #  以数据库名命名的目录
|   |-- V1__initial.sql            #  按照 sql 命名规则命名的 sql 文件，下同
|   |-- V2__first_changes.sql
|   |-- V3__add_tables.sql
|   |-- V4__init_data.sql
|-- database_02/                   #  以数据库名命名的目录
|   |-- V1__initial.sql            #  按照 sql 命名规则命名的 sql 文件，下同
|   |-- V2__modify_columns.sql
|   |-- V3__add_user_tables.sql
|   |-- V4__init_data_for_user.sql
...                                #  可以有多个数据库，按照上面的范例定义即可

2）sql 文件命名规范

sql 文件名必须严格按照本规则命名，否则将会无法更新！

格式：
V[Version]__[Description].sql

#  以大写的 V 开头，小写的 .sql 结尾；
# Version：数字和小数点组成的版本号，由用户自行定义，不能有字母！！！按大小顺序递增。例如：1/2/3/3.1/3.2/3.2.1/3.2.2 等
# Description：对本 sql 文件的描述信息。
# Version 和 Description 之间用两个下划线 "__" 隔开。
#  样例：
  V1__initial.sql
  V2.1__first_changes.sql
  V3.1.1__add_tables.sql

项目实战

本文主要介绍的是 mysql 数据库使用 flyway 的实战经验；

程序操作指引

操作指引

1）将DB的sql文件与服务端版本文件一起提交，并严格遵守上述的目录结构和sql文件名规范要求；
2）sql文件内容中不需要用use语句指定数据库；
3）sql文件内容采用增量修改的方式提交，尽量不要有drop table再create table的语句，避免误删数据（除了非常确定该表中的数据无用！）；
4）如果提交到svn中的sql文件已经被更新到了任一个游戏服，此sql文件不可再修改或删除；
5）sql文件内容，事务数量越小越好，避免sql执行部分失败后，需要回滚相关操作；

注意事项

#重要的事情说三遍
一般情况下：
只增量添加sql文件，不要删除和修改！
只增量添加sql文件，不要删除和修改！！
只增量添加sql文件，不要删除和修改！！！

只有一种例外情况可以删除或修改一个已经提交到svn的sql文件：该sql文件提交到svn之后尚未更新到任何游戏服，因为按照Flyway的更新逻辑，DB更新是以sql文件为粒度的，在DB更新之前的sql内容修改是没有关系的；但是如果一个sql文件已经更新到某个服务器，再去修改它，那么再次修改的内容将不会在该服务器上被执行。

SRE 操作指引

Flyway 安装部署

官方文档：https://flywaydb.org/documentation/commandline/#download-and-installation

version=5.2.4  #  可以在 Flyway 官网查看最新的版本号，此处以当前（2019.06.06）的最新版本为例。
cd /home/xxxx
wget -qO- https://repo1.maven.org/maven2/org/flywaydb/flyway-commandline/${version}/flyway-commandline-${version}-linux-x64.tar.gz | tar xvz
sudo ln -s `pwd`/flyway-${version}/flyway /usr/local/bin

Flyway 的默认配置文件：

vim flyway-${version}/conf/flyway.conf
flyway.url=jdbc:mysql://host:port/dbname?useSSL=false
flyway.user=xxxxx
flyway.password=xxxxxxxxx

Flyway 执行可以使用以下两种方式：

1）直接在 flyway 命令行中直接加上参数，无需配置文件；

2）在配置文件中指定好默认的配置，无需参数；

Flyway 更新 DB 指令

方法一：指定 schemas 来更新。Flyway 从默认目录 （ flyway-version/sql/{database}） 来读取 sql 文件

#  同步 sql 版本文件到 Flyway 默认 sql 目录
rsync -azL --delete ${updating_dir}/ /home/${project_user}/flyway/sql/${database}/

#  执行 migrate 指令
flyway -baselineOnMigrate=true -baselineVersion=0 -schemas="${database}" -user="${user}" -password="${password}" -url="jdbc:mysql://${host}" migrate

方法二：直接指定 sql 目录来更新。直接指定 locations 参数【推荐】

#  在参数中指定 sql 文件的位置，直接执行 migrate 指令
flyway -baselineOnMigrate=true -baselineVersion=0 -user="${user}" -password="${password}" -url="jdbc:mysql://${host}" -schemas=${database} -locations=filesystem:/home/xxx/server/database/htdocs_local/db/alter/stg/ migrate

备注：两者并无本质差异，推荐使用方法二直接参数中指定 locations 的方式，少了一步 rsync，减少出错概率。

参数说明：

1、-baselineOnMigrate=true ：表示如果当前DB未使用Flyway的话，以当前DB版本为基线版本
2、-baselineVersion=0：指定基线的版本，第一次使用 flyway 的时候指定为0，之后可以指定为当前版本，当前版本参考 flyway_schema_history 中的记录。
3、-schemas：数据库名
4、-locations：sql文件目录
5、migrate：对DB进行migrate更新
6、-user -password -url：用户名、密码和数据库访问地址信息

更新流程

1、程序按照Flyway规范提交新版本的sql文件；
2、提交阿拉丁流程来更新DB；
3、DB Client机器上备份数据库；
4、DB Client机器上下载新版本的sql文件；
5、执行Flyway进行DB更新；
6、如有报错，则进行排查并修复后重新更新；

问题排查

sql 文件的 checksum 不一致

原因：sql 文件被更新之后，文件内容进行了变更，再次执行更新会有这个报错 ;

解决方法：执行 flyway repair;

flyway -baselineOnMigrate=true -baselineVersion=0 -user="${user}" -password="${password}" -url="jdbc:mysql://${host}" -schemas=${database} repair

sql 文件描述不一致

原因：sql 文件被更新之后，文件名有变更 ;

解决方法：修改 flyway_schema_history 表中该 sql 文件对应的 description 字段 ;

Migration V6.7__xxx_xxx.sql failed

原因：sql 文件内容执行失败 ;

解决方法：根据 Flyway 输出的 Error Message 进行对应处理即可 ;

#注意：
1）如果对这个sql回滚，然后修改后重新提交的话，需要删除flyway_schema_history表中的该行记录;
2）如果修改内容后重新执行的话，需要执行repair指令修复下checksum；
3）如果手动执行完毕该sql内容的话，需要在对应的flyway_schema_history表中将该行的success字段改为true；

Validate failed: Detected failed migration to version 6.7

原因：该 sql 文件之前已经更新过，但是执行失败了 ;

解决方法：灵活处理 flyway_schema_history 表 ;

#注意：
1）如果对这个sql回滚，然后修改后重新提交的话，需要删除flyway_schema_history表中的该行记录;
2）如果手动执行完毕该sql内容的话，需要在对应的flyway_schema_history表中将该行的success字段改为true；

Validate failed: Detected resolved migration not applied to database: 2.7

原因：该版本的 sql 之前已经通过 Flyway migrate 更新过，但是新版本中该文件被删除了，导致验证不通过；

解决方法：flyway_schema_history 将该记录删除，或者在 flyway 命令中加上跳过这个验证的参数：-ignoreMissingMigrations=true；

WARNING: DB: Duplicate index 'idx_flyway_a_index' defined on the table 'sbtest.sbtest1'. This is deprecated and will be disallowed in a future release. (SQL State: HY000 - Error Code: 1831)

原因：理由不明，索引是正确添加的，但是会有 WARNING；

解决方法：不用处理 , 可以忽略；

总结

规范化管理业务变更一直是 sre 工作目标，数据库做为业务的核心，业务 sre 理应管控全局，对其进行规范化的管理，避免各种误操作带来的问题或故障。多个项目数据库更新使用 flyway 后，传统数据库更新带来的痛点不会再变为 sre 的负担，而且能够高质高效的完成每一次变更。

谨防！Post 打爆 /tmp 分区

DevOps之Gitlab-CICD实践篇

iOS 消息推送那些事儿

Dockerfile最佳实践

ceph部分数据所有副本先后故障的抢救