From bc9681e4b8154746a0f83af7f107b89cef7d5070 Mon Sep 17 00:00:00 2001
From: li-jun056 <1255728208@qq.com>
Date: Sat, 19 Sep 2020 15:54:40 +0800
Subject: [PATCH] update documents
---
.../backup-and-restoration.md | 115 ++++++
content/en/docs/Toolreference/gs_expansion.md | 148 +++++++
content/en/menu/index.md | 1 +
...11\350\243\205\347\216\257\345\242\203.md" | 363 ------------------
...71\345\231\250\345\256\211\350\243\205.md" | 159 ++++----
5 files changed, 346 insertions(+), 440 deletions(-)
create mode 100644 content/en/docs/Toolreference/gs_expansion.md
delete mode 100644 "content/zh/docs/installation/\345\207\206\345\244\207\350\275\257\347\241\254\344\273\266\345\256\211\350\243\205\347\216\257\345\242\203.md"
diff --git a/content/en/docs/Administratorguide/backup-and-restoration.md b/content/en/docs/Administratorguide/backup-and-restoration.md
index 9e6c3a77d..0ab56da81 100644
--- a/content/en/docs/Administratorguide/backup-and-restoration.md
+++ b/content/en/docs/Administratorguide/backup-and-restoration.md
@@ -242,6 +242,121 @@ To restore the original database, perform the following steps:
>- Incremental restoration from backup files is not supported.
>- After the restoration, check that the link file in the database is linked to the correct file.
+### PITR Recovery
+
+#### Background
+
+When a database breaks down or needs to be rolled back to a previous state, the point-in-time recovery \(PITR\) function of openGauss can be used to restore the database to any point in time after the backup and archive data is generated.
+
+> **NOTE:**
+>
+>- PITR can only be restored to a point in time after the physical backup data is generated.
+>- Only the primary node can be restored using PITR. The standby node needs to be fully built to synchronize data with the primary node.
+
+#### Prerequisites
+
+- Full data files have been physically backed up.
+- WAL log files have been archived.
+
+#### PITR Recovery Process
+
+1. Replace the target database directory with the physical backup files.
+2. Delete all files in the database directory **pg\_xlog/**.
+3. Copy the archived WAL log file to the **pg\_xlog** file. \(Or you can configure **restore\_command** in the **recovery.conf** file to skip this step.\)
+4. Create the recovery command file **recovery.conf** in the database directory and specify the database recovery degree.
+5. Start the database.
+6. Connect to the database and check whether the database is recovered to the expected status.
+7. If the expected status is reached, run the **pg\_xlog\_replay\_resume\(\)** command so that the primary node can provide services externally.
+
+#### Configuring the recovery.conf File
+
+**Archive Recovery Configuration**
+
+- restore\_command = string
+
+The **shell** command is used to obtain the archived WAL files among the WAL file series. Any %f in the string is replaced by the name of the file to retrieve from the archive, and any %p is replaced by the path name to copy it to on the server. Any %r is replaced by the name of the file containing the last valid restart point.
+
+For example:
+
+```
+restore_command = 'cp /mnt/server/archivedir/%f %p'
+```
+
+- archive\_cleanup\_command = string
+
+This option parameter declares a **shell** command that is executed each time the system is restarted. **archive\_cleanup\_command** provides a mechanism for deleting unnecessary archived WAL files from the standby database. Any %r is replaced by the name of the file containing the last valid restart point. That is the earliest file that must be kept to allow recovery to be restartable, so all files older than %r can be safely removed.
+
+For example:
+
+```
+archive_cleanup_command = 'pg_archivecleanup /mnt/server/archivedir %r'
+```
+
+If multiple standby servers need to be recovered from the same archive path, ensure that WAL files are not deleted from any standby server before the recovery.
+
+- recovery\_end\_command = string
+
+This parameter is optional and is used to declare a **shell** command that is executed only when the recovery is complete. **recovery\_end\_command** provides a cleanup mechanism for future replication and recovery.
+
+**Recovery Object Configuration**
+
+- recovery\_target\_name = string
+
+This parameter declares that the name is recovered to a recovery point created using pg\_create\_restore\_point\(\).
+
+For example:
+
+```
+recovery_target_name = 'restore_point_1'
+```
+
+- recovery\_target\_time = timestamp
+
+This parameter declares that the name is recovered to a specified timestamp.
+
+For example:
+
+```
+recovery_target_time = '2020-01-01 12:00:00'
+```
+
+- recovery\_target\_xid = string
+
+This parameter declares that the name is recovered to a transaction ID.
+
+For example:
+
+```
+recovery_target_xid = '3000'
+```
+
+- recovery\_target\_lsn = string
+
+This parameter declares that the name is recovered to the LSN specified by log.
+
+For example:
+
+```
+recovery_target_lsn = '0/0FFFFFF'
+```
+
+- recovery\_target\_inclusive = boolean
+
+This parameter declares whether to stop the recovery after the recovery target is specified \(**true**\) or before the recovery target is specified \(**false**\). This declaration supports only the recovery targets **recovery\_target\_time**, **recovery\_target\_xid**, and **recovery\_target\_lsn**.
+
+For example:
+
+```
+recovery_target_inclusive = true
+```
+
+> **NOTE:**
+>
+>- Only one of the four configuration items **recovery\_target\_name**, **recovery\_target\_time**, **recovery\_target\_xid**, and **recovery\_target\_lsn** can be used at a time.
+>- If no recovery targets are configured or the configured target does not exist, data is recovered to the latest WAL log point by default.
+
+
+
## Logical Backup and Restoration
diff --git a/content/en/docs/Toolreference/gs_expansion.md b/content/en/docs/Toolreference/gs_expansion.md
new file mode 100644
index 000000000..79be47ba0
--- /dev/null
+++ b/content/en/docs/Toolreference/gs_expansion.md
@@ -0,0 +1,148 @@
+# gs\_expansion
+
+## Background
+
+openGauss provides the **gs\_expansion** tool to scale out the standby database node. A standalone node or a node with one primary and multiple standbys can be scaled to a node with one primary and four standbys.
+
+## Precautions
+
+When a standalone mode is scaled to the primary/standby mode, the standalone database needs to be started as primary. Therefore, the database process needs to be restarted. When scaling out a standalone node, plan the running services first.
+
+## Prerequisites
+
+- The openGauss software package exists on the primary database node.
+
+- The same users and user groups as those on the primary node have been created on the new standby node.
+
+- The trustworthiness of user **root** and the database management user has been established between the existing database nodes and the new nodes.
+
+- The XML file has been created and information about the standby node to be scaled has been added to the installed database configuration file.
+
+- Only user **root** is authorized to run the **gs\_expansion** command.
+
+- The environment variables of the primary database node have been imported before the scale-out command is run.
+
+- The operating system of the new standby node is the same as that of the primary node.
+
+
+## Syntax
+
+- Scale out the standby node.
+
+ ```
+ gs_expansion –U USER –G GROUP –X XMLFILE –h hostlist [-L]
+ ```
+
+- Show help information.
+
+ ```
+ gs_expansion -? | --help
+ ```
+
+- Show version information.
+
+ ```
+ gs_expansion -V | --version
+ ```
+
+
+## Description
+
+- -U
+
+ Specifies the OS username of openGauss.
+
+ The user name of the new standby node must be the same as that of the primary node where the database has been installed and must be created in advance.
+
+- -G
+
+ Specifies the OS user group of openGauss.
+
+ The user group of the new standby node must be the same as that of the primary node where the database has been installed.
+
+- -X
+
+ Specifies the path of the openGauss configuration file.
+
+ Value range: storage paths of XML files. The XML file must contain the configuration information about the installed database and all nodes of the new database.
+
+- -h
+
+ Specifies the IP address of the standby node to be scaled.
+
+ The value must be the same as the value of **backip** in the XML configuration file. If there are multiple nodes, use commas \(,\) to separate them.
+
+- -L
+
+ If the standalone database has been installed on the node to be scaled, skip the step of installing the database on the new standby node and directly establish the primary/standby relationship by adding the **–L** parameter during scaling.
+
+ > **NOTE:**
+ >- The databases installed on the primary and standby nodes must use the same user and user group, and the paths for separating environment variables must be the same.
+ >- When the primary and standby nodes are installed, the values of **gaussdbAppPath**, **gaussdbLogPath**, **gaussdbToolPath**, and **corePath** in the XML configuration file must be the same.
+ >- The data on the scaled standby node must be installed in om mode. The database started in compilation mode does not support scaling out with the primary node.
+
+- -?, –help
+
+ Shows help information.
+
+- -V, –version
+
+ Shows version information.
+
+
+## Examples
+
+Use **gs\_expansion** for scaling:
+
+```
+# ./gs_expansion -U zxb -G zxb -X /opt/zxb/instance4.xml -h 90.90.44.165
+Start to preinstall database on the new standby nodes.
+Successfully preinstall database on the new standby nodes.
+
+Start to install database on the new standby nodes.
+
+installing database on node 90.90.44.165:
+Please enter the password of user [zxb] on node [90.90.44.165]:
+Parsing the configuration file.
+Check preinstall on every node.
+Successfully checked preinstall on every node.
+Creating the backup directory.
+Successfully created the backup directory.
+begin deploy..
+Installing the cluster.
+begin prepare Install Cluster..
+Checking the installation environment on all nodes.
+begin install Cluster..
+Installing applications on all nodes.
+Successfully installed APP.
+begin init Instance..
+encrypt cipher and rand files for database.
+Please enter password for database:
+Please repeat for database:
+begin to create CA cert files
+The sslcert will be generated in /usr1/zxb/opengauss/gaussdb/app/share/sslcert/om
+Cluster installation is completed.
+Configuring.
+Deleting instances from all nodes.
+Successfully deleted instances from all nodes.
+Checking node configuration on all nodes.
+Initializing instances on all nodes.
+Updating instance configuration on all nodes.
+Check consistence of memCheck and coresCheck on database nodes.
+Configuring pg_hba on all nodes.
+Configuration is completed.
+Successfully started cluster.
+Successfully installed application.
+end deploy..
+
+Successfully install database on node ['90.90.44.165']
+
+Database on standby nodes installed finished. Start to establish the primary-standby relationship.
+
+Success to expansion standby nodes.
+```
+
+## Helpful Links
+
+[gs\_preinstall](en-us_topic_0249632278.md), [gs\_install](en-us_topic_0249632258.md), and [gs\_ctl](en-us_topic_0249632282.md)
+
diff --git a/content/en/menu/index.md b/content/en/menu/index.md
index a3aa4559f..b545bb80c 100644
--- a/content/en/menu/index.md
+++ b/content/en/menu/index.md
@@ -1201,6 +1201,7 @@ headless: true
- [gs\_backup]({{< relref "./docs/Toolreference/gs_backup.md" >}})
- [gs\_basebackup]({{< relref "./docs/Toolreference/gs_basebackup.md" >}})
- [gs\_ctl]({{< relref "./docs/Toolreference/gs_ctl.md" >}})
+ - [gs\_expansion]({{< relref "./docs/Toolreference/gs_expansion.md" >}})
- [gs\_initdb]({{< relref "./docs/Toolreference/gs_initdb.md" >}})
- [gs\_install]({{< relref "./docs/Toolreference/gs_install.md" >}})
- [gs\_postuninstall]({{< relref "./docs/Toolreference/gs_postuninstall.md" >}})
diff --git "a/content/zh/docs/installation/\345\207\206\345\244\207\350\275\257\347\241\254\344\273\266\345\256\211\350\243\205\347\216\257\345\242\203.md" "b/content/zh/docs/installation/\345\207\206\345\244\207\350\275\257\347\241\254\344\273\266\345\256\211\350\243\205\347\216\257\345\242\203.md"
deleted file mode 100644
index 7b7bca086..000000000
--- "a/content/zh/docs/installation/\345\207\206\345\244\207\350\275\257\347\241\254\344\273\266\345\256\211\350\243\205\347\216\257\345\242\203.md"
+++ /dev/null
@@ -1,363 +0,0 @@
-# 准备软硬件安装环境
-
-本章节描述安装前需要进行的环境准备。
-
-
-
-- [软硬件环境要求](#软硬件环境要求)
- - [硬件环境要求](#硬件环境要求)
- - [软件环境要求](#软件环境要求)
- - [软件依赖要求](#软件依赖要求)
-- [修改操作系统配置](#修改操作系统配置)
- - [关闭操作系统防火墙](#关闭操作系统防火墙)
- - [设置字符集参数](#设置字符集参数)
- - [设置时区和时间](#设置时区和时间)
- - [关闭swap交换内存](#关闭swap交换内存)
- - [设置网卡MTU值](#设置网卡mtu值)
-- [设置root用户远程登录](#设置root用户远程登录)
-
-
-
-## 软硬件环境要求
-
-介绍openGauss的软硬件环境要求。建议部署openGauss的各服务器具有等价的软硬件配置。
-
-### 硬件环境要求
-
-[表1](#zh-cn_topic_0241802565_zh-cn_topic_0085434629_zh-cn_topic_0059782022_t62cd0eed17004265b1b8ad98f302a4bc)列出了openGauss服务器应具备的最低硬件要求。在实际产品中,硬件配置的规划需考虑数据规模及所期望的数据库响应速度。请根据实际情况进行规划。
-
-**表 1** 硬件环境要求
-
-
-
项目
- |
-配置描述
- |
-
-
-内存
- |
-功能调试建议32GB以上。
-性能测试和商业部署时,单实例部署建议128GB以上。
-复杂的查询对内存的需求量比较高,在高并发场景下,可能出现内存不足。此时建议使用大内存的机器,或使用负载管理限制系统的并发。
- |
-
-CPU
- |
-功能调试最小1×8 核 2.0GHz。
-性能测试和商业部署时,单实例部署建议1×16核 2.0GHz。
-CPU超线程和非超线程两种模式都支持。但是,openGauss各节点的设置需保持一致。
- |
-
-硬盘
- |
-用于安装openGauss的硬盘需最少满足如下要求:
-- 至少1GB用于安装openGauss的应用程序包。
- 每个主机需大约300MB用于元数据存储。
- 预留70%以上的磁盘剩余空间用于数据存储。
-建议系统盘配置为Raid1,数据盘配置为Raid5,且规划4组Raid5数据盘用于安装openGauss。有关Raid的配置方法在本手册中不做介绍。请参考硬件厂家的手册或互联网上的方法进行配置,其中Disk Cache Policy一项需要设置为Disabled,否则机器异常掉电后有数据丢失的风险。
-openGauss支持使用SSD盘作为数据库的主存储设备,支持SAS接口和NVME协议的SSD盘,以RAID的方式部署使用。
- |
-
-网络要求
- |
-300兆以上以太网。
-建议网卡设置为双网卡冗余bond。有关网卡冗余bond的配置方法在本手册中不做介绍。请参考硬件厂商的手册或互联网上的方法进行配置。
-openGauss网络如果配置bond,请保证bond模式一致,不一致的bond配置可能导致openGauss工作异常。
- |
-
-
-
-
-### 软件环境要求
-
-**表 2** 软件环境要求
-
-
-软件类型
- |
-配置描述
- |
-
-
-Linux操作系统
- |
-openEuler 20.3LTS和CentOS 7.6
- |
-
-Linux文件系统
- |
-剩余inode个数 > 15亿(推荐)
- |
-
-工具
- |
-bzip2
- |
-
-Python
- |
-- openEuler:支持Python 3.7.X
- CentOS:支持Python 3.6.X
- |
-
-
-
-
-### 软件依赖要求
-
-openGauss的软件依赖要求如[表 软件依赖要求](#table1212531681911)所示。
-
-建议使用上述操作系统安装光盘或者源中,下列依赖软件的默认安装包,若不存在下列软件,可参看软件对应的建议版本。
-
-**表 3** 软件依赖要求
-
-
-所需软件
- |
-建议版本
- |
-
-
-libaio-devel
- |
-建议版本:0.3.109-13
- |
-
-flex
- |
-要求版本:2.5.31 以上
- |
-
-bison
- |
-建议版本:2.7-4
- |
-
-ncurses-devel
- |
-建议版本:5.9-13.20130511
- |
-
-glibc.devel
- |
-建议版本:2.17-111
- |
-
-patch
- |
-建议版本:2.7.1-10
- |
-
-lsb_release
- |
-建议版本:4.1
- |
-
-
-
-
-## 修改操作系统配置
-
-### 关闭操作系统防火墙
-
-为了在防火墙开启的状态下,确保openGauss的正常使用。用户需要将同openGauss相关的服务、协议、IP以及端口添加到openGauss各主机的防火墙白名单中。
-
-以openEuler操作系统为例,假设openGauss信息如[表 openGauss信息](#zh-cn_topic_0241802566_zh-cn_topic_0085434636_zh-cn_topic_0059782018_table4312170510523)所示。
-
-**表 1** openGauss信息
-
-
-主机名称
- |
-内部IP
- |
-外部IP
- |
-
-
-plat1
- |
-192.168.0.11
- |
-10.10.0.11
- |
-
-plat2
- |
-192.168.0.12
- |
-10.10.0.12
- |
-
-plat3
- |
-192.168.0.13
- |
-10.10.0.13
- |
-
-plat4
- |
-192.168.0.14
- |
-10.10.0.14
- |
-
-管理网络
- |
--
- |
-10.10.64.236
- |
-
-
-
-
-**操作步骤**
-
-目前仅支持在防火墙关闭的状态下进行安装。
-
-1. 修改/etc/selinux/config文件中的“SELINUX“值为“disabled“。
-
- a. 使用VIM打开config文件。
-
- ```
- vim /etc/selinux/config
- ```
-
- b. 修改“SELINUX“的值“disabled“。
-
- ```
- SELINUX=disabled
- ```
-
-2. 重新启动操作系统。
-
- ```
- reboot
- ```
-
-3. 检查防火墙是否关闭。
-
- ```
- systemctl status firewalld
- ```
-
- 若防火墙未关闭,请执行[4](#li17330102819394);
-
- 若防火墙已关闭,则无需再关闭防火墙。
-
-4. 关闭防火墙。
-
- ```
- systemctl disable firewalld.service
- systemctl stop firewalld.service
- ```
-
-5. 在其他主机上重复步骤1到步骤4。
-
-### 设置字符集参数
-
-将各数据库节点的字符集设置为相同的字符集,可以在/etc/profile文件中添加"export LANG=XXX"(XXX为Unicode编码)。
-
-```
-vim /etc/profile
-```
-
-### 设置时区和时间
-
-将各数据库节点的时区设置为相同时区,可以将/usr/share/zoneinfo/目录下的时区文件拷贝为/etc/localtime文件。
-
-```
-cp /usr/share/zoneinfo/$地区/$时区 /etc/localtime
-```
-
-> **说明:**
->_$地区/$时区为需要设置时区的信息,例如:Asia_/Shanghai。
-
-使用date -s命令将各主机的时间设置为统一时间,举例如下。
-
-```
-date -s Mon May 11 16:42:11 CST 2020
-```
-
-> **说明:**
->可以通过date命令查询主机时区。
-
-### 关闭swap交换内存
-
-在各数据库节点上,使用swapoff -a命令将交换内存关闭。
-
-```
-swapoff -a
-```
-
-### 设置网卡MTU值
-
-将各数据库节点的网卡MTU值设置为相同大小。对于X86,MTU值推荐1500;对于ARM,MTU值推荐8192。
-
-```
-ifconfig 网卡编号 mtu 值
-```
-
-## 设置root用户远程登录
-
-在openGauss安装时需要root帐户远程登录访问权限,本章介绍如何设置使用root用户远程登录。
-
-1. 修改PermitRootLogin配置,允许用户远程登录。
-
- a. 打开sshd\_config文件。
-
- ```
- vim /etc/ssh/sshd_config
- ```
-
- b. 修改权限配置,可以使用以下两种方式实现:
- - 注释掉“PermitRootLogin no”。
-
- ```
- #PermitRootLogin no
- ```
-
- - 将“PermitRootLogin“改为“yes“。
-
- ```
- PermitRootLogin yes
- ```
-
- c. 执行**:wq**保存并退出编辑页面。
-
-2. 修改Banner配置,去掉连接到系统时,系统提示的欢迎信息。欢迎信息会干扰安装时远程操作的返回结果,影响安装正常执行。
-
- a. 编辑sshd\_config文件。
-
- ```
- vim /etc/ssh/sshd_config
- ```
-
- b. 修改Banner配置,注释掉“Banner”所在的行。
-
- ```
- #Banner XXXX
- ```
-
- c. 执行**:wq**保存并退出编辑页面。
-
-3. 使用如下命令使设置生效。
-
- ```
- service sshd restart
- ```
-
- > **注意:**
- >若执行命令后返回提示信息“Redirecting to /bin/systemctl restart sshd.service”,请执行命令:/bin/systemctl restart sshd.service。
-
-4. 以root用户身份重新登录。
-
- ```
- ssh xxx.xxx.xxx.xxx
- ```
-
- > **说明:**
- >xxx.xxx.xxx.xxx为安装openGauss环境的ip。
-
-
-
\ No newline at end of file
diff --git "a/content/zh/docs/installation/\345\256\271\345\231\250\345\256\211\350\243\205.md" "b/content/zh/docs/installation/\345\256\271\345\231\250\345\256\211\350\243\205.md"
index f310146ed..fc1894cff 100644
--- "a/content/zh/docs/installation/\345\256\271\345\231\250\345\256\211\350\243\205.md"
+++ "b/content/zh/docs/installation/\345\256\271\345\231\250\345\256\211\350\243\205.md"
@@ -1,77 +1,82 @@
-# 在docker上安装openGuass
-Docker构建文件,方便DevOps用户的安装、配置和环境设置。
-
-## 怎么创建和运行
-这个项目提供了简单的 Dockerfiles for:
-
- * openGauss_1.0.0
-
-构建docker镜像,可以用 [buildDockerImage.sh](dockerfiles/buildDockerImage.sh) 脚本. 下边是说明和帮助。
-
-`buildDockerImage.sh` 是一个方便以用的shell脚本,提供MD5的检查,对于初学者来说更容易上手。
-
-### 创建openGauss docker 镜像
-**重要:** 你要提供openGauss二进制安装包,放到 `dockerfiles/` 文件夹. 不需要解压. 二进制包可以从 [opengauss.org](https://opengauss.org/en/download.html)下载, 确保有正确的yum源. 如果你手动解压安装包会导致运行失败!
-
-在创建镜像前请确保提供了正确的二进制安装包并把他们放到了正确的文件夹 进入 **dockerfiles** 文件夹 运行 **buildDockerImage.sh** 脚本:
-
- [root@localhost dockerfiles]$ ./buildDockerImage.sh -h
- Usage: buildDockerImage.sh -v [version] [-i] [Docker build option]
- Builds a Docker Image for openGauss.
-
- Parameters:
- -v: version to build
- Choose one of: 1.0.0 SingleInstance
- -i: ignores the MD5 checksums
-
-### 环境变量
-为了更灵活的使用openGuass镜像,可以设置额外的参数。未来我们会扩充更多的可控制参数,当前版本支持以下变量的设定。
-
-#### `GS_PASSWORD`
-在你使用openGauss镜像的时候,必须设置该参数。该参数值不能为空或者不定义。该参数设置了openGauss数据库的超级用户omm以及测试用户gaussdb的密码。openGauss安装时默认会创建omm超级用户,该用户名暂时无法修改。测试用户gaussdb是在[docker-entry
-point.sh]中自定义创建的用户。
-
-openGauss镜像配置了本地信任机制,因此在容器内连接数据库无需密码,但是如果要从容器外部(其它主机或者其它容器)连接则必须要输入密码。
-
-**openGauss的密码有复杂度要求,需要:密码长度8个字符以上,必须同时包含英文字母,数字,以及特殊符号**
-
-#### `GS_NODENAME`
-
-指定数据库节点名称,默认为gaussdb。
-
-#### `GS_USERNAME`
-
-指定数据库连接用户名,默认为gaussdb。
-
-#### `GS_PORT`
-指定数据库端口,默认为5432。
-
-
-### 支持的架构和操作系统版本
-
-x86-64 CentOS 7.6
-ARM64 openEuler 20.03 LTS
-
-
-### 开启实例
-
-```console
-$ docker run --name opengauss --privileged=true -d -e GS_PASSWORD=secretpassword@123 opengauss:1.0.0
-```
-
-### 从操作系统层面连接数据库
-
-```console
-$ docker run −−name opengauss −−privileged=true −d −e GSPASSWORD=secretpassword@123 \
- −p8888:5432 opengauss:1.0.0 gsql -d postgres -U gaussdb -W'secretpassword@123' \
- -h your-host-ip -p8888
-```
-
-### 数据持久化
-
-```console
-$ docker run --name opengauss --privileged=true -d -e GS_PASSWORD=secretpassword@123 \
- -v /opengauss:/var/lib/opengauss opengauss:1.0.0
-```
-
-
+# 容器安装
+
+本章节主要介绍通过Docker安装openGauss,方便DevOps用户的安装、配置和环境设置。
+
+## 支持的架构和操作系统版本
+
+- x86-64 CentOS 7.6
+
+- ARM64 openEuler 20.03 LTS
+
+## 配置准备
+
+使用 buildDockerImage.sh脚本构建docker镜像,buildDockerImage.sh是一个方便使用的shell脚本,提供MD5的检查。
+
+## 创建openGauss docker镜像
+
+> **说明:**
+>- 安装前需要提供openGauss二进制安装包,放到 dockerfiles/文件夹,不需要解压。二进制包可以从 [https://opengauss.org/zh/download.html](https://opengauss.org/zh/download.html)下载,确保有正确的yum源,如果你手动解压安装包会导致运行失败。
+>- 当容器为centos环境时,需要预先从网络下载gosu-amd64文件并放到dockerfiles/ 文件夹下面,该文件下载地址:[https://github.com/tianon/gosu/releases/download/1.12/gosu-amd64](https://github.com/tianon/gosu/releases/download/1.12/gosu-amd64)。
+>- 当容器为openeuler环境时,需要预先从网络下载gosu-arm64文件并放到dockerfiles/ 文件夹下面,该文件下载地址:[https://github.com/tianon/gosu/releases/download/1.12/gosu-arm64](https://github.com/tianon/gosu/releases/download/1.12/gosu-arm64)。
+>- 安装前需要从华为开源镜像站获取openEuler\_aarch64.repo文件,并放到openGauss-server-master/docker/SingleInstance/dockerfiles/1.0.0文件夹下面。openEuler\_aarch64.repo获取方法:
+> ```
+> wget -O openEuler_aarch64.repo https://mirrors.huaweicloud.com/repository/conf/openeuler_aarch64.repo
+> ```
+
+在创建镜像前,请确保dockerfiles文件夹存在openGauss二进制安装包,在dockerfiles文件夹运行buildDockerImage.sh脚本。
+
+```
+[root@localhost dockerfiles]$ ./buildDockerImage.sh -h
+Usage: buildDockerImage.sh -v [version] [-i] [Docker build option]
+Builds a Docker Image for openGauss.
+Parameters:
+-v: version to build
+Choose one of: 1.0.0 SingleInstance
+-i: ignores the MD5 checksums
+```
+
+## 环境变量
+
+为了更灵活的使用openGuass镜像,可以设置额外的参数。未来我们会扩充更多的可控制参数,当前版本支持以下变量的设定。
+
+**GS\_PASSWORD**
+
+使用openGauss镜像的时候,必须设置该参数。该参数值不能为空或者不定义。该参数设置了openGauss数据库的超级用户omm以及测试用户gaussdb的密码。openGauss安装时默认会创建omm超级用户,该用户名暂时无法修改。测试用户gaussdb是在docker-entry point.sh中自定义创建的用户。
+
+openGauss镜像配置了本地信任机制,因此在容器内连接数据库无需密码,但是如果要从容器外部(其它主机或者其它容器)连接则必须要输入密码。
+
+**openGauss的密码有复杂度要求**
+
+密码长度8个字符以上,必须同时包含英文字母、数字、以及特殊符号。
+
+**GS\_NODENAME**
+
+指定数据库节点名称,默认为gaussdb。
+
+**GS\_USERNAME**
+
+指定数据库连接用户名,默认为gaussdb。
+
+**GS\_PORT**
+
+指定数据库端口,默认为5432。
+
+## 开启实例
+
+```
+$ docker run --name opengauss --privileged=true -d -e GS_PASSWORD=secretpassword@123 opengauss:1.0.0
+```
+
+## 从操作系统层面连接数据库
+
+```
+$ docker run ??name opengauss ??privileged=true ?d ?e GSPASSWORD=secretpassword@123 \ -p8888:5432 opengauss:1.0.0
+gsql -d postgres -U gaussdb -W'secretpassword@123' \ -h your-host-ip -p8888
+```
+
+## 数据持久化
+
+```
+$ docker run --name opengauss --privileged=true -d -e GS_PASSWORD=secretpassword@123 \ -v /opengauss:/var/lib/opengauss opengauss:1.0.0
+```
+
--
Gitee