通过backup/restore方式恢复分区表报错

【StarRocks版本】例如:1.19.5
【集群规模】:3fe(1 follower+2observer)+3be
【机器信息】测试环境,CPU虚拟核/内存/网卡,例如:4C/8G/千兆

准备工作:部署broker,创建REPOSITORIES到hdfs。

操作:通过backup备份数据,然后truncate掉表中的数据,然后通过restore恢复。

问题:对于未做分区的表,可以通过backup/restore恢复truncate掉的数据。
但是对于分区表来说,restore恢复过程中报错。

测试表结构:

CREATE TABLE test_restore_orders (
dt int(11) NOT NULL COMMENT “”,
id bigint(20) NOT NULL COMMENT “”,
aaa_id bigint(20) REPLACE NULL COMMENT “”,
bbb_id bigint(20) REPLACE NULL COMMENT “”,
ccc_id bigint(20) REPLACE NULL COMMENT “”,
ddd_number varchar(65533) REPLACE NULL DEFAULT “” COMMENT “”,
type tinyint(4) REPLACE NULL DEFAULT “0” COMMENT “”,
status tinyint(4) REPLACE NULL COMMENT “”,
remark varchar(65533) REPLACE NULL COMMENT “”,
dt_time datetime REPLACE NULL COMMENT “”,
INDEX idx_aaa_id (aaa_id) USING BITMAP COMMENT ‘’,
INDEX idx_ccc_id (ccc_id) USING BITMAP COMMENT ‘’
) ENGINE=OLAP
PRIMARY KEY(dt, id)
COMMENT “OLAP”
PARTITION BY RANGE(dt)
(PARTITION p2020 VALUES [("-2147483648"), (“2021”)),
PARTITION p2021 VALUES [(“2021”), (“2022”)),
PARTITION p2022 VALUES [(“2022”), (“2023”)),
PARTITION p2023 VALUES [(“2023”), (“2024”)),
PARTITION p2024 VALUES [(“2024”), (“2025”)),
PARTITION p2025 VALUES [(“2025”), (“2026”)),
PARTITION p2026 VALUES [(“2026”), (“2027”)),
PARTITION p2027 VALUES [(“2027”), (“2028”)),
PARTITION p2028 VALUES [(“2028”), (“2029”)),
PARTITION p2029 VALUES [(“2029”), (“2030”)),
PARTITION p2030 VALUES [(“2030”), (“2031”)),
PARTITION p2031 VALUES [(“2031”), (“2032”)),
PARTITION p2032 VALUES [(“2032”), (“2033”)),
PARTITION p2033 VALUES [(“2033”), (“2034”)),
PARTITION p2034 VALUES [(“2034”), (“2035”)),
PARTITION p2035 VALUES [(“2035”), (“2036”)),
PARTITION p2036 VALUES [(“2036”), (“2037”)),
PARTITION p2037 VALUES [(“2037”), (“2038”)),
PARTITION p2038 VALUES [(“2038”), (“2039”)),
PARTITION p2039 VALUES [(“2039”), (“2040”)),
PARTITION p2040 VALUES [(“2040”), (“2041”)))
DISTRIBUTED BY HASH(id) BUCKETS 16
PROPERTIES (
“replication_num” = “2”,
“in_memory” = “false”,
“storage_format” = “DEFAULT”
);

一、恢复分区表全表

backup命令:

BACKUP SNAPSHOT test_dorisdb.test_restore_orders_full_202206011920
TO hdfs_starrocks_repo
ON (
test_restore_orders
)
PROPERTIES (“type”=“full”, “timeout” = “3600”);

执行结果:

恢复命令:

RESTORE SNAPSHOT test_dorisdb.test_restore_orders_full_202206011920
FROM hdfs_starrocks_repo
ON (
test_restore_orders
)
PROPERTIES
(
“backup_timestamp”=“2022-06-01-19-26-48-254”,
“replication_num” = “2”
);

执行完报错:

二、恢复分区表单个分区的数据

backup命令:

BACKUP SNAPSHOT test_dorisdb.test_orders_full_20220601800
TO hdfs_starrocks_repo
ON (
test_orders PARTITION (p2022)
)
PROPERTIES (“type”=“full”, “timeout” = “3600”);

备份成功记录:

备份成功后,使用truncate清掉表中的数据,然后执行恢复操作。

restore命令:

RESTORE SNAPSHOT test_dorisdb.test_orders_full_20220601800
FROM hdfs_starrocks_repo
ON (
test_orders PARTITION (p2022)
)
PROPERTIES
(
“backup_timestamp”=“2022-06-01-18-02-53-777”,
“replication_num” = “2”
);

恢复操作报错如下

此时查询目标表数据报错

MySQL [test_dorisdb]> select count(*) from test_orders;
ERROR 1064 (HY000): Table state is not NORMAL: ‘RESTORING’

ok 我先执行验证下 晚些给答复

好的,麻烦尽快,非常感谢

逻辑是有些问题的,总体流程是:先创建云端仓库用于备份与恢复(新老集群都要创建云端仓库,

REPOSITORY名字要相同,BROKER Name要查看集群的broker名称);

在老集群准备好需要进行迁移备份的分区表,Backup到云端仓库;

再从云端仓库以分区的形式再Restore到新集群。

我现在模拟的一个starrocks里的一张分区表的备份和恢复。不涉及到新老集群。
就是用的一个云端仓库,名字叫hdfs_starrocks_repo,通过show命令查看如下:

操作流程就是上面说的,
通过backup备份数据,然后truncate掉表中的数据,然后通过restore恢复。

从云端仓库以分区的形式再Restore到新集群,这个以分区的形式restore,是需要加一个参数吗?

备份的时候也是可以单独只备份对应分区的数据,然后您恢复的时候,也可以直接恢复对应分区的数据,语法是:

从 example_repo 中恢复备份 snapshot_2 中的表 backup_tbl 的分区 p1,p2,以及表 backup_tbl2 到数据库 example_db1,并重命名为 new_tbl,时间版本为 “2022-06-02-12-11-01”。默认恢复为 3 个副本

RESTORE SNAPSHOT example_db1.`snapshot_2`
FROM `example_repo`
ON
(
    `backup_tbl` PARTITION (`p1`, `p2`),
    `backup_tbl2` AS `new_tbl`
)
PROPERTIES
(
    "backup_timestamp"="2022-06-02-12-11-01"
);

之前的原因找到了,因为用的是主键表做的backup/restore测试。

而主键表是不支持使用backup/restore功能的

此贴可以撤了