Postgresql备份与恢复-pg_basebasckup

pg_basebackup用于对正在运行的PostgreSQL数据库集群进行基本备份。备份是在不影响数据库的其他客户端的情况下进行的，并且可以用于时间点恢复和作为日志传送或流复制备用服务器的起点 。
pg_basebackup 不仅可以从主服务器也可以从备用服务器进行基本备份。要从备用数据库进行备份，请设置备用数据库以便它可以接受复制连接（即 setmax_wal_senders和hot_standby，并对其进行pg_hba.conf适当配置）。您还需要在主节点上启用full_page_writes。

1.1 优点

a. 可以远程备份， 通过日志可以恢复到最新
b. 可以通过备库备份
c. 备份操作相关简单

1.2 不足

a. 它只把整个数据库实例的数据都拷贝出来，而不只是把实例中的部分（如某个数据库或表）单独备份
b. 归档日志需要单独备份
c. 使用复制协议 REPLICATION权限或者是超级用户的用户 ID 建立连接，并且pg_hba.conf必须允许复制连接。
d.服务器还必须配置max_wal_senders设置得足够高，以提供至少一个用于备份的 walsender 和一个用于 WAL 流式传输（如果使用）。
e.如果在备份期间将备用数据库提升为主数据库，则备份将失败。

1.3工作原理

1）创建检查点，打开FPW (full-page-write) ，创建备份标签（存储检查点位置，时间等信息）
2）通过流复制协议与数据库建立连接，主库的WAL Sender进程向pg_basebackup发送数据库物理文件
3）pg_basebackup接收到文件后写入目标位置（压缩或不压缩）

pg_basebackup --help

常用备份命令

pg_basebackup -D /tmp/pg_backup/ -Ft -Pv -U postgres -h 1.15.57.253 -p5432 -R

pg_basebackup -h 10.51.x.1x -D /data/pgsql/data -p 5432 -U repl -Fp -Xs -Pv -R --checkpoint=fast

• -D 空文件，没有该目录会自动创建
• F 格式化
• t 打包为tar包
• Pv 显示备份的详细过程
• -u 用户
• -p 端口
• 控制输出的选项：
• -D, --pgdata=DIRECTORY 接收基本备份到目录
• -F, --format=p|t 输出格式（plain（默认），tar）
• -r, --max-rate=RATE 传输数据目录的最大传输速率（以 kB/s 为单位，或使用后缀“k”或“M”）
• -R, --write-recovery-conf 用于复制的写入配置
• -T, --tablespace-mapping=OLDDIR=NEWDIR 将 OLDDIR 中的表空间重定位到 NEWDIR --waldir=WALDIR 预写日志目录的位置
• -X, --wal-method=none|fetch|stream 包含指定方法所需的 WAL 文件
• -z, --gzip 压缩 tar 输出 -Z, --compress=0-9 使用给定的压缩级别压缩 tar 输出 常规选项：
• -c, --checkpoint=fast|spread 设置快速或扩展检查点
• -C, --create-slot 创建复制槽
• -l, --label=LABEL 设置备份标签
• -n, --no-clean 出错后不清理
• -N, --no-sync 不等待更改安全写入磁盘
• -P, --progress 显示进度信息
• -S, --slot=SLOTNAME 要使用的复制槽
• -v, --verbose 输出详细信息
• -V, --version 输出版本信息，然后退出 --no-slot 防止创建临时复制槽 --no-verify-checksums 不验证校验和
• -?, --help 显示此帮助，然后退出
• 连接选项：
• -d, --dbname=CONNSTR 连接字符串
• -h, --host=HOSTNAME 数据库服务器主机或套接字目录
• -p, --port=PORT 数据库服务器端口号
• -s, --status-interval=状态包发送到服务器的间隔时间（以秒为单位）
• -U, --username=NAME 以指定的数据库用户连接
• -w, --no-password 从不提示输入密码
• -W, --password 强制密码提示（应该自动

3.pg_basebackup 备份示例

创建归档目录

mkdir -p /ssd/pg957/arch

chown -R postgres:postgres /ssd/pg957/arch

配置归档命令

vi $PGDATA/postgresql.conf

archive_mode = on

archive_command = 'DATE=`date +%Y%m%d`; DIR="/ssd/pg957/arch/$DATE"; (test -d $DIR || mkdir -p $DIR) && cp %p $DIR/%f'

