PostgreSQL Windows\Linux\FreeBSD的数据文件通用吗

标签

PostgreSQL , Linux , Windows , 数据文件 , 存储格式


背景

PostgreSQL是一个跨平台的数据库,比如支持WindowS, AIX , linux , freebsd等。

同时也支持不同架构例如X86,ARM等。

对于相同架构,不同平台,是否能实现文件级别的平移,甚至物理的流复制搭建STANDBY呢?

理论上从数据库的存储层面来看,如果两个平台存储结构(比如堆表、索引、WAL日志,CLOG等)一致,是可以平移的。

比如Windows,Linux,都是x64的,那么能不能平移? - 答案是可行的,之前平移过freebsd和linux的。(位数必须一致,32和64可不行)

从PostgreSQL代码中,并未找到存储层面不一致的地方,大家可以搜一下#ifdef WIN之类的,通常与Linux的系统调用(比如共享内存段的分配,内部进程通信等)差异较多,但是数据库本身存储层面没有找到差异。

那么我们来验证一下将Windows中的数据文件,拷贝到Linux下面使用的场景。

安装Windows PostgreSQL软件

建议下载已经打包好的二进制。

https://www.enterprisedb.com/download-postgresql-binaries

https://www.enterprisedb.com/postgresql-962-binaries-win64?ls=Crossover&type=Crossover

解压到d:\pgsql

初始化数据库

C:\windows\system32>d:  

D:\>cd pgsql  

D:\pgsql>cd bin  

D:\pgsql\bin>initdb.exe -D d:\pgsql/data -E SQL_ASCII -U postgres --locale=C
属于此数据库系统的文件宿主为用户 "dege.zzz".
此用户也必须为服务器进程的宿主.
数据库簇将使用本地化语言 "C"进行初始化.
缺省的文本搜索配置将会被设置到"english"  

禁止为数据页生成校验和.  

创建目录 d:/pgsql/data ... 成功
正在创建子目录 ... 成功
选择默认最大联接数 (max_connections) ... 100
选择默认共享缓冲区大小 (shared_buffers) ... 128MB
选择动态共享内存实现 ......windows
创建配置文件 ... 成功
正在运行自举脚本 ...成功
正在执行自举后初始化 ...成功
同步数据到磁盘...成功  

警告:为本地连接启动了 "trust" 认证.
你可以通过编辑 pg_hba.conf 更改或你下次
行 initdb 时使用 -A或者--auth-local和--auth-host选项.  

成功。您现在可以用下面的命令开启数据库服务器:  

    "pg_ctl" -D "d:\pgsql/data" -l logfile start

配置参数

d:\pgsql\data\postgresql.conf  

修改如下配置  

port = 1951
log_destination = 'csvlog'  

logging_collector = on

启动数据库

D:\pgsql\bin>pg_ctl.exe start -D "d:\pgsql\data"
正在启动服务器进程  

D:\pgsql\bin>LOG:  redirecting log output to logging collector process
HINT:  Future log output will appear in directory "pg_log".

查看控制文件内容

D:\pgsql\bin>pg_controldata.exe "d:\pgsql\data"
pg_control 版本:                      960
Catalog 版本:                         201608131
数据库系统标识符:                     6395009439800837980
数据库簇状态:                         在运行中
pg_control 最后修改:                  2017/3/8 14:25:08
最新检查点位置:                       0/14EB8B0
优先检查点位置:                       0/14EB618
最新检查点的 REDO 位置:               0/14EB8B0
最新检查点的重做日志文件: 000000010000000000000001
最新检查点的 TimeLineID:              1
最新检查点的PrevTimeLineID: 1
最新检查点的full_page_writes: 开启
最新检查点的NextXID:          0:542
最新检查点的 NextOID:                 12402
最新检查点的NextMultiXactId: 1
最新检查点的NextMultiOffsetD: 0
最新检查点的oldestXID:            535
最新检查点的oldestXID所在的数据库:1
最新检查点的oldestActiveXID:  0
最新检查点的oldestMultiXid:  1
最新检查点的oldestMulti所在的数据库:1
最新检查点的oldestCommitTsXid:0
最新检查点的newestCommitTsXid:0
最新检查点的时间:                     2017/3/8 14:22:46
不带日志的关系: 0/1使用虚假的LSN计数器
最小恢复结束位置: 0/0
最小恢复结束位置时间表: 0
开始进行备份的点位置:                       0/0
备份的最终位置:                  0/0
需要终止备份的记录:        否
wal_level设置:                    minimal
wal_log_hints设置:        关闭
max_connections设置:   100
max_worker_processes设置:   8
max_prepared_xacts设置:   0
max_locks_per_xact设置:   64
track_commit_timestamp设置:        关闭
最大数据校准:     8
数据库块大小:                         8192
大关系的每段块数:                     131072
WAL的块大小:    8192
每一个 WAL 段字节数:                  16777216
标识符的最大长度:                     64
在索引中可允许使用最大的列数:    32
TOAST区块的最大长度:                1996
大对象区块的大小:         2048
日期/时间 类型存储:                   64位整数
正在传递Flloat4类型的参数:           由值
正在传递Flloat8类型的参数:                   由值
数据页校验和版本:  0

