5、一粒云二次封装与迁移 – 数据迁移分析

运维2023年1月13日

完成系统迁移测试后系统已经能够正常运行，经过1个月的稳定性测试后决定将老数据迁移到新的系统中。

老数据目前存放在一台80TB的戴尔EMC存储中并连接到ESXI服务器。80TB分成8块10TB的硬盘挂载到老一粒云的系统中。其中的FastDFS文件系统分成8个区域存储文件。经过统计其中存在20TB左右的数据。

在迁移时首先是必须保证数据安全性。另外经过沟通如果涉及到停机可以将后续需要上传的数据先暂存到客户机器上，但是不能太久。其次需要重新分配空间，原来的系统独占80TB，现在需要对半分，新系统使用40TB数据。

1、深入分析

为了保证迁移顺利和数据安全性，继续对系统进行深入分析。

数据库集中存放重要的数据与标记，所以查询数据库可以发现非常多的关键点。

mysql> show tables;
+------------------------+
| Tables_in_yliyun       |
+------------------------+
| associate_file_label   |
| chat_msg               |
| conv_file              |
| department             |
| dept_per               |
| ent_per                |
| enterprise             |
| favorite_file          |
| file_comment           |
| file_history           |
| file_praise            |
| forum                  |
| forum_assign           |
| forum_msg              |
| forum_msg_attach       |
| forum_sub              |
| fs_file                |
| fs_file_attr           |
| group_access           |
| group_file             |
| group_member           |
| group_sync_folder      |
| group_trash_file       |
| group_used_size        |
| knowledge_item         |
| knowledge_library      |
| knowledge_tag          |
| label_per              |
| labels                 |
| ldap                   |
| ldap_ou                |
| msg                    |
| msg_send               |
| nas                    |
| nas_hot                |
| nas_map                |
| nas_share              |
| personal_file          |
| personal_sync_folder   |
| personal_trash_file    |
| personal_used_size     |
| plugin                 |
| propertys              |
| public_file            |
| public_sync_folder     |
| public_trash_file      |
| rules                  |
| sequence               |
| server                 |
| share_file             |
| share_file_batch       |
| share_file_info        |
| space_config           |
| sys_config             |
| trans_department       |
| user                   |
| user_group             |
| user_online            |
| user_per               |
| v_department_used_size |
| v_dept_per             |
| v_ent_per              |
| v_file_dept_per        |
| v_file_praise          |
| v_file_user_per        |
| v_group_file_count     |
| v_group_member         |
| v_group_member_count   |
| v_group_share_file     |
| v_group_sync_folder    |
| v_group_trash_file     |
| v_group_used_size      |
| v_joined_group         |
| v_personal_share_file  |
| v_personal_sync_folder |
| v_personal_trash_file  |
| v_personal_used_size   |
| v_public_share_file    |
| v_public_sync_folder   |
| v_public_trash_file    |
| v_user                 |
| v_user_group           |
| v_user_per             |
| versions               |
+------------------------+
84 rows in set (0.00 sec)

mysql>

其中fs_file表非常可疑，从名字可以看出，这个表中也许存放了文件系统存储文件的标记。

mysql> select fs_file_id,file_name from fs_file limit 0,5;
+------------+-----------------------------------------------------+
| fs_file_id | file_name                                           |
+------------+-----------------------------------------------------+
|          1 | group1/M00/00/00/wKgAEmMYflSAdgwJAAAu9Am4McM53.docx |
|          5 | group1/M00/00/00/wKgAEmNuariAdpn-AAAABsdDDEE84.html |
|          2 | group1/M00/00/00/wKgAEmNuK46ENlMTAAAAAETLCWE021.MP4 |
|          3 | group1/M00/00/00/wKgAEmNuO0qEXwIFAAAAACgBC2c879.MP4 |
|          4 | group1/M00/00/00/wKgAEmNuZmOAMyTjAAAHpjXCM2I37.docx |
+------------+-----------------------------------------------------+
5 rows in set (0.00 sec)

mysql>

查询该表发现以上信息。推断fs_file_id为其它表引用该文件的索引，file_name为该文件在文件系统中的位置。

mysql> select fs_file_id,file_path,file_name from  personal_file limit 0,5;
+------------+-----------+-----------------------------------+
| fs_file_id | file_path | file_name                         |
+------------+-----------+-----------------------------------+
|          1 | /         | 新建 Microsoft Word 文档.docx     |
|          2 | /测试/    | 20200729074241MEDIA.MP4           |
|       NULL | /         | 测试                              |
|          3 | /         | 20221007045107MEDIA.MP4           |
|          4 | /测试/    | 文档.docx                         |
+------------+-----------+-----------------------------------+
5 rows in set (0.00 sec)