wal_level = hot_standby

#备注说明 注释：

%p 表示xlog文件名$PGDATA的相对路径, 如pg_xlog/00000001000000190000007D

%f 表示xlog文件名, 如00000001000000190000007D

备注：

wal_level：指定生成wal日志的级别，值为minmal，archive，hot_standby。

确保从备份恢复和物理复制可能性的WAL级别由wal_level = replica设置。(在版本9.6之前，有两个独立的级别——archive和hot_standby——但后来它们被合并了)

minmal一般的配置，archive会生成wal归档需要的日志记录，hot_standby添加备库时需要设置。

在PostgreSQL中，wal_level参数用于设置写前日志（WAL）的详细程度。

这个设置对数据库的复制功能和性能有重要影响。

wal_level有三个可选值：minimal、replica和logical。

WAL级别的选择

• minimal: 这是最低级别的WAL记录，只包含恢复和立即关机所需的信息。它可以提高某些批量操作的性能，但不支持WAL归档和流复制。

• replica: 这是默认级别，提供足够的信息以支持WAL归档和流复制，允许在备用服务器上运行只读查询。这个级别适用于需要数据复制和高可用性的场景。

• logical: 这个级别在replica的基础上增加了支持逻辑解码的信息，允许更灵活的数据复制，如表和列的选择性复制，以及跨版本的数据同步。但是，使用logical级别会增加WAL的大小，特别是在进行大量更新和删除操作时。

参数测试：

从PostgreSQL 10开始，默认使用的就是这个级别(之前是最小级别)

ALTER SYSTEM RESET wal_level;

ALTER SYSTEM RESET max_wal_senders;

SELECT pg_current_wal_insert_lsn(); 

再来检查一下wal记录

=> DROP TABLE wallevel;

=> SELECT pg_current_wal_insert_lsn();

 pg_current_wal_insert_lsn

---------------------------

 0/353AF21C

(1 row)

=> CREATE TABLE wallevel AS

  SELECT 1 AS n;

=> SELECT pg_current_wal_insert_lsn();

 pg_current_wal_insert_lsn

---------------------------

 0/353BE51C

(1 row)

postgres$ /usr/lib/postgresql/11/bin/pg_waldump -p /var/lib/postgresql/11/main/pg_wal -s 0/353AF21C -e 0/353BE51C

PostgreSQL的WAL(4)--WAL创建和调优 - abce - 博客园

物理复制与逻辑复制

• 物理复制: 基于二进制日志的流复制，能够实现实时数据同步，适合构建高可用性的数据库系统。物理复制通过WAL日志实现主从库之间的数据同步，主库的数据变更实时传输到从库。

• 逻辑复制: 提供更高级的复制技术，允许选择性复制数据，适用于需要数据转换和过滤的复杂场景。逻辑复制可以在主库上执行数据转换和过滤操作，但可能会带来更高的延迟和资源消耗。

• 流复制
  PostgreSQL 的流复制（streaming replication）是一种基于二进制日志（binary log）的复制技术，它可以将一个 PostgreSQL 主库上的数据实时复制到一个或多个从库中。主库将修改后的数据写入二进制日志文件（WAL 日志），从库通过流式复制（streaming replication）将主库的 WAL 日志拷贝到本地，并将日志中的操作应用到自己的数据库中，从而实现数据的实时同步。

  在 PostgreSQL 的流复制中，有两种类型的从库：

  热备（Hot Standby）从库：它可以接收数据并执行只读查询，但不能执行写操作，因为所有写操作都必须在主库上执行。

  流式复制（Streaming Replication）从库：它可以接收数据并执行读写操作，因为它可以像主库一样执行写操作。

  流复制的优点在于它可以实现实时数据同步，并且可以在从库上执行读写操作，从而提高整个系统的可用性和性能。同时，流复制的实现非常稳定，并且已经被广泛应用于生产环境中。

  要启用流复制，需要在 PostgreSQL 的配置文件中设置一些参数，例如：

  主库配置

  wal_level = replica
  max_wal_senders = 5
  wal_keep_segments = 10

• 而到PG13版本wal_keep_segments改为了wal_keep_size来控制。

