主页 / dba / 问题 / 114357
Accepted
francs
Asked: 2015-09-08 05:04:40 +0800 CST

pg_stat_replication 视图的 write_location 和 flush_location

  • 772

我对 pg_stat_replication view 的write_location和flush_location感到困惑。文档说， write_location 代表最后一个事务日志位置被这个备用服务器写入磁盘， flush_location 代表最后一个事务日志位置被这个备用服务器刷新到磁盘，有什么区别吗？

在主数据库上查询 pg_stat_replication 视图

sent_location :      Last transaction log position sent on this connection
write_location:      Last transaction log position written to disk by this standby server
flush_location:      Last transaction log position flushed to disk by this standby server
replay_location:     Last transaction log position replayed into the database on this standby server

postgres=# select * from pg_stat_replication ;
-[ RECORD 1 ]----+------------------------------
pid              | 23453
usesysid         | 24619
usename          | repuser
application_name | node1
client_addr      | 192.168.2.37
client_hostname  | 
client_port      | 58412
backend_start    | 2015-09-07 20:56:13.141438+08
backend_xmin     | 
state            | streaming
sent_location    | 2/3D397B1C
write_location   | 2/3D397B1C
flush_location   | 2/3D397B1C
replay_location  | 2/3D390954
sync_priority    | 1
sync_state       | sync
postgresql

1 个回答

  1. Best Answer

    pg_stat_replication 中的两列基本上是指出write(2)和之间的区别fsync(2)

    从write(2)联机帮助页：

    write() 从缓冲区指向的 buf 向文件描述符 fd 引用的文件写入 count 个字节。

    例如，如果底层物理介质上没有足够的空间，或者遇到 RLIMIT_FSIZE 资源限制（请参阅 setrlimit(2)），或者调用在之后被信号处理程序中断，则写入的字节数可能少于计数写入的字节数少于 count 个字节。（另请参见管道 (7)。）

    对于可查找文件（即可以应用 lseek(2) 的文件，例如常规文件），写入发生在当前文件偏移量处，文件偏移量按实际写入的字节数递增。如果文件是使用 O_APPEND 打开（2）的，则文件偏移量在写入之前首先设置为文件末尾。文件偏移量的调整和写入操作作为一个原子步骤执行。

    POSIX 要求可以证明在 write() 返回后发生的 read(2) 返回新数据。请注意，并非所有文件系统都符合 POSIX。

    从fsync(2)手册页：

    fsync() 将文件描述符 fd 引用的文件的所有已修改内核数据（即已修改缓冲区高速缓存页面）传输（“刷新”）到该文件所在的磁盘设备（或其他永久存储设备）。调用会阻塞，直到设备报告传输已完成。它还刷新与文件关联的元数据信息（请参阅 stat(2)）。

    调用 fsync() 不一定确保包含该文件的目录中的条目也已到达磁盘。为此，还需要目录的文件描述符上的显式 fsync()。

    fdatasync() 类似于 fsync()，但不会刷新已修改的元数据，除非需要该元数据以便正确处理后续数据检索。例如，对 st_atime 或 st_mtime 的更改（分别是上次访问时间和上次修改时间；请参阅 stat(2)）不需要刷新，因为它们对于正确处理后续数据读取不是必需的。另一方面，更改文件大小（st_size，例如 ftruncate(2) 所做的）将需要刷新元数据。

    fdatasync() 的目的是减少不需要所有元数据与磁盘同步的应用程序的磁盘活动。

    默认情况下，在正常操作下，PostgreSQL 会调用 fsync（或 fdatasync，如果你在 linux 上），以确保 WAL 段中的数据正确且真实地写入磁盘。

    在正常操作中，当发生写入调用时，它基本上是将该数据从 PostgreSQL 复制到文件系统缓存，这只是另一位 RAM。如果服务器崩溃，那么您仍然会丢失该数据，因为它仍在 RAM 中，即使它只是 RAM 的不同部分。

    但是，在 上COMMIT，PostgreSQL 调用fsync，它强制将 WAL 段数据写出到磁盘，而不仅仅是写入 RAM 中的文件系统缓存。这确保在崩溃后，提交的数据仍然提交，并且可以重放。

    它还具有需要fsync为数据文件调用更少次数的额外优势，因为正确重播对这些文件的更改所需的所有数据都包含在 WAL 段中，这些段持久保存在磁盘中。

    可以在文章Flushing Disk Buffers中找到对 Linux 下此行为的一个很好的描述。

    可以使用wal_sync_method和fsync控制同步行为

    希望这有助于回答您的问题。=)

    • 1

相关问题