文件postgresql数据库

2017Postgres大象会PGConf.
CN2017PostgreSQL故障恢复技术内幕嘉宾:唐成公司:杭州乘数科技2017Postgres大象会PGConf.
CN2017自我介绍姓名:唐成,网名osdba杭州乘数科技创始人、CTO《PostgreSQL修炼之道:从小工到专家》作者专注于PostgreSQL、Greenplum数据库历任网易开发专家、阿里巴巴高级数据库专家关注我http://blog.
osdba.
nethttp://osdbablog.
sinaapp.
com2017Postgres大象会PGConf.
CN2017目录异常宕机下为什么能不丢数据1PostgreSQL实例恢复的总体设计2WAL日志文件的秘密3PostgreSQL多版本的秘密4控制文件中的秘密52017Postgres大象会PGConf.
CN2017为什么异常宕机下都能不丢数据导致数据库实例异常终止的原因–被kill掉,如内存不足时被OOMKiller给kill掉了–操作系统崩溃–硬件故障导致机器停机或重启只要磁盘上的数据没有丢失,PostgreSQL就不会丢失数据2017Postgres大象会PGConf.
CN2017为什么异常宕机下都能不丢数据不丢数据的定义–数据库实例还能再次启动–已提交的数据,数据库重启后还在–不会出现数据错乱的情况2017Postgres大象会PGConf.
CN2017不丢数据的基本原理每项操作记录到重做日志中,实例重新启动后,重演(replay)日志,这个动作称为"前滚"–"前滚"完成后,多数数据库还会把未完成的事务取消掉,就象这些事务从来没有执行过一样.
这个动作称之为"回滚"–在"前滚"过程中,数据库是不能被用户访问的.
–每次"前滚"时,从哪个点开始Checkpoint点的概念登场了:保证Checkpoint点之前的数据已持久化到硬盘中了.
发生Checkpoint点的周期通常在几分钟2017Postgres大象会PGConf.
CN2017目录异常宕机下为什么能不丢数据1PostgreSQL实例恢复的总体设计2WAL日志文件的秘密3PostgreSQL多版本的秘密4控制文件中的秘密52017Postgres大象会PGConf.
CN2017PostgreSQL"不丢数据"总体设计数据文件WAL文件控制文件记录上次checkpoint点时WAL日志的位置.
文件为global/pg_control记录重做日志,每次事务提交后,所做操作必须先持久化到此文件中.
在目录pg_xlog下事务提交后,所做操作不必马上持久化,但checkpoint点之前的数据必须持久化到数据文件中所在目录:base//事务状态文件记录每个事务的状态,是提交还是已回滚,具体见后面的多版本实现.
文件在目录pg_clog下2017Postgres大象会PGConf.
CN2017PostgreSQL实例恢复过程从控制文件中读取checkpoint点,checkpoint点中记录了上次发生checkpoint时WAL日志的位置从上次发生checkpoint时WAL日志的位置开始读取WAL日志文件,开始重新应用WAL日志中的内容.
不断的读取WAL日志的内容,直接读到最后,结束恢复过程.
2017Postgres大象会PGConf.
CN2017目录异常宕机下为什么能不丢数据1PostgreSQL实例恢复的总体设计2WAL日志文件的秘密3PostgreSQL多版本的秘密4控制文件中的秘密52017Postgres大象会PGConf.
CN2017如何定位WAL日志文件的2017Postgres大象会PGConf.
CN2017WAL日志位置的表示日志位置用LSN来表示:LogSequenceNumber,是WAL日志的绝对位置第1次写了210字节第2次写了320字节第3次写了220字节LSN=210LSN=210+320=530LSN=530+220=750LSN实际上是用64bit的一个数字来表示2017Postgres大象会PGConf.
CN2017WAL日志文件的秘密WAL日志文件名由24个字母组成,文件名中就有起始的WAL日志的位置2017Postgres大象会PGConf.
CN2017WAL日志文件名文件名的组成:000000010000000000000086时间线LogIdLogSeg2017Postgres大象会PGConf.
CN2017WAL日志名的组成文件名由24字符组成–时间线:英文为timeline,是以1开始的递增数字,如1,2,3.
.
.
–LogId:32bit长的一个数字,是以0开始递增的数字,如0,1,2,3.
.
.
.
实际为LSN的高32bit–LogSeg:32bit长的一个数字,是以0开始递增的数字,如0,1,2,3.
.
.
.
–LogSeg是LogSeg是LSN的低32bit的字节的值再除以WAL文件大小(16M)的结果.
注意:当LogId为0时,LogSeg是从1开始的.
2017Postgres大象会PGConf.
CN2017WAL日志名的组成WAL日志文件默认大小为16M–如果想改变大小,需要重新编译程序.
所以LogSeg最大为FF,即从000000~0000FF,即在文件名中,最后8字节中前6字节总是0.
2**32/(16M)=256,即FF.
2017Postgres大象会PGConf.
CN2017一个恢复的例子恢复时,会从此WAL文件开始000000010000000F0000005C2017Postgres大象会PGConf.
CN2017一个恢复的例子最后一个WAL文件000000010000000F000000982017Postgres大象会PGConf.
CN2017一个恢复的例子恢复时,会从此WAL文件000000010000000F0000005C开始,是否一直重放日志到WAL日志目录下的最后一个WAL文件000000010000000F000000982017Postgres大象会PGConf.
CN2017一个恢复的例子是否一直重放到目录下的最后一个WAL文件000000010000000F00000098答案是否定的,为什么因为这个文件通常并不是最后一个WAL日志文件2017Postgres大象会PGConf.
CN2017WAL日志文件复用机制为了解释上一个疑问,我们需要说明WAL日志的循环复用机制.
PostgreSQL数据库并不象Oracle数据库那个有固定多个Redolog文件.
Oralce有固定多个Redolog文件,然后进行循环写.
2017Postgres大象会PGConf.
CN2017WAL日志文件复用机制Oralce循环写Redolog时,当覆盖一个redolog文件时,需要保证这个redolog所代表的脏数据已被checkpoint刷新到数据文件中了.
PostgreSQL也是通过循环写的方式,覆盖一个WAL日志文件时,也需要把相应的脏数据刷到数据文件中.
2017Postgres大象会PGConf.
CN2017WAL日志文件的复用机制PostgreSQL的WAL日志文件名,看起来是一直增长的,不象是循环写啊看起来象是新建了一个文件,然后把旧文件删除掉了.
而且为什么要循环写啊2017Postgres大象会PGConf.
CN2017WAL日志文件复用机制循环写是为了提升性能–如果每次生成新文件,新文件是否要初使化成16M如果要初使化成16M,会产生额外的IO.
–如果不初使化,使用append的方式,文件的长度每次增加,这时需要更新文件的元数据,也会产生额外的开销.
2017Postgres大象会PGConf.
CN2017WAL日志文件复用机制WAL日志复用是通过"重命名"来实现的.
当发生一次checkpoint之后,这个checkpoint点之前的WAL日志文件都可以删除掉了,而PostgreSQL并不是删除掉,而是"重命名"这个旧的WAL文件.
2017Postgres大象会PGConf.
CN2017WAL日志文件复用机制的例子假设当前目录下的文件:000000010000000F0000000C~000000010000000F00000098这时发生了一个checkpoint点,checkpiont点所在的文件000000010000000F0000005C2017Postgres大象会PGConf.
CN2017WAL日志文件复用机制的例子checkpoint点之前的WAL文件都可以被改名掉,即000000010000000F0000000C~000000010000000F0000005B当前最后一个WAL日志文件名为000000010000000F00000098,所以生成的第一个文件名为:000000010000000F000000992017Postgres大象会PGConf.
CN2017WAL日志文件复用机制的例子000000010000000F0000000C~000000010000000F0000005B的文件被"改名",当前最后一个文件名:000000010000000F00000098000000010000000F0000000C改名为000000010000000F00000099000000010000000F0000000D改名为000000010000000F000000A0000000010000000F0000000E改名为000000010000000F000000A1000000010000000F0000005B改名为000000010000000F000000E82017Postgres大象会PGConf.
CN2017WAL日志文件复用机制补充改名用的技巧–并不是用rename,而是使用建新的硬链接,删除旧文件的方法–这种方法更通用,同时也一样可靠2017Postgres大象会PGConf.
CN2017WAL日志文件复用机制补充重命令WAL,有时也不一定会把checkpoint点之前的WAL文件都重删除掉,还受一些参数的影响:–wal_keep_segments–hot_standby_feedback–replicationslots–min_wal_size、max_wal_size2017Postgres大象会PGConf.
CN2017目录异常宕机下为什么能不丢数据1PostgreSQL实例恢复的总体设计2WAL日志文件的秘密3PostgreSQL多版本的秘密4控制文件中的秘密52017Postgres大象会PGConf.
CN2017删除数据之后能否恢复场景:–deletefromtesttab01;删除一张表的内容之后,能否恢复–没有备份2017Postgres大象会PGConf.
CN2017删除数据之后能否恢复从理论上来说,是可以恢复的.
–因为从PostgreSQL的MVCC机制上说,数据并没有马上删除掉,只是在数据行上标志了删除标记那么PostgreSQL是如何打"删除"标记的2017Postgres大象会PGConf.
CN2017PostgreSQL数据库MVCC的原理PostgreSQL是没有回滚段的,当更新一行数据时,旧行不动,只是在旧行上打上"删除标记",把原数据行新复制出一行.
所以从理论上说,相对Oracle来说PostgreSQL更容易恢复原先的数据.
因为Oracle是把旧数据放到回滚段中,恢复旧数据行会更复杂一些.
2017Postgres大象会PGConf.
CN2017PostgreSQL数据库MVCC的原理这是有几个疑问–因为每次更新,都是插入新行,数据文件越来越大怎么办旧数据的空间什么时候能被回收–虽然是更新操作,但生成的新行的物理位置发生了变化,这些与更新值无关的索引是否也需要更新这是否会带来更大的开销2017Postgres大象会PGConf.
CN2017PostgreSQL数据库MVCC的原理第一个疑问–旧数据是通过一种垃圾回收的机制来处理的–这种机制叫做vacuum第二个疑问–通常不会的,因为PostgreSQL提供了一种叫HOT技术.
2017Postgres大象会PGConf.
CN2017VACUUM原理讲解vacuum命令–PostgreSQL提供了vacuum命令,可以手工对垃圾数据进行回收autovacuum–PostgreSQL自动启动一些进程叫autovacuum,自动会进行垃圾数据回收2017Postgres大象会PGConf.
CN2017VACUUM的一些疑问vacuum的运行会不会影响性能–有很多参数控制这个影响在可以接受的范围内:vacuum_cost_delay,vacuum_cost_limitvacuum的运行是否会阻塞正常操作–普通的vacuum不会阻塞正常操作–vacuumfull会.
2017Postgres大象会PGConf.
CN2017VACUUM的一些疑问普通vacuum和vacuumfull的区别–如果表的数据文件已膨胀到了一定的大小,普通vacuum通常不会让数据文件变小.
它只是在数据文件中的数据块中标记出一些空闲空间,这些空闲空间可以被下次复用,但不能被回收–vacuumfull能回收空间,但在做vacuumfull时,不能对表做正常的操作.
2017Postgres大象会PGConf.
CN2017VACUUM中的一些经验对于频繁更新的表应该更频繁的执行普通vacuum操作以防止表膨胀–不要有长时间idle事务这会导致这个事务之后产生的垃圾数据都不能被回收,因为vacuum认认这部分数据有可能会被你这个事务访问.
lock_timeout、statement_timeout2017Postgres大象会PGConf.
CN2017删除数据之后能恢复的条件如果开启了autovacuum–数据还不有被autovacuum回收掉–autovacuum的运行周期通常在10秒到数分钟之间,所以如果要想恢复数据,立即把postgresql的进程kill掉,或直接关电源,这才可能.
2017Postgres大象会PGConf.
CN2017删除数据之后能恢复的条件如果开启了autovacuum–还有一种可能,就是数据库中有一个在删除操作之前就开始的长事务在运行,还没有结束,这时,这部分旧数据不会被回收.
2017Postgres大象会PGConf.
CN2017删除数据之后能恢复的条件如果没有开启autovacuum–这时不要做vacuum,数据都还是可能恢复的.
2017Postgres大象会PGConf.
CN2017如何打"删除"标记的在第行上有两个系统字段xmin、xmax–在更新操作中,复制出来的新行上的xmin会填写当前操作的事务ID,而xmax填0–在旧行上的xmax填写当前的事务ID实际上是在行上打事务ID的方式实现打"删除"标记的2017Postgres大象会PGConf.
CN2017insert和delete打标记的方法对于insert操作来说–只需要把新行上的xmin会填写当前操作的事务ID即可,而xmax填0对于delete操作–只需要把要删除的行上的xmax会填写当前操作的事务ID即可2017Postgres大象会PGConf.
CN2017事务回滚了怎么办因为行上的xmin和xmax是事务ID,但事务如果回滚了,这个标记就相当于没有用了.
所以还需要查询这些事务是已提交还是已回滚了,这时候commitlog就登上了历史舞台–当然还有即没有提交也还没有回滚的事务的情况,如正在运行的事务的情况,这种情况后面再说2017Postgres大象会PGConf.
CN2017回顾PostgreSQL总体设计数据文件WAL文件控制文件记录上次checkpoint点时WAL日志的位置.
文件为global/pg_control记录重做日志,每次事务提交后,所做操作必须先持久化到此文件中.
在目录pg_xlog下事务提交后,所做操作不必马上持久化,但checkpoint点之前的数据必须持久化到数据文件中所在目录:base//事务状态文件记录每个事务的状态,是提交还是已回滚,具体见后面的多版本实现.
文件在目录pg_clog下2017Postgres大象会PGConf.
CN2017CommitLog简称clog–在数据目录的pg_clog,pg_log目录下的文件可以删除,这个目录下的文件千万不能删除–每个事务的状态用两个bit来表示:#defineTRANSACTION_STATUS_IN_PROGRESS0x00#defineTRANSACTION_STATUS_COMMITTED0x01#defineTRANSACTION_STATUS_ABORTED0x02#defineTRANSACTION_STATUS_SUB_COMMITTED0x032017Postgres大象会PGConf.
CN2017事务ID可以无限多个吗不能–如果能的话,commitlog就会无限制的增长下去.
–同时每次查询一个事务ID的状态时,也会变慢2017Postgres大象会PGConf.
CN2017事务ID的设计事务ID,简称xid–是一个32bit的数字–当到达一个最大值时,又会从一个最小值开始–可以想像是需要一种回收的机制来复用xid–当旧数据中的xid用一个特殊的值FrozenXID,即2来替换,原xid就能被再次重用.
2017Postgres大象会PGConf.
CN2017事务ID的设计0231230231+230事务id的范围可以认为组成了一个圆事务id从3开始,到达最大之后又变回3(0,1,2被占用了,后面再详解)由vacuum把一些已提交的事务ID换成FrozeXID,保证当前最小的事务ID到当前事务ID的范围小于231,这样就能有新的事务ID可分配.
把FrozeXID认为是已提交的事务vacuum把已回滚的行直接回收掉,把行上xmin为已提交事务的ID换成FrozeXID.
2017Postgres大象会PGConf.
CN2017事务iD的设计有三个特殊值的事务ID–0:InvalidXID,无效事务ID–1:BootstrapXID,表示系统表初使化时的事务ID,比任务普通的事务ID都旧.
–2:FrozenXID,冻结的事务ID,比任务普通的事务ID都旧.
–大于2的事务ID都是普通的事务ID2017Postgres大象会PGConf.
CN2017事务ID的设计commitlog的大小–理论上,数据库中事务ID最多231个,每个事务占用2bit,所以commitlog最大512M字节–实际上参数autovacuum_freeze_max_age为2亿,表示最旧事务ID到当前事务ID为2亿,所以commitlog通常最大大小为50M左右.
2017Postgres大象会PGConf.
CN2017vacuum的注意事项autovacuum_freeze_max_age设置为2亿–如果最旧的事务ID到当前要分配的事务ID接近2亿时,会强制启动vacuum.
–所以要经常运行vacuum,保证数据库中太旧的事务ID的年龄不要接近2亿.
2017Postgres大象会PGConf.
CN2017目录异常宕机下为什么能不丢数据1PostgreSQL实例恢复的总体设计2WAL日志文件的秘密3PostgreSQL多版本的秘密4控制文件中的秘密52017Postgres大象会PGConf.
CN2017控制文件中的秘密2017Postgres大象会PGConf.
CN2017控制文件中的秘密数据库的唯一标识串的秘密–Databasesystemidentifier:6197591927813975882–initdb时生成的一个64bit的整数,生成过程为:gettimeofday(&tv,NULL);sysidentifier=((uint64)tv.
tv_sec)>32)&(2^32-1)::bigint));2017Postgres大象会PGConf.
CN2017控制文件中的秘密为什么有两个lastcheckpoint2017Postgres大象会PGConf.
CN2017控制文件中的秘密实例恢复时,会从上面的哪个checkpoint点开始applyredo日志–checkpoint本身也会在WAL中写一个日志,这条日志的位置为就是"Lastestcheckpointlocation"–当发生checkpoint点时WAL日志的当前位置为"Latestcheckpoint'sREDOlocation"2017Postgres大象会PGConf.
CN2017控制文件中的秘密Standby库的控制文件的秘密–Standby库的控制文件与主库是否相同–主库控制文件中的checkpoint信息是否会复制到Standby库–"Minimumrecoveryendinglocation"2017Postgres大象会PGConf.
CN2017控制文件中的秘密备库中每replay一些WAL日志后,就会做一次checkpoint点,然后把这个checkpoint点的信息记录到控制文件中.
备库replay一些日志后,会把产生脏数据的最新日志的位置记录到"Minimumrecoveryendinglocation".
为什么要记录呢为了Standby库只读的功能.
备库异常停机后再启动,需要replay日志到超过"Minimumrecoveryendinglocation"位置后,才能对外提供只读服务,或才能激活成主库.
2017Postgres大象会PGConf.
CN2017控制文件中的秘密以下几个参数的意义是什么–Backupstartlocation–Backupendlocation–End-of-backuprecordrequired2017Postgres大象会PGConf.
CN2017控制文件中的秘密主库上执行pg_start_backup('mybackup');把主库数据目录拷贝到备库编辑recovery.
conf,启动备库生成了backup_label文件backup_label也拷贝到了备库备库启动时,如果发现了有backup_label这个文件,就会从这个文件中记录的点开始恢复,同时备库会把此位置记录到控制文件的"Backupstartlocation"中.
2017Postgres大象会PGConf.
CN2017Thanks!