抱歉,您的浏览器无法访问本站
本页面需要浏览器支持(启用)JavaScript
了解详情 >

起因

前段时间在鼓捣数据表的数据上线,主要流程是将线下的数据同步到线上去,线上的部分需要需要和线下保持一直,并且每一次操作都需要自动化将表进行备份, 这个过程主要是靠自己进行代码同步,因为规则比较自定义,所以没有使用一些现有的数据同步。

主要流程如下:

1
2
3
4
5
6
7
8
9
- #备份NX的SCHEMA中的表并查询特定数据进行备用
NX-SCHEMA: 备份NX-TABLE ==> NX-TABLE_COPY ==> SELECT * FROM NX-TABLE_COPY WHERE ID =xx

- #备份JAPAB的SCHEMA中的表并且将上一步的数据写入到备份表中
JAPAN-SCHEMA: BEFEN JAPAN-TABLE ==> JAPAN-TABLE_COPY ==> INSERT INTO JAPAN-TABLE_COPY VALUE (xxx)

- #将JAPAN的SCHEMA中的原表和备份表进行重命名,将备份表的表名变成源表名,完成数据上线
JAPAN-SCHEMA: JAPAN-TABLE ==> RENAME JAPAN-TABL XXX ==> RENAME JAPAN-TABLE_COPY TO JAPAN-TABLE

在这个过程中,我们最主要的一步是在同一个schema下进行将原表进行备份,创建一个对应的不同表,后续所有的操作都改这个表中操作,在这个过程中也是出现了一些问题,后续经过实践后解决了相关问题,特此记录。

经过

我们在备份源Schema中的table时,直接采取了简单粗暴的SQL语句,如下:create table table_name_copy as select * from table_name,该SQL实现了创建table_name_copy并且将table_name中的数据也插入到对应的新表中,
看似满足了我们的需求:朴素的备份源表,不进行任何操作。

然而,简单的事情总是不会那么简单,在我们进行数据比对时,发现数据没啥问题,但是在校验表的DDL时,发现麻烦稍微有点大,此次备份基本没用,因为此时我们的表的主键、索引等等都丢失了,然后我们再查询相关的文档,发现弊端还挺多。

然后在此上进行了改进,先根据ddl创建表的结构,然后再讲数据导入进来,这样就避免了锁、和索引等问题。SQL如下:

1
2
3
4
5
6
7
8
9
10
第一步:创建表结构

方法一: 按照老表的结构创建新表
create table new_table like old_table;
方法二: 此种方法是先获取ddl,然后再修改表名再次执行DDL,进行表结构创建
SHOW CREATE TABLE old_table;

第二步:同步原表数据
INSERT INTO new_table SELECT * FROM old_table;

备份表的结构和数据都还是比较简单,但是这个只适用于少量数据的备份,大量数据的备份暂时还没有进行实践,我们大量的数据备份一般使用CSV或者ETL进行同步。

结果

在同步表结构的过程中出现了一些小的插曲,但是还是圆满的解决了问题,在严格检查的前提下发现了问题,在没有发生故障的情况下及时止损,以后的相关内容也是需要多查文档,锁看看原理,严格进行数据和DDL校验,发现问题速度处理,及时止损。

评论