备案控制台
探索云世界
开发者社区 数据库 关系型数据库 文章 正文

使用pg_resetxlog修复PostgreSQL控制文件的方法

2016-08-14 11524
版权
版权声明：
本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《 阿里云开发者社区用户服务协议》和 《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写 侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
本文涉及的产品
云原生数据库 PolarDB MySQL 版，Serverless 5000PCU 100GB
推荐场景：
PolarDB for MySQL 多主集群体验
云原生数据库 PolarDB 分布式版，标准版 2核8GB
推荐场景：
使用PolarDB-X与Flink搭建实时数据大屏
云数据库 RDS MySQL Serverless，0.5-2RCU 50GB
推荐场景：
学生管理系统数据库设计 搭建个人博客
简介： PostgreSQL 控制文件在$PGDATA/global目录下名为pg_control. 控制文件中记录了以下三部分信息 : 1. initdb时生成的静态信息 : pg_control version number: 922 C

PostgreSQL 控制文件在$PGDATA/global目录下名为pg_control.

控制文件中记录了以下三部分信息 :

1. initdb时生成的静态信息 :

pg_control version number:            922    
Catalog version number:               201204301    
Database system identifier:           5831753892046499175    
Maximum data alignment:               8    
Database block size:                  8192    
Blocks per segment of large relation: 131072    
WAL block size:                       16384    
Bytes per WAL segment:                16777216    
Maximum length of identifiers:        64    
Maximum columns in an index:          32    
Maximum size of a TOAST chunk:        1996    
Date/time type storage:               64-bit integers    
Float4 argument passing:              by value    
Float8 argument passing:              by value    
2. postgresql.conf中的配置信息 :     
Current wal_level setting:            hot_standby    
Current max_connections setting:      1000    
Current max_prepared_xacts setting:   10    
Current max_locks_per_xact setting:   64    
3. write-ahead logging以及checkpoint的动态信息 :     
Latest checkpoint location:           96E8/5B000020    
Prior checkpoint location:            96E8/5A0C8CC0    
Latest checkpoint's REDO location:    96E8/5B000020    
Latest checkpoint's TimeLineID:       1    
Latest checkpoint's full_page_writes: on    
Latest checkpoint's NextXID:          0/1183664222    
Latest checkpoint's NextOID:          309701    
Latest checkpoint's NextMultiXactId:  1    
Latest checkpoint's NextMultiOffset:  0    
Latest checkpoint's oldestXID:        1006759584    
Latest checkpoint's oldestXID's DB:   1    
Latest checkpoint's oldestActiveXID:  0    
Time of latest checkpoint:            Fri 11 Jan 2013 07:44:19 AM CST    
Minimum recovery ending location:     0/0    
Backup start location:                0/0    
Backup end location:                  0/0    
End-of-backup record required:        no

以上信息可以使用pg_controldata从pg_control获取 :

src/bin/pg_controldata/pg_controldata.c    
 * pg_controldata    
 *    
 * reads the data from $PGDATA/global/pg_control

如果控制文件$PGDATA/global/pg_control损坏或丢失, 数据库将运行异常, 无法启动.

如何修复? 关键在于恢复write-ahead logging以及checkpoint的动态信息.

这些信息可以从pg_xlog, pg_clog, pg_multixact这些目录的文件中解析出来。

pg_xlog的文件名解析可参看, 不同的段大小, 命名大不相同, pg_resetxlog的帮助文件适用16MB的段大小, 如果是其他大小, 需要重新计算名字 :
http://blog.163.com/digoal@126/blog/static/1638770402012914112949546/

接下来介绍一下使用pg_resetxlog重建pg_control的方法.
pg_resetxlog功能如下 :

src/bin/pg_resetxlog/pg_resetxlog.c    
 * pg_resetxlog.c    
 *        A utility to "zero out" the xlog when it's corrupt beyond recovery.    
 *        Can also rebuild pg_control if needed.    
 *    
 * The theory of operation is fairly simple:    
 *        1. Read the existing pg_control (which will include the last    
 *               checkpoint record).  If it is an old format then update to    
 *               current format.    
 *        2. If pg_control is corrupt, attempt to intuit reasonable values,    
 *               by scanning the old xlog if necessary.    
 *        3. Modify pg_control to reflect a "shutdown" state with a checkpoint    
 *               record at the start of xlog.    
 *        4. Flush the existing xlog files and write a new segment with    
 *               just a checkpoint record in it.  The new segment is positioned    
 *               just past the end of the old xlog, so that existing LSNs in    
 *               data pages will appear to be "in the past".    
 * This is all pretty straightforward except for the intuition part of    
 * step 2 ...