连接数据库,写入测试数据

D:\pgsql\bin>psql.exe -h 127.0.0.1 -p 1951 -U postgres postgres
psql (9.6.2)
输入 "help" 来获取帮助信息.  

postgres=# create table test(id int primary key, info text, crt_time timestamp);  

CREATE TABLE  

postgres=# insert into test select generate_series(1,100000),md5(random()::text),clock_timestamp();
INSERT 0 100000  

postgres=# checkpoint;
CHECKPOINT  

postgres=# select sum(hashtext(test.*::Text)) from test;
     sum
--------------
 210964261159
(1 行记录)  

postgres=# \q

停库、打包、发送到linux x64

D:\pgsql\bin>pg_ctl.exe stop -m fast -D "d:\pgsql\data"
等待服务器进程关闭 .... 完成
服务器进程已经关闭  

打包d:\pgsql\data  

发送到linux

安装Linux PostgreSQL软件

参考

《PostgreSQL on Linux 最佳部署手册》

解压数据

unzip data.zip

修改配置

vi data/postgresql.conf  

注释
#dynamic_shared_memory_type = windows

修改数据目录权限

chmod -R 700 data

启动数据库

pg_ctl start -D ./data  

pg_controldata
pg_control version number:            960
Catalog version number:               201608131
Database system identifier:           6376040558507154751
Database cluster state:               shut down
pg_control last modified:             Wed 08 Mar 2017 11:15:19 AM CST
Latest checkpoint location:           3C/8B000028
Prior checkpoint location:            3C/8AF86CA0
Latest checkpoint's REDO location:    3C/8B000028
Latest checkpoint's REDO WAL file:    000000010000003C0000008B
Latest checkpoint's TimeLineID:       1
Latest checkpoint's PrevTimeLineID:   1
Latest checkpoint's full_page_writes: on
Latest checkpoint's NextXID:          0:88072139
Latest checkpoint's NextOID:          173243
Latest checkpoint's NextMultiXactId:  1
Latest checkpoint's NextMultiOffset:  0
Latest checkpoint's oldestXID:        1668
Latest checkpoint's oldestXID's DB:   1
Latest checkpoint's oldestActiveXID:  0
Latest checkpoint's oldestMultiXid:   1
Latest checkpoint's oldestMulti's DB: 1
Latest checkpoint's oldestCommitTsXid:0
Latest checkpoint's newestCommitTsXid:0
Time of latest checkpoint:            Wed 08 Mar 2017 11:15:18 AM CST
Fake LSN counter for unlogged rels:   0/1
Minimum recovery ending location:     0/0
Min recovery ending loc's timeline:   0
Backup start location:                0/0
Backup end location:                  0/0
End-of-backup record required:        no
wal_level setting:                    replica
wal_log_hints setting:                off
max_connections setting:              5000
max_worker_processes setting:         128
max_prepared_xacts setting:           0
max_locks_per_xact setting:           64
track_commit_timestamp setting:       off
Maximum data alignment:               8
Database block size:                  8192
Blocks per segment of large relation: 131072
WAL block size:                       8192
Bytes per WAL segment:                16777216
Maximum length of identifiers:        64
Maximum columns in an index:          32
Maximum size of a TOAST chunk:        1996
Size of a large-object chunk:         2048
Date/time type storage:               64-bit integers
Float4 argument passing:              by value
Float8 argument passing:              by value
Data page checksum version:           0

验证数据是否正确

psql -h 127.0.0.1 -p 1951 -U postgres postgres  

postgres=# select sum(hashtext(test.*::Text)) from test;
     sum
--------------
 210964261159
(1 row)

测试插入更新删除等。

postgres=# update test set info ='new';
UPDATE 100000
postgres=# create table test1(id int, info text, crt_time timestamp);
CREATE TABLE
postgres=# insert into test1 select * from test;
INSERT 0 100000

小结

1. 目前来看,PostgreSQL在不同平台下的存储结构是一致的,所以只要CPU架构一致,是可以实现跨平台的物理文件平移的。

2. 平移时,注意软件的编译项一致(比如数据块的大小等)。

3. 平移前,如果还安装了其他插件例如PostGIS,那么也必须在目标安装对应的插件。

4. 注意修改postgresql.conf,达到兼容。(比如动态内存分配策略,预加载动态库的位置等)

时间: 2025-01-09 07:06:45

PostgreSQL Windows\Linux\FreeBSD的数据文件通用吗的相关文章

