Backup是StarRocks目前提供的唯一一种可将数据与元数据一并导出的导出方式。Backup操作也需要Broker组件，通过Broker将数据备份到远端存储系统中，例如HDFS、OSS、COS或S3等。
基于Backup的特性，这种方式通常用于对数据进行定期的快照备份，或者用于在不同集群间进行数据迁移。
与Backup对应的命令是Restore，用于将Backup备份后的数据进行还原。因为Backup备份后的文件中已经包含了元数据，所以在进行Restore还原操作时，我们无需手动建表。
目前，备份（Backup）操作或还原（Restore）可操作的最小单位是分区，最大单位是表，还不直接支持整库的备份或还原。当前也只支持全量备份，还未支持增量。所以如果需要对数据进行定期备份，我们需要在建表时合理规划表的分区，例如按时间分区，然后在后续业务中，按照分区粒度进行备份或还原。
注意：目前主键模型还不支持Restore操作，虽然可以Backup成功，但无法正常还原。
StarRocks官网对于备份还原的介绍材料主要有：
https://docs.starrocks.com/zh-cn/main/administration/Backup_and_restore其他相关语法可参考官网文档->参考手册->SQL参考->DDL/DML。
Backup&Restore操作非常常用，咱们着重演示，需要使用到的集群组件有：
| 集群编号 | 节点IP | 部署服务 | 端口 | 版本 | 说明 |
| 集群A | 172.17.0.2 [starrocks] | FE | 9030 | 2.1.0 | 用户名密码均为root |
| BE | 8030 | ||||
| Broker | 8000 | 名称为：hdfs_broker | |||
| mysql-client | 5.7.37 | ||||
| 集群B | 192.168.110.101 [node01] | FE | 9030 | 2.0.1 | 用户名密码均为root |
| BE | 8030 | ||||
| Broker | 8000 | 名称均为：hdfs_broker | |||
| mysql-client | 5.7.35 | ||||
| 192.168.110.102 [node02] | FE | 2.0.1 | |||
| BE | |||||
| Broker | |||||
| 192.168.110.103 [node03] | FE | 2.0.1 | |||
| BE | |||||
| Broker | |||||
| OSS | 桶名：wu########ng "fs.oss.accessKeyId" = "LTA################TbR", "fs.oss.accessKeySecret" = "HqD################PKN", "fs.oss.endpoint" = "oss-cn-beijing.aliyuncs.com" | ||||
备注：
1、集群A与集群B都可以与外网通信；
2、集群A和集群B不在同一个内网，两套集群间无法直接通信。
一、需求模拟
为相对全面的涵盖常规业务场景，现模拟需求如下：
1、备份集群B数据库backup_test中的所有表（这里假设共三张表，即表backup_visit、backup_user和backup_supplier）的所有数据到OSS中，OSS相关信息见上表；
2、将集群B备份到OSS中的部分数据还原至集群A中，要求：
1）将数据还原至集群A的restore库；
2）backup_user表只还原分区p202201和p202202；
3）backup_supplier表需重命名为restore_supplier；
4）由于集群A只有一个BE节点，要求还原时设置只还原为单副本。
二、集群B准备
在node01节点访问StarRocks：
[root@node01 ~]# mysql -h192.168.110.101 -P9030 -uroot -proot
创建数据库：
mysql> create database backup_test;
mysql> use backup_test;
2.1 表backup_visit准备
创建表backup_visit：
mysql> CREATE TABLE backup_visit(
record_id int,
seller_id int,
store_id int,
sale_date date,
sale_amt bigint
) Distributed BY hash(record_id)
properties(
"replication_num" = "1"
);
为该表分别创建Rollup Index和物化视图（后面解释原因），创建rollup_visit：
mysql> ALTER TABLE backup_visit ADD ROLLUP rollup_visit (sale_date,sale_amt);
创建Rollup和创建物化视图都是异步操作，需等待Rollup创建完成后再创建物化视图，创建进度查看命令：
mysql> SHOW ALTER MATERIALIZED VIEW FROM backup_test;
继续创建物化视图mv_visit：
mysql> CREATE MATERIALIZED VIEW mv_visit AS SELECT store_id,SUM(sale_amt) FROM backup_visit GROUP BY store_id;
为backup_visit表导入演示数据：
mysql> insert into backup_visit values(211014001,10001,13,'2021-10-14',1999),(211014002,10002,13,'2021-10-14',6999),(211015098,16573,19,'2021-10-15',3999);
查看backup_visit表结构：
mysql> desc backup_visit all;
2.2 表backup_user准备
创建表backup_user：
mysql> CREATE TABLE backup_user (
event_day DATE,
site_id INT DEFAULT '10',
city_code VARCHAR(100),
user_name VARCHAR(32) DEFAULT '',
pv BIGINT DEFAULT '0'
)
PARTITION BY RANGE(event_day)(
PARTITION p202201 VALUES LESS THAN ("2022-02-01"),
PARTITION p202202 VALUES LESS THAN ("2022-03-01"),
PARTITION p202203 VALUES LESS THAN ("2022-04-01")
)
DISTRIBUTED BY HASH(event_day, site_id) BUCKETS 2;
插入演示数据：
mysql> insert into backup_user values('2020-12-23',12,'49','lm',23),('2021-12-25',10,'26','Mark',55),( '2022-03-01',13,'52','SR',10086);
2.3 表backup_supplier准备
创建表backup_supplier：
mysql> CREATE TABLE `backup_supplier` (
`s_suppkey` int(11) NOT NULL COMMENT "",
`s_name` varchar(26) NOT NULL COMMENT "",
`s_address` varchar(26) NOT NULL COMMENT "",
`s_city` varchar(11) NOT NULL COMMENT "",
`s_nation` varchar(16) NOT NULL COMMENT "",
`s_region` varchar(13) NOT NULL COMMENT "",
`s_phone` varchar(16) NOT NULL COMMENT ""
)DUPLICATE KEY(`s_suppkey`)
DISTRIBUTED BY HASH(`s_suppkey`) BUCKETS 2
PROPERTIES (
"replication_num" = "3"
);
使用Stream Load导入演示数据（supplier.tbl是使用SSB测试集生成的数据文件）：
[root@node01 ~]# curl --location-trusted -u root:root -H "label:supplier_20220301001" -H "column_separator:|" -T supplier.tbl http://192.168.110.101:8030/api/backup_test/backup_supplier/_stream_load
在StarRocks中查看表backup_supplier数据条数：
mysql> select count(1) from backup_supplier;
+-----------------+
| count(1) |
+-----------------+
| 2000 |
+-----------------+
2.4 创建远端仓库oss_repo
在StarRocks中创建OSS远端仓库的语法为：
CREATE REPOSITORY `仓库名称`
WITH BROKER `broker_name`
ON LOCATION "oss://存储桶名称/路径"
PROPERTIES
(
"fs.oss.accessKeyId" = "xxx",
"fs.oss.accessKeySecret" = "yyy",
"fs.oss.endpoint" = "oss-cn-beijing.aliyuncs.com"
);
fs.oss.endpoint信息可以从阿里官网文档中获取：
根据我们OSS的信息修改语句，创建远端仓库oss_repo：
mysql> CREATE REPOSITORY `oss_repo`
WITH BROKER `hdfs_broker`
ON LOCATION "oss://wu########ng/StarRocks"
PROPERTIES
(
"fs.oss.accessKeyId" = "LTA################TbR",
"fs.oss.accessKeySecret" = "HqD################PKN",
"fs.oss.endpoint" = "oss-cn-beijing.aliyuncs.com"
);
查看已创建的仓库信息：
mysql> SHOW REPOSITORIES;
仅root或ADMIN_PRIV权限用户可以创建或删除仓库。假设仓库信息有误，可以删除后重新创建，删除语法为：
mysql> DROP REPOSITORY `repo_name`;
三、集群A准备
登录集群A的StarRocks：
[root@starrocks ~]# mysql -h172.17.0.2 -P9030 -uroot -proot
登录后，首先在集群A中创建目标库restore：
mysql> create database restore;
mysql> use restore;
接下来，特别注意，务必创建与集群B名称相同的远端仓库oss_repo，若仓库名称不同，即便我们的OSS信息和路径都一致，也无法进行还原：
mysql> CREATE REPOSITORY `oss_repo`
WITH BROKER `hdfs_broker`
ON LOCATION "oss://wu########ng/StarRocks"
PROPERTIES
(
"fs.oss.accessKeyId" = "LTA################TbR",
"fs.oss.accessKeySecret" = "HqD################PKN",
"fs.oss.endpoint" = "oss-cn-beijing.aliyuncs.com"
);
这里也可使用CREATE READ ONLY REPOSITORY语句创建只读仓库，只读仓库下只能使用仓库进行Restore恢复操作，不能进行Backup备份。
创建完成后，查看仓库信息，确认集群A中的仓库名称与集群B是相同的：
mysql> SHOW REPOSITORIES;
集群A就准备完毕，不需要建表。
四、Backup备份
备份（backup）操作实际是将指定表或分区的数据，直接以StarRocks存储的文件的形式，上传到远端仓库中进行存储。
同一数据库下只能有一个正在执行的BACKUP或RESTORE任务，多个数据库，从代码看这里也加了锁，也即当前可以认为集群中同时只能进行一个备份或者还原的任务。
Backup命令的语法为：
BACKUP SNAPSHOT [db_name].{snapshot_name}
TO `repository_name`
ON (
`table_name` [PARTITION (`p1`, ...)],
...
)
PROPERTIES ("key"="value", ...);
1、ON子句中标识需要备份的表和分区。如果不指定分区，则默认备份该表的所有分区。目前不直接支持整库的备份，如果需要整库备份，需要将库内所有的表都写在这里。
2、Backup的PROPERTIES目前只支持以下两个属性：
"type" = "full"：表示这是一次全量更新（默认），目前也只支持全量，可以省略；
"timeout" = "3600"：任务超时时间，默认为一天，单位秒，默认时可省略。
3、执行备份命令后，集群首先会对涉及到的tablet进行一次快照，快照耗时很少，快照名称为我们Backup语句中指定的snapshot_name。之后的备份操作实际都是对这个快照进行操作。也即在快照之后，对表进行的导入、修改等操作都不再影响备份的结果。
结合我们的需求改写备份语句，在集群B中执行备份任务：
mysql> BACKUP SNAPSHOT backup_test.snapshot_label22030101
TO `oss_repo`
ON
(
backup_visit,
backup_user,
backup_supplier
)
PROPERTIES (
"type" = "full",
"timeout" = "3600"
);
Backup为异步操作，可以通过show backup语句查看最近一次Backup作业的执行状态（StarRocks中每个数据库仅保存最近一次BACKUP任务）：
mysql> SHOW BACKUP FROM backup_test\G
*************************** 1. row ***************************
JobId: 84472
SnapshotName: snapshot_label22030101
DbName: backup_test
State: UPLOADING
BackupObjs: [default_cluster:backup_test.backup_supplier], [default_cluster:backup_test.backup_user], [default_cluster:backup_test.backup_visit]
CreateTime: 2022-03-01 21:07:26
SnapshotFinishedTime: 2022-03-01 21:07:30
UploadFinishedTime: NULL
FinishedTime: NULL
UnfinishedTasks: 84481=10004, 84480=10004, 84473=10002, 84475=10002, 84474=10002, 84477=10003, 84476=10003, 84479=10004, 84478=10003
Progress: [84473: 3/5], [84476: 0/0], [84479: 0/0]
TaskErrMsg:
Status: [OK]
Timeout: 3600
重点关注以下五个参数：
1）SnapshotName：我们手动指定的本次备份作业的名称，后续还原时需要用到。
2）State：任务状态，需要着重关注，根据任务的进度可能会有以下8种可能的状态：
- PENDING：作业初始状态，等待被调度。
- SNAPSHOTING：正在进行快照操作。
- UPLOAD_SNAPSHOT：快照结束，准备上传。
- UPLOADING：正在上传快照，当数据量大时，这一步通常耗时较长。
- SAVE_META：正在本地生成元数据文件。
- UPLOAD_INFO：上传元数据文件和本次备份作业的信息。
- FINISHED：备份完成，任务正常完成的最终状态。
- CANCELLED：备份失败或被取消，任务超时或出现错误且多次重试失败后的最终状态。
3）UnfinishedTasks：Backup作业同样会拆分为多个子任务并行执行，以84473=10002为例，表示task id为84473的子任务在BackendId为10002的BE节点上进行，目前进行的进度为3/5，这个进度为“已完成的tablet数/该子任务共包含的tablet数”，即Backup或Restore过程中，仍是以tablet作为最小数据单位。
4）TaskErrMsg和Status：会显示任务过程中Task的一些错误信息，但只要State列不为CANCELLED，就说明作业依然在继续，这些Task有可能会重试成功。当然，有些Task错误，也会直接导致作业失败。
当一次备份作业涉及到的表和数据都很多时，我们需要不时关注作业状态，若发现任务长时间没有进度或有其他问题，也可以将任务手动取消，取消语法为：
mysql> CANCEL BACKUP FROM db_name;
我们演示的数据量很小，备份作业可以很快完成。查看任务，当任务State为FINISHED时，表示备份作业成功完成，我们再进行后续的操作。
五、Restore还原
恢复（restore）操作需要我们指定一个远端仓库中已存在的备份，然后将这个备份的内容恢复到本地集群中。前面已经说过，目前一个集群中只能有一个Backup或Restore任务。Restore的语法和Backup非常相似：
RESTORE SNAPSHOT [db_name].{snapshot_name}
FROM `repository_name`
ON (
`table_name` [PARTITION (`p1`, ...)] [AS `tbl_alias`],
...
)
PROPERTIES ("key"="value", ...);
主要参数说明：
1）snapshot_name，即我们备份时定义的那个快照名。
2）ON子句中指定需要恢复的表和分区。还原时同样不支持直接进行库级别的还原，若要整库还原，需要列出库内所有的表。如果不指定分区，则默认恢复该表的所有分区。所指定的表和分区必须已存在于仓库备份中。
3）可以通过AS语句将仓库中备份的表名恢复为新的表，但新表名不能已存在于数据库中。表的其他信息均不能修改。
4）可以将仓库中备份的表恢复替换数据库中已有的同名表，但需保证两张表的表结构完全一致。表结构包括：表名、列、分区、Rollup及物化视图等等。同时，特别注意，从恢复作业的COMMIT阶段开始，如果恢复作业失败或被取消，有可能造成之前的数据已损坏且无法访问，因此，如无必要，强烈不建议使用覆盖替换同名表的方式恢复数据，除非确认当前表中的数据已不再使用。
5）可以指定恢复表的部分分区，系统会检查分区Range是否能够匹配。在任务中以分区为增量单位来备份并还原数据，这种方式是推荐的。这种情况与上面的第四条不同，不是覆盖，而是为目标表增量添加分区。
6）Restore的PROPERTIES目前支持以下属性：
"backup_timestamp" = "2022-02-22-16-45-08"：指定了恢复对应备份的哪个时间版本，必填。该信息可以通过SHOW SNAPSHOT ON repo;语句获得。
"replication_num" = "3"：指定恢复的表或分区的副本数。默认为3。若恢复已存在的表或分区，则副本数必须和已存在表或分区的副本数相同。同时，考虑到StarRocks的副本策略，必须有足够Host的BE节点来容纳多个副本。
"timeout" = "3600"：任务超时时间，默认为一天，单位秒。
首先，在oss_repo中查看快照的时间版本信息：
mysql> SHOW SNAPSHOT ON oss_repo;
+------------------------------------+-----------------------------------+----------+
| Snapshot | Timestamp | Status |
+------------------------------------+-----------------------------------+----------+
| snapshot_label22030101 | 2022-03-01-21-07-26-597 | OK |
+------------------------------------+-----------------------------------+----------+
当Status为OK时表示备份正常，若不为OK，可能表示备份还未完成或出现了其他异常情况。如果想查看仓库中快照的详细信息，也可以在SHOW SNAPSHOT语句中拼接上Snapshot和Timestamp信息再次查看：
mysql> SHOW SNAPSHOT ON `oss_repo` WHERE SNAPSHOT = "snapshot_label22030101" AND TIMESTAMP = "2022-03-01-21-07-26-597"\G
*************************** 1. row ***************************
Snapshot: snapshot_label22030101
Timestamp: 2022-03-01-21-07-26-597
Database: backup_test
Details: {
"database": "backup_test",
"meta_version": 92,
"backup_time": 1646140046597,
"name": "snapshot_label22030101",
"starrocks_meta_version": 3,
"backup_result": "succeed",
"backup_objects": {
"backup_visit": {"partitions": {"backup_visit": {}}},
"backup_supplier": {"partitions": {"backup_supplier": {}}},
"backup_user": {"partitions": {
"p202201": {},
"p202202": {},
"p202203": {}
}}
}
}
Status: OK
返回值会以Json的形式，展示整个备份的库表及分区信息。
接下来，根据我们模拟的需求，在集群A中执行还原语句，这里再把还原部分的需求摘录一份：
将集群B备份到OSS中的部分数据还原至集群A中，要求：
1）将数据还原至集群A的restore库；
2）backup_user表只还原分区p202201和p202202；
3）backup_supplier表需重命名为restore_supplier；
4）由于集群A只有一个BE节点，要求还原时设置只还原为单副本。
根据备份信息及业务需求，在集群A中编写Restore语句并执行：
mysql> RESTORE SNAPSHOT restore.`snapshot_label22030101`
FROM `oss_repo`
ON (
backup_visit,
backup_user PARTITION (`p202201`, `p202202`),
backup_supplier AS restore_supplier
)
PROPERTIES
(
"backup_timestamp"="2022-03-01-21-07-26-597",
"replication_num" = "1",
"timeout" = "3600"
);
还原同样为异步操作，通过SHOW RESTORE [FROM db_name]语句查看还原状态（StarRocks中每个数据库也只会保存最近一次RESTORE任务）：
mysql> SHOW RESTORE\G
*************************** 1. row ***************************
JobId: 13005
Label: snapshot_label22030101
Timestamp: 2022-03-01-21-07-26-597
DbName: default_cluster:restore
State: DOWNLOADING
AllowLoad: false --恢复时是否允许导入，当前不支持（这个参数只是预留）
ReplicationNum: 1
RestoreObjs: backup_visit, backup_supplier, backup_user PARTITIONS [p202201, p202202]
CreateTime: 2022-03-01 21:16:12
MetaPreparedTime: 2022-03-01 21:16:14
SnapshotFinishedTime: 2022-03-01 21:16:17
DownloadFinishedTime: NULL
FinishedTime: NULL
UnfinishedTasks: 13127=10002, 13128=10002
Progress: [13127: 0/0]
TaskErrMsg:
Status: [OK]
Timeout: 3600
在数据还原过程中，会自动创建还原操作涉及到的表，创建完成后，这些表可见，但不能访问，需要等待还原任务完成后方可正常访问。
还原任务的状态信息我们通常只需要关注State、TaskErrMsg及Status：
1）State：恢复作业当前所在阶段，根据任务进度可能会有八种状态：
-
-
- PENDING：作业初始状态，等待调度。
- SNAPSHOTING：正在进行本地新建表的快照操作。
- DOWNLOAD：正在发送下载快照任务。
- DOWNLOADING：快照正在下载。
- COMMIT：准备生效已下载的快照。
- COMMITTING：正在生效已下载的快照。
- FINISHED：恢复完成，作业成功。
- CANCELLED：恢复失败或被取消，通常为任务超时或任务失败。
-
2）TaskErrMsg及Status：显示还原作业过程中可能出现的错误信息，如果任务失败，这里也会展示失败信息。同样的，只要State列不为CANCELLED，则说明作业依然在继续，作业中失败的task可能会重试成功，当然也有可能重试失败，最终导致任务CANCELLED。
与Backup操作时相同，当我们发现任务进度持续卡住，或者因为其他原因需要取消还原任务时，取消的语法为：
mysql> CANCEL RESTORE FROM db_name;
再次强调，如果是覆盖表式的还原，当取消处于COMMIT或之后阶段的恢复作业时，可能导致数据损坏，进而导致被恢复的表无法访问。
六、信息查看
本次演示还原的数据量不大，当Restore任务状态为FINISHED时，即表示还原作业已成功完成，我们来查看一下还原后集群A的库表信息。
6.1 表名检查
mysql> show tables from restore;
+-----------------------------+
| Tables_in_restore |
+-----------------------------+
| backup_user |
| backup_visit |
| restore_supplier |
+-----------------------------+
表名没有问题，backup_supplier表在还原时已被重命名为restore_supplier。
6.2 表结构检查
查看backup_visit的表结构：
mysql> desc backup_visit all;
确认物化视图及Rollup索引都能被一并备份还原过来。
6.3 分区检查
检查backup_visit的分区还原情况：
mysql> show partitions from backup_visit;
分区正常，可以单独还原的我们给定的分区。后续我们也可以再次对该表单独还原p202203分区，这也是业务中比较常用的备份还原形式。
七、性能调优
备份还原时，若集群中资源相对空闲，也可以通过调整作业中子任务的并行度来进行加速，主要涉及到参数有三个：
7.1 upload_worker_count
BE配置项，上传文件最大线程数，默认值为1，作用于BACKUP阶段。调优时可以适当调大，例如设为5。
7.2 download_worker_count
BE配置项，下载线程数，默认1个，作用于RESTORE阶段。调优时可以适当增大，例如设为5。
7.3 max_download_speed_kbps
BE配置项，最大下载速度限制，默认值：50000（kb/s）。备份还原任务通常不会跑到这个参数的上限，假设是由于这个速度限制导致的，可根据带宽情况适当调整。
八、注意事项
出于篇幅考虑，咱们没有创建更多的示例表来控制单一变量演示说明问题，这里我将我们实际业务中使用备份还原出现过的问题及解决方案以FAQ的形式整理出来，供大家参考。
8.1 动态分区属性失效
在StarRocks早期版本中出现过，动态分区表备份还原后，查看建表语句，虽然dynamic_partition.enable属性为true，但是不能正常的自动创建新分区（已提issue）。
解决方案：将该表的动态分区属性关闭一次后重新启用。即先后执行：
ALTER TABLE tbl SET("dynamic_partition.enable"="false");
ALTER TABLE tbl SET("dynamic_partition.enable"="true");
8.2 Colocate表查询异常
设置了Colocate属性的表在进行备份还原后，无法正常查询（已提issue）。
解决方案：将该表的Colocate属性关闭掉，即执行：
ALTER TABLE tbl SET ("colocate_with" = "");
8.3 创建CREATE REPOSITORY报错
执行CREATE REPOSITORY语句后直接报错，提示errors while write data to output stream, cause by: buffer is null。
解决方案：broker的conf目录中有一个hdfs-site.xml，里面配置了备份还原时本地的缓存目录，默认是/tmp/，可以排查一下权限问题。若创建仓库阶段有报错，基本可以从本地权限、通信及OSS权限三个角度来逐个排查。
8.4 出现不明报错
备份还原操作在用户层面并不涉及复杂的业务编码，当出现完全理不出头绪的报错，除了及时向社区求助，也可以先从这几个角度排查解决：
1、拆分任务，如果一次任务涉及的表或者数据量很大，可以将任务拆分为多个，逐个进行，这样通常可以解决大部分问题。
2、排查版本，通常我们升级StarRocks时，只关注FE和BE，可能忘记了同时升级Broker，此时可以将Broker升级至和主程序一致的版本，再次执行任务。
8.5 备份还原能备份什么、还原什么和修改什么
1、Rollup和物化视图可以同步还原（其中Rollup是物化视图的前身，是一个逐渐被弱化的概念，它的功能也已经被物化视图完全涵盖，现在并不建议使用）。
2、在进行还原操作时，库名可以不和源库的一致，表名可以改，副本数可以改，其他的都改不了。
3、仅支持备份OLAP类型的表，视图不能备份，会报错，需要手动创建。
8.6 其他注意事项
1、当备份还原语句中有存在仅以大小写区分的表时（例如表ABC_cost和表abc_cost），任务会报错，需要将它们拆分为不同的任务进行（已提issue）。
2、Backup一个空表时，出现过一直卡在SNAPSHOTING阶段的情况，所以目前需要注意不要备份空表（已提issue）。
3、创建或删除远端仓库需要root或ADMIN_PRIV权限，执行备份还原任务时只需要普通权限。
4、目前备份的快照数据无法在StarRocks上使用命令删除，DROP REPOSITORY命令只是删除StarRocks与远端存储的连接，已经存在于远端存储中的文件需要我们登录OSS等进行手动删除。
5、最后也是最重要，不要一次备份或还原大量的表和数据，当表的数据量很大时，可以按照分区拆分任务进行，个人建议单次任务不要超过10G，以避免失败重试的时间成本。同时，在前期也要注意合理建表，规范分区分桶，尤其是分桶数，不要过多，当一个表涉及的tablet过多时，即使总数据量很小，依然可能需要备份或恢复较长时间。
1180
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