pg_resetxlog的用法 :

ocz@db-172-16-3-150-> pg_resetxlog --help    
pg_resetxlog resets the PostgreSQL transaction log.    
    
Usage:    
  pg_resetxlog [OPTION]... DATADIR    
    
Options:    
  -e XIDEPOCH      set next transaction ID epoch    
  -f               force update to be done    
  -l TLI,FILE,SEG  force minimum WAL starting location for new transaction log    
  -m XID           set next multitransaction ID    
  -n               no update, just show extracted control values (for testing)    
  -o OID           set next OID    
  -O OFFSET        set next multitransaction offset    
  -V, --version    output version information, then exit    
  -x XID           set next transaction ID    
  -?, --help       show this help, then exit

参数具体含义 :

-l timelineid,fileid,seg    
  The WAL starting address (-l) should be larger than any WAL segment file name currently existing in the    
directory pg_xlog under the data directory. These names are also in hexadecimal and have three parts. The    
first part is the “timeline ID” and should usually be kept the same. Do not choose a value larger than 255    
(0xFF) for the third part; instead increment the second part and reset the third part to 0. For example, if    
00000001000000320000004A is the largest entry in pg_xlog, -l 0x1,0x32,0x4B will work; but if the largest    
entry is 000000010000003A000000FF, choose -l 0x1,0x3B,0x0 or more.    
    Note    
    pg_resetxlog itself looks at the files in pg_xlog and chooses a default -l setting beyond the last    
    existing file name. Therefore, manual adjustment of -l should only be needed if you are aware of WAL    
    segment files that are not currently present in pg_xlog, such as entries in an offline archive; or if    
    the contents of pg_xlog have been lost entirely.    
    
-e XIDEPOCH    
  The transaction ID epoch is not actually stored anywhere in the database except in the field that is set by    
pg_resetxlog, so any value will work so far as the database itself is concerned. You might need to adjust    
this value to ensure that replication systems such as Slony-I work correctly - if so, an appropriate value    
should be obtainable from the state of the downstream replicated database.    
    
-x XID    
  A safe value for the next transaction ID (-x) can be determined by looking for the numerically largest file    
name in the directory pg_clog under the data directory, adding one, and then multiplying by 1048576. Note    
that the file names are in hexadecimal. It is usually easiest to specify the option value in hexadecimal    
too. For example, if 0011 is the largest entry in pg_clog, -x 0x1200000 will work (five trailing zeroes    
provide the proper multiplier).    
    
-m XID    
  A safe value for the next multitransaction ID (-m) can be determined by looking for the numerically largest    
file name in the directory pg_multixact/offsets under the data directory, adding one, and then multiplying    
by 65536. As above, the file names are in hexadecimal, so the easiest way to do this is to specify the    
option value in hexadecimal and add four zeroes.    
    
-O OFFSET    
   A safe value for the next multitransaction offset (-O) can be determined by looking for the numerically    
largest file name in the directory pg_multixact/members under the data directory, adding one, and then    
multiplying by 65536. As above, the file names are in hexadecimal, so the easiest way to do this is to    
specify the option value in hexadecimal and add four zeroes.    
    
-o OID    
  There is no comparably easy way to determine a next OID that's beyond the largest one in the database, but    
fortunately it is not critical to get the next-OID setting right.    
    
-n    
  no update, just show extracted control values (for testing)    
-f    
  force

测试步骤如下(基于PostgreSQL 9.2.1) :

  1. 新建测试数据, 用到with oids的表, 因为OID无法确定, 看看是否会有异常.
  2. 关闭数据库
  3. 记下pg_controldata信息, 方便修复后进行比对
  4. 删除$PGDATA/global/pg_control
  5. 开启数据库观察报错输出
  6. touch $PGDATA/global/pg_control
  7. 使用pg_resetxlog修复pg_control
  8. 记下pg_controldata信息, 与前面的pg_controldata输出进行比对
  9. 启动数据库
  10. 查看测试数据是否正常, 新插入数据

  11. 关闭数据库, 并记下pg_controldata的信息, 看看有何变化.

    测试过程 :