• （

  如果min_wal_size + wal_keep_segments 大于了max_wal_size，那么WAL日志空间至少也会占用：min_wal_size + wal_keep_segments。

  如果min_wal_size + wal_keep_segments小于max_wal_size，那么WAL日志空间尽量保持在max_wal_size。

  所以从这个原理来说：min_wal_size不需要设置太大，生产库只需要为1G左右大小时就够用了，不需要太大。

  而为了防止备库同步失败，应该设置一个较大的wal_keep_segments，WAL文件为16M大小，可把wal_keep_segments设置为500或更大。

  然后把max_wal_size比 min_wal_size + wal_keep_segments略大一点就可以了。

  而参数max_wal_size也会控制checkpoint发生的频繁程度：

  target = (double) ConvertToXSegs(max_wal_size_mb) / (2.0 + CheckPointCompletionTarget);
  如果checkpoint_completion_target设置为0.5时，则每写了 max_wal_size/2.5 的WAL日志时，就会发送一次checkpoint。

  checkpoint_completion_target的范围为0~1，那么结果就是写的WAL的日志量超过: max_wal_size的1/3～1/2时，就会发生一次checkpoint。

  ）

• 从库配置

  hot_standby = on
  primary_conninfo = 'host=master_ip_address port=5432 user=replica password=replica_pass'
  
  其中，wal_level 表示主库需要记录的 WAL 日志级别，max_wal_senders 表示主库可以同时发送 WAL 日志给多少个从库，wal_keep_segments 表示主库需要保留的 WAL 日志段数。而在从库中，hot_standby 表示是否启用热备功能，primary_conninfo 表示连接到主库的参数。

  流复制的具体实现步骤和细节较为复杂，需要结合具体的场景进行设置和调优。但是，一旦正确配置和使用，流复制可以帮助 PostgreSQL 构建高可用、高性能的数据库系统。

3.2. 重启并验证归档

重启数据库使参数生效，验证归档。

checkpoint; # 解释checkpoint做了什么

select pg_switch_wal() ; # 10g 以前用 select pg_switch_xlog();

[root@hgdb01 20180117]# pwd /ssd/pg957/arch/20180117

[root@hgdb01 20180117]# ls

000000020000000000000003 000000020000000000000004

3.3. 创建replication权限的角色

创建replication权限的角色, 或者超级用户的角色。

create role repl nosuperuser replication login connection limit 32 encrypted password '111111';

3.4. 配置pg_hba.conf

配置pg_hba.conf，添加以下内容 
host replication repl 0.0.0.0/0 md5

3.5. 执行备份

#因为使用流复制协议, 所以支持异地备份

pg_ctl reload #执行加载配置的命令

mkdir `date +%F` ;

pg_basebackup -F t -x -D /home/postgres/bak/`date +%F` -h 192.168.137.220 -p 5432 -U repl V12：

pg_basebackup -F t -X s -D /home/postgres/bak/`date +%F` -h 192.168.137.220 -p 5432 -U repl

3.6. 备份检查

备份完毕，查看备份文件 
[postgres@hgdb01 ~]$ cd /dbbak/2018-01-17 
[postgres@hgdb01 2018-01-17]$ ll 
total 46M -rw-rw-r--. 1 postgres postgres 1.5K Jan 17 01:13 16400.tar 
-rw-rw-r--. 1 postgres postgres 46M Jan 17 01:13 base.tar 
[postgres@hgdb01 2018-01-17]$ tar -tvf base.tar |less #查看备份包内容

3.7. 注意事项

pg_basebackup 备份参数 -F -t -X
 -F 指定了输出的格式，支持p（原样输出）或者t（tar格式输出）。
 -X 表示备份开始后，启动另一个流复制连接从主库接收WAL日志。 
16400表空间的oid 
简单讲述表空间的软连接 
[postgres@hgdb01 pg_tblspc]$ ls -l 
total 0 lrwxrwxrwx. 1 postgres postgres 14 Jan 17 01:04 16400 -> /pgtbls/tbls01 

4.pg_basebackup 恢复过程

4.1 切换日志

在需要备份的库中创建标记表EOR，并检查点和归档指令

create table t_flag(id int) ;

insert into t_flag values(1);

checkpoint; #刷新内存脏页到磁盘

select pg_switch_wal(); #手动日志归档

4.2 删除原数据

停止数据库并删除数据目录，将pg_basebackup生成的备份包分别解压到相应目录