mysql>

查询personal_file表就可以发现存在fs_file_id键值，指向这个文件的名称和路径，如果该值是NULL，那么这个也许是目录。从而证明了上述第一条的猜想。

root@yliyun:/usr/local/mysql/bin# fdfs_file_info /usr/local/yliyun/conf/fdfs/storage.conf group1/M00/00/00/wKgAEmMYflSAdgwJAAAu9Am4McM53.docx
GET FROM SERVER: false

file type: normal
source storage id: 0
source ip address: 192.168.0.18
file create timestamp: 2022-09-07 19:19:48
file size: 12020
file crc32: 163066307 (0x09b831c3)
root@yliyun:/usr/local/mysql/bin#

通过执行fdfs_file_info命令证实了第二条猜想,文件系统可以通过这段路径找到文件。

2、分析文件系统路径意义

查询fs_file表，发现所有的路径都是以下这种格式。

group1/M00/00/00/wKgAEmMYflSAdgwJAAAu9Am4McM53.docx
group1/M00/00/00/wKgAEmNuZmOAMyTjAAAHpjXCM2I37.docx

最后经过查询fdfs的文档得知该路径的意义，首先group1可以理解为一个存储组，FastDFS采用多副本模式，group1，group2内的数据都是一样的，这样可以保证数据存储的安全性。第二段M00则表示存储组下的存储节点编号。

root@yliyun:/usr/local/mysql/bin# ls -lh / | grep yliyun_data
drwxr-xr-x   3 root root 4.0K 7月  10  2022 yliyun_data_01      #M00
drwxr-xr-x   3 root root 4.0K 7月  10  2022 yliyun_data_02      #M01
drwxr-xr-x   3 root root 4.0K 7月  10  2022 yliyun_data_03      #M02
drwxr-xr-x   3 root root 4.0K 7月  10  2022 yliyun_data_04      #M03

多存储节点采用以上的编号方式。

第三第四段的/00/00则表示在该存储节点下的实际路径。如下

root@yliyun:/usr/local/mysql/bin# ls /yliyun_data_01/data/
00  0A	14  1E	28  32	3C  46	50  5A	64  6E	78  82	8C  96	A0  AA	B4  BE	C8  D2	DC  E6	F0  FA
01  0B	15  1F	29  33	3D  47	51  5B	65  6F	79  83	8D  97	A1  AB	B5  BF	C9  D3	DD  E7	F1  FB
02  0C	16  20	2A  34	3E  48	52  5C	66  70	7A  84	8E  98	A2  AC	B6  C0	CA  D4	DE  E8	F2  FC
03  0D	17  21	2B  35	3F  49	53  5D	67  71	7B  85	8F  99	A3  AD	B7  C1	CB  D5	DF  E9	F3  FD
04  0E	18  22	2C  36	40  4A	54  5E	68  72	7C  86	90  9A	A4  AE	B8  C2	CC  D6	E0  EA	F4  FE
05  0F	19  23	2D  37	41  4B	55  5F	69  73	7D  87	91  9B	A5  AF	B9  C3	CD  D7	E1  EB	F5  FF
06  10	1A  24	2E  38	42  4C	56  60	6A  74	7E  88	92  9C	A6  B0	BA  C4	CE  D8	E2  EC	F6
07  11	1B  25	2F  39	43  4D	57  61	6B  75	7F  89	93  9D	A7  B1	BB  C5	CF  D9	E3  ED	F7
08  12	1C  26	30  3A	44  4E	58  62	6C  76	80  8A	94  9E	A8  B2	BC  C6	D0  DA	E4  EE	F8
09  13	1D  27	31  3B	45  4F	59  63	6D  77	81  8B	95  9F	A9  B3	BD  C7	D1  DB	E5  EF	F9
root@yliyun:/usr/local/mysql/bin# ls /yliyun_data_01/data/00
00  0A	14  1E	28  32	3C  46	50  5A	64  6E	78  82	8C  96	A0  AA	B4  BE	C8  D2	DC  E6	F0  FA
01  0B	15  1F	29  33	3D  47	51  5B	65  6F	79  83	8D  97	A1  AB	B5  BF	C9  D3	DD  E7	F1  FB
02  0C	16  20	2A  34	3E  48	52  5C	66  70	7A  84	8E  98	A2  AC	B6  C0	CA  D4	DE  E8	F2  FC
03  0D	17  21	2B  35	3F  49	53  5D	67  71	7B  85	8F  99	A3  AD	B7  C1	CB  D5	DF  E9	F3  FD
04  0E	18  22	2C  36	40  4A	54  5E	68  72	7C  86	90  9A	A4  AE	B8  C2	CC  D6	E0  EA	F4  FE
05  0F	19  23	2D  37	41  4B	55  5F	69  73	7D  87	91  9B	A5  AF	B9  C3	CD  D7	E1  EB	F5  FF
06  10	1A  24	2E  38	42  4C	56  60	6A  74	7E  88	92  9C	A6  B0	BA  C4	CE  D8	E2  EC	F6
07  11	1B  25	2F  39	43  4D	57  61	6B  75	7F  89	93  9D	A7  B1	BB  C5	CF  D9	E3  ED	F7
08  12	1C  26	30  3A	44  4E	58  62	6C  76	80  8A	94  9E	A8  B2	BC  C6	D0  DA	E4  EE	F8
09  13	1D  27	31  3B	45  4F	59  63	6D  77	81  8B	95  9F	A9  B3	BD  C7	D1  DB	E5  EF	F9