1. 测试数据

digoal=> create table oid_test(id int primary key) with oids;    
NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index "oid_test_pkey" for table "oid_test"    
CREATE TABLE    
digoal=> insert into oid_test select generate_series(1,100000);    
INSERT 0 100000    
digoal=> select min(oid),max(oid) from oid_test ;    
  min  |  max       
-------+--------    
 16397 | 116396    
(1 row)

2. 关闭数据

ocz@db-172-16-3-150-> pg_ctl stop -m fast    
waiting for server to shut down.... done    
server stopped

3. 记下pg_controldata信息, 方便修复后进行比对

ocz@db-172-16-3-150-> pg_controldata     
pg_control version number:            922    
Catalog version number:               201204301    
Database system identifier:           5832000131111550393    
Database cluster state:               shut down    
pg_control last modified:             Fri 11 Jan 2013 09:48:18 AM CST    
Latest checkpoint location:           96E8/5F000020    
Prior checkpoint location:            96E8/5EE5C698    
Latest checkpoint's REDO location:    96E8/5F000020    
Latest checkpoint's TimeLineID:       1    
Latest checkpoint's full_page_writes: on    
Latest checkpoint's NextXID:          0/1183842312    
Latest checkpoint's NextOID:          116414    
Latest checkpoint's NextMultiXactId:  65536    
Latest checkpoint's NextMultiOffset:  65536    
Latest checkpoint's oldestXID:        1006759584    
Latest checkpoint's oldestXID's DB:   1    
Latest checkpoint's oldestActiveXID:  0    
Time of latest checkpoint:            Fri 11 Jan 2013 09:48:18 AM CST    
Minimum recovery ending location:     0/0    
Backup start location:                0/0    
Backup end location:                  0/0    
End-of-backup record required:        no    
Current wal_level setting:            hot_standby    
Current max_connections setting:      1000    
Current max_prepared_xacts setting:   10    
Current max_locks_per_xact setting:   64    
Maximum data alignment:               8    
Database block size:                  8192    
Blocks per segment of large relation: 131072    
WAL block size:                       16384    
Bytes per WAL segment:                16777216    
Maximum length of identifiers:        64    
Maximum columns in an index:          32    
Maximum size of a TOAST chunk:        1996    
Date/time type storage:               64-bit integers    
Float4 argument passing:              by value    
Float8 argument passing:              by value

4. 删除$PGDATA/global/pg_control

