FAQ (StarRocks#32)

* modify for FAQ
* add recovery tips

administration/Metadata_recovery.md

@@ -39,6 +39,6 @@ FE 有可能因为某些原因出现无法启动 bdbje、FE 之间无法同步
     ![8-4](../assets/8-4.png)
     以上这些步骤的目的，其实就是人为地制造出一个 FOLLOWER 节点的元数据，然后用这个元数据，重新开始故障恢复。这样就避免了从 OBSERVER 恢复元数据所遇到的不一致的问题。
 
-4. 第3步执行成功后，我们再通过 `ALTER SYSTEM DROP FOLLOWER/OBSERVER` 命令，将之前的其他的 FE 从元数据删除后，按加入全新 FE 的方式，重新把这些 FE 添加一遍。
+4. 第3步执行成功后，我们再通过 `ALTER SYSTEM DROP FOLLOWER/OBSERVER` 命令，将之前的其他的 FE 从元数据删除后，按加入全新 FE 的方式，重新把这些 FE 添加一遍。如果通过--helper添加FE时对应fe启动失败，可以检查当前master节点的/fe/meta/bdb文件夹大小，如果bdb过大（超过fe.conf中jvm设置的一半），则需要增大fe.conf中的jvm大小后重新启动。
 
 5. 如果以上操作正常，则恢复完毕。

faq/Exporting_faq.md

@@ -0,0 +1,86 @@
+# Export
+
+## 阿里云OSS备份与还原
+
+StarRocks支持备份数据到阿里云OSS/AWS S3（或者兼容S3协议的对象存储）等。假设有两个StarRocks集群，分别DDB1集群和DDB2集群，我们需要将DDB1中的数据备份到阿里云OSS，然后在需要的时候恢复到DDB2，备份及恢复大致流程如下：
+
+1. 创建云端仓库
+在DDB1和DDB2中分别执行SQL：
+
+    ```sql
+    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"
+    );
+    ```
+
+    a. DDB1和DDB2都需要创建，且创建的REPOSITORY仓库名称要相同，仓库查看：
+
+    ```sql
+    SHOW REPOSITORIES;
+    ```
+
+    b. broker_name需要填写一个集群中的broker名称，BrokerName查看：
+
+    ```sql
+    SHOW BROKER;
+    ```
+
+    c. fs.oss.endpoint后的路径不需要带存储桶名。
+
+2. 备份数据表
+在DDB1中将需要进行备份的表，BACKUP到云端仓库。在DDB1中执行SQL：
+
+    ```sql
+    BACKUP SNAPSHOT [db_name].{snapshot_name}
+    TO `repository_name`
+    ON (
+    `table_name` [PARTITION (`p1`, ...)],
+    ...
+    )
+    PROPERTIES ("key"="value", ...);
+    ```
+
+    ```plain text
+    PROPERTIES 目前支持以下属性：
+    "type" = "full"：表示这是一次全量更新（默认）。
+    "timeout" = "3600"：任务超时时间，默认为一天，单位秒。
+    ```
+
+    StarRocks目前不支持全数据库的备份，我们需要在ON (……)指定需要备份的表或分区，这些表或分区将并行的进行备份。
+    查看正在进行中的备份任务（注意同时进行的备份任务只能有一个）：
+
+    ```sql
+    SHOW BACKUP FROM db_name;
+    ```
+
+    备份完成后，可以查看OSS中备份数据是否已经存在（不需要的备份需在OSS中删除）：
+
+    ```sql
+    SHOW SNAPSHOT ON OSS仓库名; 
+    ```
+
+3. 数据还原
+
+    在DDB2中进行数据还原，DDB2中不需要创建需恢复的表结构，在进行Restore操作过程中会自动创建。执行还原SQL：
+
+    ```sql
+    RESTORE SNAPSHOT [db_name].{snapshot_name}
+    FROMrepository_name``
+    ON (
+        'table_name' [PARTITION ('p1', ...)] [AS 'tbl_alias'],
+        ...
+    )
+    PROPERTIES ("key"="value", ...);
+    ```
+
+    查看还原进度：
+
+    ```sql
+    SHOW RESTORE;
+    ```

faq/Others.md

@@ -45,3 +45,124 @@ ALTER DATABASE example_db SET DATA QUOTA 10T;
 ```
 
 改动db的quota，调整这个db的容量上限。
+
+## [数据恢复]中原子替换表/分区功能使用方法
+
+类似CK的分区卸载、装载，跨表分区移动等功能。
+下面以原子替换表 table1 的数据，或 table1 的分区数据，为例。可能比insert overwrite更安全些，可以先检查下数据。
+
+### 原子替换「表」
+
+1. 创建一张新表table2;
+
+    ```SQL
+    create table2 like table1;
+    ```
+
+2. 使用stream load / broker load /insert into 等方式导入数据到新表 table2 中；
+3. 原子替换 table1 与 table2：
+
+    ```SQL
+    ATER TABLE table1 SWAP WITH table2;
+    ```
+
+这样就可以进行表的原子替换。
+
+### 原子替换「分区」
+
+同样可以用「导入临时分区」的方式进行替换。
+
+1. 创建临时分区:
+
+    ```SQL
+    ALTER TABLE table1
+    ADD TEMPORARY PARTITION tp1
+    VALUES LESS THAN("2020-02-01");
+    ```
+
+2. 向临时分区导入数据;
+
+3. 原子替换「分区」:
+
+    ```SQL
+    ALTER TABLE table1
+    REPLACE PARTITION (p1) WITH TEMPORARY PARTITION (tp1);
+    ```
+
+这样可以导入数据后做一定的验证以后再替换,可以进行临时分区的原子替换。
+
+## fe重启报错:error to open replicated environment，will exit
+
+### 问题描述
+
+重启集群fe后报该错且fe无法启动。
+
+### 解决方案
+
+是bdbje的一个bug，社区版和1.17版本（不含此版本）以前重启会小概率触发该bug，可以升级到1.17及更高版本，已修复该问题。
+
+## 创建hive表，查询报错:Broker list path exception
+
+### 问题描述
+
+```plain text
+msg:Broker list path exception
+path=hdfs://172.31.3.136:9000/user/hive/warehouse/zltest.db/student_info/*, broker=TNetworkAddress(hostname:172.31.4.233, port:8000)
+```
+
+### 解决方案
+
+namenode的地址和端口跟运维人员确认是否正确，权限有没有开启
+
+## 创建hive表，查询报错:get hive partition meta data failed
+
+### 问题描述
+
+```plain text
+msg:get hive partition meta data failed: java.net.UnknownHostException: emr-header-1.cluster-242
+```
+
+### 解决方案
+
+ 需要把集群里的host文件传一份到每个BE机器上，并确认网络是通的。
+
+## hive外表orc访问失败：do_open failed. reason = Invalid ORC postscript length
+
+### 问题描述
+
+查询同一sql前几次查询还行，后面报错了，重新建表后没报错了。
+
+```plain text
+MySQL [bdp_dim]> select * from dim_page_func_s limit 1;
+ERROR 1064 (HY000): HdfsOrcScanner::do_open failed. reason = Invalid ORC postscript length
+```
+
+### 解决方案
+
+目前的版本fe和hive的信息同步是有时差的2h，期间表数据有更新或者插入，会导致scan的数据和fe的判断不一致，导致出现这个错。新版本增加手动reflush功能，可以刷新表结构信息同步。
+
+## mysql外表连接失败：caching_sha2_password cannot be loaded
+
+### 问题描述
+
+MySQL8.0版本默认的认证方式是caching_sha2_password
+MySQL5.7版本默认则为mysql_native_password
+认证方式不同，外表链接出错。
+
+### 解决方案
+
+两种方案：
+
+1. 连接终端
+
+    ```sql
+    ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY 'yourpassword';
+    ```
+
+2. 修改my.cnf文件
+
+    ```plain text
+    vim my.cnf
+    [mysqld]
+    default_authentication_plugin=mysql_native_password
+    ```

faq/loading/Broker_load_faq.md

@@ -2,4 +2,8 @@
 
 ## Broker load，能不能再次执行已经执行成功（State: FINISHED）的任务？
 
-已经执行成功的任务，本身不能再次执行。需要再创建一个，因为为了保证导入任务的不丢不重，每个导入成功的label不可复用。可以show load查看历史的导入记录，然后复制下来修改label后重新导入。
+    已经执行成功的任务，本身不能再次执行。需要再创建一个，因为为了保证导入任务的不丢不重，每个导入成功的label不可复用。可以show load查看历史的导入记录，然后复制下来修改label后重新导入。
+
+## Brokerload 导入数据没报错，但是查询不到数据
+
+    brokerload导入是异步的，创建load语句没报错，不代表导入成功了。show load查看相应的状态和errmsg，修改相应内容后重试任务。