pg_ctl stop -D /u01/postgresql/data_bak

清空 data_bak 里的文件

rm -rf /u01/postgresql/data_bak/*

#解决备份文件到指定目录

tar -xvf base.tar.gz -C /u01/postgresql/data_bak/

# 如果归档文件存在可以直接用归档文件

tar -xvf pg_wal.tar.gz -C /u01/postgresql/arch

4.3 恢复参数

pg12以前
在PG12以前需要修改 recovery.conf文件配置还原参数
cp PGHOME/share/recovery.conf.sample PGDATA/recovery.confviPGDATA/recovery.conf

#备注
restore_command = 'cp /ssd/pg957/arch/20180118/%f %p'
recovery_target_timeline = 'latest'
备注1：配置recovery_target_timeline参数, 便于判断是否已经到达还原点. (可选, 仅做PITR时需要.一般都是恢复到最新)
备注2：对路径 /ssd/pg957/arch/20180118/的解释
备注3：备份完成后recovery.conf文件名会自动修改为 recovery.done

pg12以后
从v12开始，针对此问题进行了改进，把recovery.conf中的参数合到了postgresql.conf配置文件中，但在非恢复模式这些参数将被忽略。

从PG12开始，recovery.conf文件不存在，由下面两个新文件进行替换：
recovery.signal：告诉PostgreSQL进入正常的归档恢复
standby.signal：告诉PostgreSQL进入standby模式
如果两个文件都存在，则standby.signal优先。

export PGDATA=/u01/postgresql/data_bak

# 告诉PostgreSQL进入正常的归档恢复

touch $PGDATA/recovery.signal

echo " restore_command = 'cp /u01/postgresql/arch/%f %p' recovery_target = 'immediate' " >> $PGDATA/postgresql.auto.conf

4.4 启动验证

启动数据库并做数据查看验证是否恢复完成

pg_ctl start -D /u01/postgresql/data_bak

5.基于时点恢复

5.1 恢复目标

默认情况下，恢复将恢复到 WAL 日志的末尾即，备份那一刻的日志。即recovery_target默认为immediate。
以下参数可用于指定较早的停止点。最多可以使用

  recovery_target
, recovery_target_lsn
, recovery_target_name
, recovery_target_time
, or之一；recovery_target_xid
如果在配置文件中指定了其中一个以上，则会引发错误。这些参数只能在服务器启动时设置。PostgreSQL: Documentation: 14: 20.5. Write Ahead Log

recovery_target = ’immediate’指定恢复应该在达到一个一致状态后尽快结束，即尽早结束。 在从一个在线备份中恢复时，这意味着备份结束的那个点。

recovery_target_time = '2022-02-07 13:45:00+08'
recovery_target_name (string)指定恢复将继续进行的已命名的恢复点 （pg_create_restore_point()创建）。
recovery_target_time (timestamp)这个参数指定恢复将继续执行的时间戳。精确的停止点也受到recovery_target_inclusive的影响。
recovery_target_xid (string)指定恢复将继续执行的事务ID。
recovery_target_inclusive (boolean)指定我们是否在指定的恢复目标之后停止（true）， 或者在恢复目标之前停止（false）。
recovery_target_timeline (string)指定恢复到一个特定的时间线中。默认值是沿着基础备份建立时的当前时间线恢复。
将这个参数设置为latest会恢复到该归档中能找到的最新的时间线， 这在一个后备服务器中有用。
recovery_target_action (enum) (boolean)指定当到达恢复目标时服务器应该采取什么动作。默认值是pause， 这意味着将暂停恢复。
promote意味着将结束恢复进程并且服务器开始接受连接。 shutdown将在到达恢复目标后停止服务器。

5.2 示例

基于时间点注意事项：
1. 归档日志完整
2. 指定从归档目录万利 restore_command = 'cp /u01/postgresql/arch/%f %p'
3.设置recovery_target_time 或 recovery_target_lsn 或 recovery_target_xid
4.创建touch $PGDATA/recovery.signal

#示例：

#设置基于时间的恢复 recovery_target_time = '2022-02-07 13:45:00+08'

#设置基于lsn,或 xid 的恢复 recovery_target_lsn 或 recovery_target_xid 可以通过pg_waldump 解析日志，来确定恢复目标 如本例需要恢复到COMMIT 可以设置 xid 为 '34' 或 lsn 为 '0/DA0000F8' recovery_target_xid='34' 或

recovery_target_lsn='0/DA0000F8'

postgres@s2ahumysqlpg01-> pg_waldump 0000000400000000000000DA

mgr: Standby len (rec/tot): 50/ 50, tx: 0, lsn: 0/DA000028, prev 0/D9000100, desc: RUNNING_XACTS nextXid 2173559 latestCompletedXid 2173558 oldestRunningXid 2173559 rmgr: Heap len (rec/tot): 54/ 150, tx: 2173559, lsn: 0/DA000060, prev 0/DA000028, desc: INSERT off 2 flags 0x00, blkref #0: rel 1663/13548/34369 blk 0 FPW rmgr: Transaction len (rec/tot): 34/ 34, tx: 2173559, lsn: 0/DA0000F8, prev 0/DA000060, desc: COMMIT 2022-02-21 17:40:31.486619 HKT rmgr: Standby len (rec/tot): 50/ 50, tx: 0, lsn: 0/DA000120, prev 0/DA0000F8, desc: RUNNING_XACTS nextXid 2173560 latestCompletedXid 2173559 oldestRunningXid 2173560 rmgr: XLOG len (rec/tot): 24/ 24, tx: 0, lsn: 0/DA000158, prev 0/DA000120, desc: SWITCH

5.3 恢复控制

pg_is_wal_replay_paused() →boolean 如果请求恢复暂停，则返回 true。 pg_get_wal_replay_pause_state() →text 返回恢复暂停状态。返回值是not paused是否未请求pause requested暂停，是否请求暂停但恢复尚未暂停，以及paused恢复是否实际暂停。 pg_promote ( wait boolean DEFAULT true, wait_seconds integer DEFAULT 60 ) → boolean 将备用服务器提升为主状态。wait如果设置为（默认值），该true函数会等待升级完成或wait_seconds秒数过去，true如果升级成功则返回，false否则返回。如果wait设置为false，则函数在向 postmastertrue发送SIGUSR1信号以触发提升后立即返回。 默认情况下，此功能仅限超级用户使用，但可以授予其他用户 EXECUTE 权限来运行该功能。 pg_wal_replay_pause() →void 请求暂停恢复。请求并不意味着恢复立即停止。如果要保证恢复实际上已暂停，则需要检查由pg_get_wal_replay_pause_state(). 请注意，

pg_is_wal_replay_paused()返回是否发出请求。恢复暂停时，不会应用进一步的数据库更改。如果热备用处于活动状态，所有新查询将看到相同的数据库快照，并且在恢复恢复之前不会产生进一步的查询冲突。 默认情况下，此功能仅限超级用户使用，但可以授予其他用户 EXECUTE 权限来运行该功能。

pg_wal_replay_resume() →void 如果已暂停，则重新启动恢复。 默认情况下，此功能仅限超级用户使用，但可以授予其他用户 EXECUTE 权限来运行该功能。 注意： pg_wal_replay_pause 和 pg_wal_replay_resume不能在提升主库时进行执行。如果在恢复暂停时触发了提升，则暂停状态结束并继续提升。

5.4 备份进度

在pg 14中备份进行可以通过下面这个视图查询
pg_stat_progress_basebackup

1 恢复备库案例

登录主库查看信息，这边查询到空白，证明主从已经断掉了：

select client_addr,sync_state from pg_stat_replication;
\x on
select * from pg_stat_replication;

ps -ef | grep wal

故障处理

由于环境问题，一小时产生的wal日志量超过100G以上，由于断开时间太久，只能重建主从，否则会丢数据。

这里的话从库数据已经跟主库不一致且wal日志追不上，先把从库的数据目录整个删除：

su - postgres
pg_ctl stop
rm -rf /data/pgsql/data/*

然后直接使用pg_basebackup工具把主库整个拉过来（有点类似myslq的克隆插件）：

pg_basebackup -h 10.51.x.1x -D /data/pgsql/data -p 5432 -U repl -Fp -Xs -Pv -R --checkpoint=fast

完成后需要修改配置文件里面的内容：

vim /data/pgsql/data/postgresql.conf
###修改连接数，一定要比主库大
max_connections = 2000
#从机信息和连接用户
primary_conninfo = 'host=10.51.0.109 user=repl password=123456'
#说明恢复到最新状态
recovery_target_timeline = latest
#大于主节点，正式环境重新考虑此值的大小
max_connections = 120
#说明这台机器不仅可以用户数据归档，还可以用于数据查询
hot_standby = on
#流备份的最大延迟时间
max_standby_archive_delay = 30s
#向主机汇报本地状态的间隔时间
wal_receiver_status_interval = 10s
#出现错误复制，向主机反馈
hot_standby_feedback = on
logging_collector = on
log_directory = 'pg_log'
log_filename = 'postgresql-%Y-%m-%d.log'

#在data下创建一个standby.signal文件 （默认情况刚刚发备份复制命令已经默认创建这个文件了只需要修改就行）

vim standby.signal
standby_mode = 'on'

修改完后启动：

su - postgres
pg_ctl start

启动后会有以下提示，表示需要等待回放wal日志：

但是我这边出现了一些小的故障问题，回放到某个部分的wal日志的时候提示已经被主库删除了：

去主库上查看，搜索这个wal日志，确实没有：

find /data/pgsql/data/pg_wal/xxxxxxxxxxxxxxxx

主要原因是主库默认情况下会自动删除wal日志，如果有配置上边的归档设置，只能去归档目录把wal日志拉回去pg_wal的目录下边（archive_commandcp %/data/pgsql/data/pg_archive/%f'）是归档的配置。

由于我这边的业务场景的原因，每小时产生的wal日志实在太多，此办法并不是最佳方法。

这个时候只能调整参数，让主库wal日志保留一定的数量，在主库的配置文件添加一下参数：

vim /data/pgsql/data/postgresql.conf
max_wal_senders = 10
wal_keep_size = 400GB
#让主库的pg_wal目录下的wal日志保留400G，按照我这边的业务增长，每小时100+G，400可以保留接近3小时，够时间恢复了
full_page_writes = on
wal_log_hints = on

###保存，然后重新加载一下配置文件
su - postgres
pg_ctl reload

操作后，重复上述操作，从删除从库的数据目录文件开始重新执行上述步骤。

特别注意的是复制完成后，记得配置文件把wal保留的配置给去掉在启动，启动成功后看日志文件，会看到正常回放，系统层面查看wal进程是否启动。

[root@bds-prd-pg-s data]# ps -ef | grep wal
root 5308 32711  0 11:02 pts/1    00:00:00 grep --color=auto wal
postgres 9131  8233  8 Feb07 ? 01:23:19 postgres: walreceiver streaming 2D593/28B7E000

数据库层面：

etl=#select pg_is_in_recovery();
pg_is_in_recovery
-------------------
f
(1 row)
####显示f为主库 t为从库
etl=# \x
Expanded display is on.
etl=#select * from pg_stat_replication;
-[ RECORD 1 ]----+------------------------------
pid | 8057
usesysid | 16384
usename | repl
application_name | walreceiver
client_addr | XX.XX.0.108
client_hostname |
client_port | 43306
backend_start | 2024-02-07 18:26:30.129682+08
backend_xmin | 62649322
state | streaming
sent_lsn | 2D596/48FA000
write_lsn | 2D596/48FA000
flush_lsn | 2D596/48FA000
replay_lsn | 2D596/48F9A70
write_lag | 00:00:00.023841
flush_lag | 00:00:00.030618
replay_lag | 00:00:00.249837
sync_priority | 0
sync_state | async
reply_time | 2024-02-08 11:05:57.224484+08

从库查看：

etl=# \x
Expanded display is on.
etl=#select * from pg_stat_wal_receiver;
-[ RECORD 1 ]
pid | 9131
status | streaming
receive_start_lsn | 2D23C/7D000000
receive_start_tli | 2
written_lsn | 2D59B/1BA50000
flushed_lsn | 2D59B/1BA50000
received_tli | 2
last_msg_send_time | 2024-02-08 11:12:09.260339+08
last_msg_receipt_time | 2024-02-08 11:12:09.263823+08
latest_end_lsn | 2D59B/1BA50000
latest_end_time | 2024-02-08 11:12:09.002218+08
slot_name |
sender_host | XX.XX.0.109
sender_port | 5432
conninfo | user=repl password=******** channel_binding=prefer dbname=replication host=10.51.0.109