ocz@db-172-16-3-150-> rm $PGDATA/global/pg_control     
rm: remove regular file `/data05/ocz/pg_root/global/pg_control'? y

5. 开启数据库观察报错输出

ocz@db-172-16-3-150-> pg_ctl start    
server starting    
ocz@db-172-16-3-150-> postgres: could not find the database system    
Expected to find it in the directory "/data05/ocz/pg_root",    
but could not open file "/data05/ocz/pg_root/global/pg_control": No such file or directory

接下来进行修复 :

6. touch $PGDATA/global/pg_control

ocz@db-172-16-3-150-> touch $PGDATA/global/pg_control    
ocz@db-172-16-3-150-> chmod 600 $PGDATA/global/pg_control

7. 使用pg_resetxlog修复pg_control

首先确定-l timelineid,fileid,seg的信息 :

ocz@db-172-16-3-150-> cd $PGDATA/pg_xlog    
ocz@db-172-16-3-150-> ll    
total 65M    
-rw------- 1 ocz ocz 16M Jan 11 09:39 00000001000096E80000005C    
-rw------- 1 ocz ocz 16M Jan 11 09:39 00000001000096E80000005D    
-rw------- 1 ocz ocz 16M Jan 11 09:48 00000001000096E80000005E    
-rw------- 1 ocz ocz 16M Jan 11 09:48 00000001000096E80000005F    
drwx------ 2 ocz ocz 44K Jan 11 09:48 archive_status

-l timelineid,fileid,seg 的数据来自pg_xlog文件名的三个部分, 分别占用8个16进制位.

段大小为16MB, 所以末端最大为0xFF.

得出-l 0x1,0x96E8,0x60

接下来确定-x XID的信息

来自pg_clog

ocz@db-172-16-3-150-> cd $PGDATA/pg_clog    
ocz@db-172-16-3-150-> ll -t|head -n 5    
total 43M    
-rw------- 1 ocz ocz 8.0K Jan 11 09:48 0469    
-rw------- 1 ocz ocz 216K Jan 10 21:00 0468    
-rw------- 1 ocz ocz 256K Jan 10 12:56 0467    
-rw------- 1 ocz ocz 256K Jan 10 09:35 0466

取最大值加1然后乘以1048576.

转换成16进制的话相当于取最大值加1然后末尾添加5个0

得到-x 0x046A00000

接下来确定-m XID的信息

来自pg_multixact/offsets

ocz@db-172-16-3-150-> cd $PGDATA/pg_multixact/offsets    
ocz@db-172-16-3-150-> ll    
total 0

取最大值加1然后乘以65536.

转换成16进制的话相当于取最大值加1然后末尾添加4个0

没有文件的话使用0加1, 然后末尾添加4个0

得到-m 0x10000

接下来确定-O OFFSET的信息

来自pg_multixact/members

ocz@db-172-16-3-150-> cd $PGDATA/pg_multixact/members    
ocz@db-172-16-3-150-> ll    
total 0

取最大值加1然后乘以65536.

转换成16进制的话相当于取最大值加1然后末尾添加4个0

没有文件的话使用0加1, 然后末尾添加4个0

得到-O 0x10000

最后, 不确定的值有2个 :

-e XIDEPOCH    ，如果么有使用 slony或者londiste这种基于触发器的数据同步软件，则-e意义不大，它实际上是在将32位的xid转换为64位的xid时使用的一个转换系数 。 
-o OID    , 系统会自动跳过已经分配的OID，自动容错，例如OID被别的程序使用掉了，PG会自动生成下一个OID，并且继续判断可用性。知道可用为止。

可以先不管这两个值.

执行pg_resetxlog 如下 :

ocz@db-172-16-3-150-> pg_resetxlog -l 0x1,0x96E8,0x60 -x 0x046A00000 -m 0x10000 -O 0x10000 -f $PGDATA    
pg_resetxlog: pg_control exists but is broken or unknown version; ignoring it    
Transaction log reset

8. 记下pg_controldata信息, 与前面的pg_controldata输出进行比对

ocz@db-172-16-3-150-> pg_controldata     
pg_control version number:            922    
Catalog version number:               201204301    
Database system identifier:           5832008033851373032    
Database cluster state:               shut down    
pg_control last modified:             Fri 11 Jan 2013 10:09:44 AM CST    
Latest checkpoint location:           96E8/60000020    
Prior checkpoint location:            0/0    
Latest checkpoint's REDO location:    96E8/60000020    
Latest checkpoint's TimeLineID:       1    
Latest checkpoint's full_page_writes: off    
Latest checkpoint's NextXID:          0/1184890880    
Latest checkpoint's NextOID:          10000    
Latest checkpoint's NextMultiXactId:  65536    
Latest checkpoint's NextMultiOffset:  65536    
Latest checkpoint's oldestXID:        3479858176    
Latest checkpoint's oldestXID's DB:   0    
Latest checkpoint's oldestActiveXID:  0    
Time of latest checkpoint:            Fri 11 Jan 2013 10:09:44 AM CST    
Minimum recovery ending location:     0/0    
Backup start location:                0/0    
Backup end location:                  0/0    
End-of-backup record required:        no    
Current wal_level setting:            minimal    
Current max_connections setting:      100    
Current max_prepared_xacts setting:   0    
Current max_locks_per_xact setting:   64    
Maximum data alignment:               8    
Database block size:                  8192    
Blocks per segment of large relation: 131072    
WAL block size:                       16384    
Bytes per WAL segment:                16777216    
Maximum length of identifiers:        64    
Maximum columns in an index:          32    
Maximum size of a TOAST chunk:        1996    
Date/time type storage:               64-bit integers    
Float4 argument passing:              by value    
Float8 argument passing:              by value

注意修复后从控制文件读取到的不确定的-e XIDEPOCH和-o OID信息如下 :

也就是initdb后的初始值.

Latest checkpoint's NextXID:          0/1184890880  : XIDEPOCH=0    
Latest checkpoint's NextOID:          10000

与修复pg_control前发生了变化的值如下 :
修复前

Database system identifier:           5832000131111550393    
pg_control last modified:             Fri 11 Jan 2013 09:48:18 AM CST    
Prior checkpoint location:            96E8/5EE5C698    
Latest checkpoint's full_page_writes: on    
Latest checkpoint's NextXID:          0/1183842312    
Latest checkpoint's NextOID:          116414    
Latest checkpoint's oldestXID:        1006759584    
Latest checkpoint's oldestXID's DB:   1    
Time of latest checkpoint:            Fri 11 Jan 2013 09:48:18 AM CST    
Current wal_level setting:            hot_standby    
Current max_connections setting:      1000    
Current max_prepared_xacts setting:   10

修复后

Database system identifier:           5832008033851373032    
pg_control last modified:             Fri 11 Jan 2013 10:09:44 AM CST    
Prior checkpoint location:            0/0    
Latest checkpoint's full_page_writes: off    
Latest checkpoint's NextXID:          0/1184890880    
Latest checkpoint's NextOID:          10000    
Latest checkpoint's oldestXID:        3479858176    
Latest checkpoint's oldestXID's DB:   0    
Time of latest checkpoint:            Fri 11 Jan 2013 10:09:44 AM CST    
Current wal_level setting:            minimal    
Current max_connections setting:      100    
Current max_prepared_xacts setting:   0

9. 启动数据库

ocz@db-172-16-3-150-> pg_ctl start    
server starting    
ocz@db-172-16-3-150-> LOG:  00000: loaded library "pg_stat_statements"    
LOCATION:  load_libraries, miscinit.c:1249

10. 查看测试数据是否正常, 然后新插入数据

ocz@db-172-16-3-150-> psql digoal digoal    
psql (9.2.1)    
Type "help" for help.    
digoal=> select min(oid),max(oid),count(*) from oid_test ;    
  min  |  max   | count      
-------+--------+--------    
 16397 | 116396 | 100000    
(1 row)

数据可以正常访问.

新插入数据 :

digoal=> insert into oid_test select generate_series(100001,200000);    
INSERT 0 100000    
digoal=> select min(oid),max(oid),count(*) from oid_test ;    
  min  |  max   | count      
-------+--------+--------    
 16384 | 116396 | 200000    
(1 row)    
digoal=> select oid,* from oid_test where oid=16397;    
  oid  |   id       
-------+--------    
 16397 |      1    
 16397 | 100014    
(2 rows)

注意oid出现了重复, 印证了PostgreSQL中的说明, OID不确保唯一性.

11. 关闭数据库, 并记下pg_controldata的信息, 看看有何变化.

ocz@db-172-16-3-150-> pg_ctl stop -m fast    
waiting for server to shut down.... done    
server stopped    
ocz@db-172-16-3-150-> pg_controldata     
pg_control version number:            922    
Catalog version number:               201204301    
Database system identifier:           5832008033851373032    
Database cluster state:               shut down    
pg_control last modified:             Fri 11 Jan 2013 10:16:18 AM CST    
Latest checkpoint location:           96E8/61000020    
Prior checkpoint location:            96E8/60DFF470    
Latest checkpoint's REDO location:    96E8/61000020    
Latest checkpoint's TimeLineID:       1    
Latest checkpoint's full_page_writes: on    
Latest checkpoint's NextXID:          0/1184890883    
Latest checkpoint's NextOID:          116385    
Latest checkpoint's NextMultiXactId:  65536    
Latest checkpoint's NextMultiOffset:  65536    
Latest checkpoint's oldestXID:        1006759584    
Latest checkpoint's oldestXID's DB:   1    
Latest checkpoint's oldestActiveXID:  0    
Time of latest checkpoint:            Fri 11 Jan 2013 10:16:18 AM CST    
Minimum recovery ending location:     0/0    
Backup start location:                0/0    
Backup end location:                  0/0    
End-of-backup record required:        no    
Current wal_level setting:            hot_standby    
Current max_connections setting:      1000    
Current max_prepared_xacts setting:   10    
Current max_locks_per_xact setting:   64    
Maximum data alignment:               8    
Database block size:                  8192    
Blocks per segment of large relation: 131072    
WAL block size:                       16384    
Bytes per WAL segment:                16777216    
Maximum length of identifiers:        64    
Maximum columns in an index:          32    
Maximum size of a TOAST chunk:        1996    
Date/time type storage:               64-bit integers    
Float4 argument passing:              by value    
Float8 argument passing:              by value

关闭数据库后与刚修复好时的控制文件信息变化如下 :
开库前 :

pg_control last modified:             Fri 11 Jan 2013 10:09:44 AM CST    
Latest checkpoint location:           96E8/60000020    
Prior checkpoint location:            0/0    
Latest checkpoint's REDO location:    96E8/60000020    
Latest checkpoint's full_page_writes: off    
Latest checkpoint's NextXID:          0/1184890880    
Latest checkpoint's NextOID:          10000    
Latest checkpoint's oldestXID:        3479858176    
Latest checkpoint's oldestXID's DB:   0    
Time of latest checkpoint:            Fri 11 Jan 2013 10:09:44 AM CST    
Current wal_level setting:            minimal    
Current max_connections setting:      100    
Current max_prepared_xacts setting:   0

关库后 :

pg_control last modified:             Fri 11 Jan 2013 10:16:18 AM CST    
Latest checkpoint location:           96E8/61000020    
Prior checkpoint location:            96E8/60DFF470    
Latest checkpoint's REDO location:    96E8/61000020    
Latest checkpoint's full_page_writes: on    
Latest checkpoint's NextXID:          0/1184890883    
Latest checkpoint's NextOID:          116385    
Latest checkpoint's oldestXID:        1006759584    
Latest checkpoint's oldestXID's DB:   1    
Time of latest checkpoint:            Fri 11 Jan 2013 10:16:18 AM CST    
Current wal_level setting:            hot_standby    
Current max_connections setting:      1000    
Current max_prepared_xacts setting:   10

小结

1. 使用pg_resetxlog后, 先检查数据一致性, 必要时将数据导出, 使用initdb新建数据库, 再导入.

2. 如果控制文件丢失, 并且没有备份的话, pg_resetxlog你不知道该填啥, 但是可以从pg_xlog目录中获得大概的redo location, 或者pg_resetxlog 会猜测一些值, 直接-f生成控制文件, 启动数据库后, 可能由于XID回归到以前的XID而致使数据"消失", 你可以使用txid_current()函数不断的消耗XID来得到一致的值.

http://blog.163.com/digoal@126/blog/static/163877040201183043153622/
http://blog.163.com/digoal@126/blog/static/163877040201251911813661/

使用pg_xlogdump从xlog中抽取信息, 包括txid.
http://blog.163.com/digoal@126/blog/static/16387704020134993845555/

pg_resetxlog的版本必须要与数据库集群的版本一致。

注意

控制文件和PostgreSQL的大版本相关，建议用户使用pg_resetxlog前，看一看对应版本的使用说明。

参考

1. man pg_controldata
2. man pg_resetxlog
3. http://blog.163.com/digoal@126/blog/static/163877040201171233710582/
4. http://blog.163.com/digoal@126/blog/static/1638770402012914112949546/
5. http://www.postgresql.org/docs/9.2/static/wal-internals.html
6. http://www.postgresql.org/docs/9.2/static/app-pgresetxlog.html
7. http://www.postgresql.org/docs/9.2/static/pgupgrade.html
8. http://www.postgresql.org/docs/9.2/static/continuous-archiving.html
9. src/bin/pg_resetxlog/pg_resetxlog.c
10. src/include/catalog/pg_control.h
11. src/bin/pg_controldata/pg_controldata.c
12. src/backend/access/transam/clog.c
13. src/include/access/clog.h
14. src/backend/access/transam/xlog.c
15. src/include/access/xlog.h

祝大家玩得开心，欢迎随时来 阿里云促膝长谈业务需求 ，恭候光临。

阿里云的小伙伴们加油，努力 做好内核与服务，打造最贴地气的云数据库 。

文章标签：
云原生数据库 PolarDB
数据库
关系型数据库
PostgreSQL
关键词：
云数据库 RDS PostgreSQL 版方法
相关实践学习
使用PolarDB和ECS搭建门户网站
本场景主要介绍基于PolarDB和ECS实现搭建门户网站。
阿里云数据库产品家族及特性
阿里云智能数据库产品团队一直致力于不断健全产品体系，提升产品性能，打磨产品功能，从而帮助客户实现更加极致的弹性能力、具备更强的扩展能力、并利用云设施进一步降低企业成本。以云原生+分布式为核心技术抓手，打造以自研的在线事务型(OLTP)数据库Polar DB和在线分析型(OLAP)数据库Analytic DB为代表的新一代企业级云原生数据库产品体系， 结合NoSQL数据库、数据库生态工具、云原生智能化数据库管控平台，为阿里巴巴经济体以及各个行业的企业客户和开发者提供从公共云到混合云再到私有云的完整解决方案，提供基于云基础设施进行数据从处理、到存储、再到计算与分析的一体化解决方案。本节课带你了解阿里云数据库产品家族及特性。
德哥,digoal
目录
相关文章
德哥,digoal
|
SQL 关系型数据库 分布式数据库
PostgreSQL 在线修改数据类型 - online ddl 方法之一
标签 PostgreSQL , online ddl , trigger , ddl 事务 背景 有张表的主键id是serial，但现在不够了，需要升级成bigserial，有什么优雅的方法吗？我看下来好像会锁表很久（因为数据量挺大） 如果直接alter table，由于数据类型从4字节改成了8字节，而tuple结构是在METADATA里面的，不是每行都有，所以DEFORM需要依赖METADATA，目前来说，这种操作需要rewrite table。
德哥,digoal
3624 0
德哥,digoal
|
关系型数据库 数据挖掘 数据库
PostgreSQL 模糊查询最佳实践 - (含单字、双字、多字模糊查询方法)
PostgreSQL 模糊查询最佳实践 - (含单字、双字、多字模糊查询方法)https://github.com/digoal/blog/blob/master/201704/20170426_01.md
德哥,digoal
13637 0
德哥,digoal
|
监控 关系型数据库 测试技术
PostgreSQL 双节点流复制如何同时保证可用性、可靠性(rpo,rto) - （半同步，自动降级方法实践）
PostgreSQL 双节点流复制如何同时保证可用性、可靠性(rpo,rto) - （半同步，自动降级方法实践）
德哥,digoal
1156 0
德哥,digoal
|
弹性计算 监控 关系型数据库
PostgreSQL 双节点流复制如何同时保证可用性、可靠性(rpo,rto) - （半同步，自动降级方法实践）
标签 PostgreSQL , 同步 , 半同步 , 流复制 背景 两节点HA架构，如何做到跨机房RPO=0(可靠性维度)？同时RTO可控(可用性维度)？ 半同步是一个不错的选择。 1、当只挂掉一个节点时，可以保证RPO=0。如下： 主 -> 从（挂） 主（挂） -> 从 2、当一个节点挂掉后，在另一个节点恢复并开启同步模式前，如果在此期间（
德哥,digoal
2067 0
德哥,digoal
|
关系型数据库 数据库 PostgreSQL
PostgreSQL 粗心设错session_preload_libraries的补救方法
标签 PostgreSQL , session_preload_libraries , psql: FATAL: could not access file "pg_pathman": No such file or directory 背景 由于粗心，设错了session_preload_l...
德哥,digoal
1678 0
德哥,digoal
|
SQL 关系型数据库 网络安全
PostgreSQL 大版本升级方法之一 - 不落地并行导出导入
标签 PostgreSQL , 大版本升级 , rds_dbsync , pg_dump , pg_restore 背景 尽量快的大版本升级的方法。 一、9.4以下版本，使用pg_dump并行导出，pg_restore并行导入，迁移 (导出使用源版本pg_dump，导入使用目标版本pg_restore。
德哥,digoal
1919 0
德哥,digoal
|
SQL 关系型数据库 数据库
PostgreSQL 设计优化case - 大宽表任意字段组合查询索引如何选择(btree, gin, rum) - (含单个索引列数超过32列的方法)
标签 PostgreSQL , adhoc查询 , 大宽表 , 任意字段组合查询 , 索引 , btree , gin , rum 背景 大宽表，任意字段组合查询，透视。是实时分析系统中的常见需求： 1、实时写入。
德哥,digoal
2479 0
德哥,digoal
|
关系型数据库 PostgreSQL 索引
PostgreSQL 模拟两个update语句死锁 - 利用扫描方法
德哥,digoal
3236 0
德哥,digoal
|
关系型数据库 PostgreSQL
Greenplum 与 PostgreSQL 修改元数据(catalog)的方法 allow_system_table_mods
德哥,digoal
2783 0
李博 bluemind
|
监控 负载均衡 关系型数据库
PostgreSQL 10.1 手册_部分 III. 服务器管理_第 26 章 高可用、负载均衡和复制_26.4. 日志传送的替代方法
26.4. 日志传送的替代方法 26.4.1. 实现 26.4.2. 基于记录的日志传送 前一节描述的内建后备模式的一种替代方案是使用一个轮询归档位置的 restore_command。这是版本 8.4 及以下版本中唯一可用的选项。
李博 bluemind
1228 0
数据库

关系型数据库

热门文章

最新文章

  • 1
    你的数据库用对索引了吗？一文揭秘PolarDB XPlan索引选择
  • 2
    为PostgreSQL讨说法 - 浅析《UBER ENGINEERING SWITCHED FROM POSTGRES TO MYSQL》
  • 3
    德哥的PostgreSQL私房菜 - 史上最屌PG资料合集
  • 4
    什么场景应该用 MongoDB ？
  • 5
    PostgreSQL 如何实现批量更新、删除、插入
  • 6
    PostgreSQL upsert功能(insert on conflict do)的用法
  • 7
    Linux 性能诊断 perf使用指南
  • 8
    PostgreSQL 9种索引的原理和应用场景
  • 9
    PostgreSQL 如何潇洒的处理每天上百TB的数据增量
  • 10
    Jedis常见异常汇总
  • 1
    PolarDB闪电助攻，《香肠派对》百亿好友关系实现毫秒级查询
    36
  • 2
    【MySQL系列笔记】MVCC
    29
  • 3
    你的数据库用对索引了吗？一文揭秘PolarDB XPlan索引选择
    62518
  • 4
    【MySQL系列笔记】索引
    84
  • 5
    【MySQL系列笔记】隔离锁
    82
  • 6
    【MySQL系列笔记】事务
    62
  • 7
    超1/3中国500强企业都在用的「汇联易」，为什么选用阿里云RDS？
    134349
  • 8
    PolarDB +AnalyticDB Zero-ETL ：免费同步数据到ADB，享受数据流通新体验
    101536
  • 9
    详解MySQL字符集和Collation
    128884
  • 10
    RDS MySQL 数据库运维简述
    761

    • 相关产品

  • 云原生数据库 PolarDB
    文档详情 产品详情

    • 相关课程

    更多
  • 7天突破PolarDB for PostgreSQL 2022版
  • PolarDB for PostgreSQL 内核解读系列课程
  • PolarDB for PostgreSQL 入门
  • PostgreSQL实战进阶
  • PostgreSQL云上开发实践
  • PolarDB for PostgreSQL 开源人才初级认证培训课程

    • 相关电子书

    更多
  • PostgresChina2018_王帅_从Oracle到PostgreSQL的数据迁移
  • 阿里云PostgreSQL、PPAS、HDB for PG生
  • 为什么PostgreSQL是最适合去O的数据库

    • 相关实验场景

    更多
  • 阿里云百炼xAnalyticDB PostgreSQL构建AIGC应用
  • PolarDB for PostgreSQL 闪回特性体验
  • 函数计算X RDS PostgreSQL，基于LLM大语言模型构建AI知识库
  • 如何基于PolarDB-PG处理空间数据
  • PolarDB for PostgreSQL 14：全局索引
  • 如何一键本地部署PolarDB for PostgreSQL

    • 推荐镜像

    更多
  • postgresql
  • mongodb
  • mysql
    • 下一篇
    阿里云oss简介和使用流程
    为什么选择阿里云什么是云计算全球基础设施技术领先稳定可靠安全合规分析师报告
    产品和定价全部产品免费试用产品动态产品定价价格计算器云上成本管理
    解决方案技术解决方案
    文档与社区文档开发者社区天池大赛培训与认证
    权益中心免费试用高校计划企业扶持计划推荐返现计划
    支持与服务基础服务企业增值服务迁云服务官网公告健康看板信任中心
    关注阿里云
    关注阿里云公众号或下载阿里云APP，关注云资讯，随时随地运维管控云服务
    阿里云APP阿里云微信
    联系我们：4008013260
    法律声明Cookies政策廉正举报安全举报联系我们加入我们
    阿里巴巴集团淘宝网天猫全球速卖通阿里巴巴国际交易市场1688阿里妈妈飞猪阿里云计算AliOS万网高德UC友盟优酷钉钉支付宝达摩院淘宝海外阿里云盘饿了么
    © 2009-2024 Aliyun.com 版权所有 增值电信业务经营许可证： 浙B2-20080101 域名注册服务机构许可： 浙D3-20210002 京D3-20220015
    浙公网安备 33010602009975号浙B2-20080101-4