[20151025]linux下删除数据文件的恢复细节3

[20151025]linux下删除数据文件的恢复细节3.txt --以前曾经写过一篇关于 --链接:http://blog.itpub.net/267265/viewspace-763969/ --里面提到实际上这种方式对于生产系统不是很合适,而且生产系统情况非常复杂,不可能出现删除数据文件时没有事务产生. --这种方式仅仅适合no archivelog的模式(没有办法的选择),我当时还提到这种方式一定要快,因为我的测试执行 alter system --checkpoint;,数据库直接cr

[20151023]linux下删除数据文件的恢复细节2

[20151023]linux下删除数据文件的恢复的一些细节问题(补充).txt --以前曾经写过一篇关于 --链接:http://blog.itpub.net/267265/viewspace-763969/ --里面提到实际上这种方式对于生产系统不是很合适,而且生产系统情况非常复杂,不可能出现删除数据文件时没有事务产生. --这种方式仅仅适合no archivelog的模式(没有办法的选择),我当时还提到这种方式一定要快,因为我的测试执行 alter system --checkpoint;

[20151028]linux下删除数据文件的恢复细节4

[20151028]linux下删除数据文件的恢复细节4 --前几天一直在做删除数据文件的恢复测试,中间遇到许多问题自己无法解决,从我个人讲我不主张使用句柄的方式来恢复,而更愿意 --使用rman的方式,这种情况仅仅适合非归档模式. --前几天的测试非常混乱,我自己都不知道为什么在删除数据文件的情况下有时候执行alter system checkpoint数据库会直接crash,有 --时候为什么有不会.我再把整个恢复过程做一个总结: 1.测试环境: SCOTT@test> @ &r/ver

[20130614]linux下删除数据文件的恢复的一些细节问题.txt

[20130614]linux下删除数据文件的恢复的一些细节问题.txt 前天看了链接:http://space.itpub.net/26015009/viewspace-763506 我仅仅做一些测试以及补充,以及注意的细节问题,实际上最好的方法依旧是使用rman备份恢复. 1.测试环境: --session 1 SQL> @ver BANNER --------------------------------------------------------------------------

Linux下将数据文件的指定域读取到shell脚本中

这个例子说明了怎样在Linux下shell脚本中从数据文件读取特定的域(field)并进行操作.例如,假设文件employees.txt的格式是{employee-name}:{employee-id}:{department-name},以冒号进行划分,如下所示. $ cat employees.txt Emma Thomas:100:Marketing Alex Jason:200:Sales Madison Randy:300:Product Development Sanjay Gupt

请教windows下有所有的数据文件,控制文件,但没有参数文件,如何恢复?

我在itpub论坛上遇到的一个问题,并做了回答,分享一下: 一.如果仅仅是参数文件丢失,数据库仍然运行,可用如下代码:set linesize 120set pagesize 999set heading offset feedback offspool F:\spfile.txt  select '*.'||name||'='||value from v$parameter where isdefault ='FALSE';  spool off来获取当前实例的非缺省参数,对生成的临时参数文件

直接复制数据文件实现linux平台数据库复制到windows平台数据库

一.1  平台环境概述   之前在测试传输表空间时感受了一下跨平台的移值,当时只测试了通过传输表空间的特性复制某个指定表空间,或者是通过RMAN中的CONVERT或TTS复制数据库,测试结束之后,感觉ORACLE10G之后对不同平台(相同字节顺序)的数据文件相互兼容性方面得到大大提升,下意识认为不通过传输表空间直接复制数据文件应该也可以,今天在本地测试了一下,确实相当好使,通过这种方式使得跨平台的移植更加高效,也易于管理和操作,下面记录的为操作过程. 注意:源平台与目标平台的字节顺序(endia

解决-从linux服务器中读取文件数据

问题描述 从linux服务器中读取文件数据 现有一个需求: 在一台服务器上写日志文件,每当日志文件写到一定大小时,比如是1G,会将这个日志文件改名成另一个名字,并新建一个与原文件名相同的日志文件,再往这个新建的日志文件里写数据:要求写一个程序能实时地读取日志文件中的内容,并且不能写日志操作.重命名操作.不能修改日志文件的任何数据,保持日志文件的完整性. 首先,这个问题在windows下几乎无解,因为一个程序打开了一个文件,再要对文件重命名是不可能的:而在Linux下,可以得到完美解决.因为Lin

备份-linux采集远程windows服务器上的数据

问题描述 linux采集远程windows服务器上的数据 问题:公司有上百台windows服务器,我需要在每天将这些服务器上的某些文件备份到一台linux服务器中,如何做最方便?每天的总数据量不超过10g 解决方案 如果文件特别多的话可能时间比较长,如果是大文件的话网速快就行了 解决方案二: window 配置FTP->linux设置计划任务->每天拉