而最后一段wKgAEmMYflSAdgwJAAAu9Am4McM53.docx

则由该文件的crc32校验，大小，类型等数据计算得出的一段随机字符。

由此了解了这样的路径意义后，就能反推出文件在Linux文件系统下的真实路径。

root@yliyun:/usr/local/mysql/bin# ls -lh /yliyun_data_01/data/00/00/wKgAEmMYflSAdgwJAAAu9Am4McM53.docx
-rw-r--r-- 1 root root 12K 9月   7 19:19 /yliyun_data_01/data/00/00/wKgAEmMYflSAdgwJAAAu9Am4McM53.docx

group1/M00/00/00/wKgAEmMYflSAdgwJAAAu9Am4McM53.docx

同时，经过上面的信息会发现一个比较严重的问题。就是路径已经在数据库内写死。存储节点对应的是M00-M07。我在进行80TB缩小为40TB的容量时，不能进行FastDFS的存储节点缩减。并且EMC如果重新划盘，那么数据就会有危险。

并且又发现了一个比较严重的问题。那就是一粒云系统的存储容量计算，是固定将每个存储节点的容量计算，如果2个存储节点都在一个分区下，那么就会出现容量*2的错误，但实际容量只有*1。

root@yliyun:/usr/local/mysql/bin# df -lh && ls / -lh | grep yliyun
文件系统        容量  已用  可用 已用% 挂载点
udev            2.0G     0  2.0G    0% /dev
tmpfs           395M  5.6M  390M    2% /run
/dev/sda1        97G   20G   73G   22% /
tmpfs           2.0G     0  2.0G    0% /dev/shm
tmpfs           5.0M     0  5.0M    0% /run/lock
tmpfs           2.0G     0  2.0G    0% /sys/fs/cgroup
tmpfs           395M     0  395M    0% /run/user/0
drwxr-xr-x   3 root root 4.0K 7月  10  2022 yliyun_data_01
drwxr-xr-x   3 root root 4.0K 7月  10  2022 yliyun_data_02
drwxr-xr-x   3 root root 4.0K 7月  10  2022 yliyun_data_03
drwxr-xr-x   3 root root 4.0K 7月  10  2022 yliyun_data_04

如上面命令结果，我将4个存储节点指定在根路径下，而根路径的实际容量为97GB

进入后台查看，总磁盘容量和剩余磁盘容量被*4。一般情况下不会出错，但如果存储超过上限时，可能会引发未知的问题。这样，剩下的新系统的4硬盘4分区每个分区10TB需要分区为4硬盘8分区每个分区5TB后才能保证数据库数据和文件系统兼容，同时剩余容量又不会出现问题。

3、制定迁移计划

首先为了保证数据安全，写一个数据导出程序，读取数据库分析文件结构，用来将文件系统中的文件按用户在系统中的格式结构原样导出。

第二步，将5-8号磁盘内的数据合并到1-4号磁盘内，并重新指定FastDFS节点路径。

第三步，将磁盘5-8重新分区，每个磁盘分2个分区，将磁盘1-4中的数据重新传输到磁盘6-8中。

第四部，建立系统重新指定文件系统存储节点路径，数据库数据导入覆盖，完成迁移。