自定义博客皮肤VIP专享

*博客头图:

格式为PNG、JPG,宽度*高度大于1920*100像素,不超过2MB,主视觉建议放在右侧,请参照线上博客头图

请上传大于1920*100像素的图片!

博客底图:

图片格式为PNG、JPG,不超过1MB,可上下左右平铺至整个背景

栏目图:

图片格式为PNG、JPG,图片宽度*高度为300*38像素,不超过0.5MB

主标题颜色:

RGB颜色,例如:#AFAFAF

Hover:

RGB颜色,例如:#AFAFAF

副标题颜色:

RGB颜色,例如:#AFAFAF

自定义博客皮肤

-+
  • 博客(2413)
  • 论坛 (1)
  • 收藏
  • 关注

原创 数据库PostrageSQL-测试覆盖检查

33.5. 测试覆盖检查PostgreSQL 源代码可以使用覆盖测试指令编译,因此可以检查哪些部分的代码被回归测试或任何其他测试套件所覆盖。当前使用 GCC 编译时支持该特性,并且需要gcov和lcov程序。一个典型的工作流程看起来是:./configure --enable-coverage ... OTHER OPTIONS ...makemake check # 或其他测试套件make coverage-html然后将你的 HTML 浏览器指向coverage/index.html。ma

2021-01-11 21:26:13 22

原创 数据库PostrageSQL-TAP 测试

33.4. TAP 测试很多测试,特别是src/bin下面的客户端程序测试使用 Perl 的 TAP 工具并且用Perl测试程序prove运行。你可以通过 设置make变量PROVE_FLAGS 向prove传递命令行选项,例如:make -C src/bin check PROVE_FLAGS='--timer'详见prove的手册页。make变量PROVE_TESTS可被用来定义一个空格分隔的列表,其中是调用prove来运行的指定测试子集的路径,这些测试子集将取代默认的t/*.pl,并且这些路

2021-01-11 21:22:27 20 1

原创 数据库PostrageSQL-变体比较文件

33.3. 变体比较文件因为某些测试生来就会产生依赖环境的结果,我们提供了方法来指定替代的“预期”结果文件。每一个回归测试可以有多个比较文件来展示在不同平台上的可能结果。有两种独立的机制来决定为每一个测试使用哪个比较文件。第一种机制允许为指定平台选择比较文件。这是一个映射文件src/test/regress/resultmap,它定义了为每一个平台使用哪个比较文件。要为一个特定平台消除虚假的测试“失败”,你可以首先选择或创建一个变体结果文件,然后在resultmap文件中增加一行。在该映射文件中的每一

2021-01-11 21:15:26 17

原创 数据库PostrageSQL-测试评估

33.2. 测试评估一些正确安装的并且全功能的PostgreSQL安装可能会在这些回归测试中的某些上“失败”,其原因是平台相关的因素,例如可变浮点表示和 message wording。这些测试目前采用diff命令来比较测试输出和在参考系统上产生的输出,这样测试的结果对小的系统差异也很敏感。当一个测试被报告为“失败”时,请总是检查实际结果和期望结果之间的差异,你可能会发现该差异其实并不明显。不管怎样,我们将努力维护在所有被支持平台上的准确的参考文件,以期待所有的测试都能通过。回归测试的实际输出在src/

2021-01-11 09:44:06 23

原创 数据库PostrageSQL-回归测试

Chapter 33. 回归测试回归测试是PostgreSQL中对于 SQL 实现的一组综合测试集。它们测试标准 SQL 操作以及PostgreSQL的扩展能力。33.1. 运行测试回归测试可以在一个已经安装并运行的服务器上运行,或者在编译树中的一个临时安装上运行。此外,还有运行该测试的“并行”和“顺序”模式。顺序方法单独运行每一个测试脚本,而并行方法则开启多个服务器进程来并行地运行多组测试。并行测试能够发现进程间通信和锁定是否工作正确。33.1.1. 在一个临时安装上运行测试要在编译之后且在安装

2021-01-11 09:43:44 24

原创 数据库PostrageSQL-可扩展性

32.4. 可扩展性32.4.1. 对扩展的内联支持PostgreSQL的JIT实现可以内联C以及internal类型的函数体,还有基于这类函数的操作符。为了能对扩展中的函数这样做,需要让那些函数的定义可用。在使用PGXS对一个已经编译有LLVM JIT支持的服务器构建一个扩展时,相关的文件将被自动构建并且安装。相关的文件必须被安装在$pkglibdir/bitcode/$extension/中并且对它们的一份概要必须被安装在$pkglibdir/bitcode/$extension.index.b

2021-01-11 09:43:23 14

原创 数据库PostrageSQL-配置

32.3. 配置配置变量jit决定启用或者禁用JIT编译。如果它被启用,配置变量jit_above_cost、jit_inline_above_cost以及jit_optimize_above_cost判断是否要为一个查询执行JIT编译以及在执行中花费多大的努力。jit_provider决定使用哪一种JIT实现。很少需要改变这一设置。见Section 32.4.2。 如Section 19.17中所述,对于开发和调试目的,还有一些额外的配置参数存在。...

2021-01-11 09:43:10 8

原创 数据库PostrageSQL-什么时候会用JIT?

32.2. 什么时候会用JIT?JIT编译主要可以让长时间运行的CPU密集型的查询受益。对于短查询,执行JIT编译增加的开销常常比它节省的时间还要多。为了判断是否应该使用JIT编译,会用到一个查询的总的估计代价(见Chapter 70和Section 19.7.2)。查询的估计代价将与jit_above_cost的设置进行比较。如果代价更高,JIT编译将被执行。然后需要两个进一步的决定。首先,如果估计代价超过jit_inline_above_cost的设置,该查询中使用的短函数和操作符都将被内联。

2021-01-11 09:42:55 10

原创 数据库PostrageSQL-什么是JIT编译?

Chapter 32. 即时编译(JIT)这一章解释什么是即时编译以及如何在PostgreSQL中配置即时编译。32.1. 什么是JIT编译?即时(Just-In-Time,JIT)编译是将某种形式的解释程序计算转变成原生程序的过程,并且这一过程是在运行时完成的。例如,与使用能够计算任意SQL表达式的通用代码来计算一个特定的SQL谓词(如WHERE a.col = 3)不同,可以产生一个专门针对该表达式的函数并且可以由CPU原生执行,从而得到加速。当使用–with-llvm编译PostgreSQL后

2021-01-10 01:27:00 41

原创 数据库PostrageSQL-快速设置

31.9. 快速设置首先在postgresql.conf中设置配置选项:wal_level = logical对于一个基础设置来说,其他所需的设置使用默认值就足够了。需要调整pg_hba.conf以允许复制(这里的值取决于实际的网络配置以及用于连接的用户):host all repuser 0.0.0.0/0 md5然后在发布者数据库上:CREATE PUBLICATION mypub FOR TABLE users, departments;并且在订阅者数据库上:CREATE SUBSCR

2021-01-10 01:24:56 46

原创 数据库PostrageSQL-配置设置

31.8. 配置设置逻辑复制要求设置一些配置选项。在发布者端,wal_level必须被设置为logical,而max_replication_slots中设置的值必须至少是预期要连接的订阅数加上保留给表同步的连接数。max_wal_senders应该至少被设置为max_replication_slots加上同时连接的物理复制体的数量。订阅者还要求max_replication_slots被设置。在这种情况下,它必须至少被设置为将被加入到该订阅者的订阅数。max_logical_replication_

2021-01-10 01:23:05 22

原创 数据库PostrageSQL-安全性

31.7. c用于复制连接的角色必须有REPLICATION属性(或者是一个超级用户)。该角色的访问必须被配置在pg_hba.conf中,并且它必须有LOGIN属性。为了能够拷贝初始表数据,用于复制连接的角色必须在被发布的表上具有SELECT特权(或者是一个超级用户)。要创建publication,用户必须在数据库中有CREATE特权。要把表加入到一个publication,用户必须在该表上有拥有权。要创建一个自动发布所有表的publication,用户必须是一个超级用户。要创建订阅,用户必须是一

2021-01-10 01:20:53 19

原创 数据库PostrageSQL-监控

31.6. 监控因为逻辑复制是基于与物理流复制相似的架构的,一个publication节点上的监控也类似于对物理复制主节点(见Section 26.2.5.2)的监控。有关订阅的监控信息在pg_stat_subscription中可以看到。每一个订阅工作者在这个视图都有一行。一个订阅能有零个或者多个活跃订阅工作者取决于它的状态。通常,对于一个已启用的订阅会有单一的应用进程运行。一个被禁用的订阅或者崩溃的订阅在这个视图中不会有行存在。如果有任何表的数据同步正在进行,对正在被同步的表会有额外的工作者。

2021-01-10 01:19:29 23

原创 数据库PostrageSQL-架构

31.5. 架构逻辑复制从拷贝发布者数据库上的数据库快照开始。拷贝一旦完成,发布者上的更改会在它们发生时实时传送给订阅者。订阅者按照数据在发布者上被提交的顺序应用数据,这样任意单一订阅中的publication的事务一致性才能得到保证。逻辑复制被构建在一种类似于物理流复制(见Section 26.2.5)的架构上。它由“walsender”和“apply”进程实现。walsender进程开始对WAL的逻辑解码(在Chapter 49中描述)并且载入标准逻辑解码插(pgoutput)。该插件把从WAL

2021-01-10 01:12:41 57 3

原创 数据库PostrageSQL-限制

31.4. 限制逻辑复制当前有下列限制或者缺失的功能。这些可能在未来的发行中解决。数据库模式和DDL命令不会被复制。初始模式可以手工使用pg_dump --schema-only进行拷贝。后续的模式改变需要手工保持同步(不过值得注意的是,模式其实不需要在两端保持绝对相同)。当一个活跃的数据库中模式定义改变时,逻辑复制是鲁棒的:当模式在发布者上发生改变并且被复制的数据开始到达订阅者但却不适合表模式时,复制将报错,直至模式被更新。在很多情况下,可以通过先对订阅者应用额外的模式更改来避免间歇性的错误。序列

2021-01-10 01:10:24 17

原创 数据库PostrageSQL-冲突

31.3. 冲突逻辑复制的行为类似于正常的DML操作,即便数据在订阅者节点本地被修改,逻辑复制也会根据收到的更改来更新数据。如果流入的数据违背了任何约束,复制将停止。这种情况被称为一个冲突。在复制UPDATE或DELETE操作时,缺失的数据将不会产生冲突并且这类操作将被简单地跳过。冲突将会产生错误并且停止复制,它必须由用户手工解决。在订阅者的服务器日志中可以找到有关冲突的详细情况。通过更改订阅者上的数据(这样它就不会与到来的数据发生冲突)或者跳过与已有数据冲突的事务可以解决这种冲突。通过调用pg_re

2021-01-10 01:08:21 25 1

原创 数据库PostrageSQL-订阅

31.2. 订阅订阅是逻辑复制的下游端。订阅被定义在其中的节点被称为订阅者。一个订阅会定义到另一个数据库的连接以及它想要订阅的publication集合(一个或者多个)。订阅者数据库的行为与任何其他PostgreSQL实例相同,并且可以被用作其他数据库的发布者,只需要定义它自己的publication。如果需要,一个订阅者节点可以有多个订阅。可以在一对发布者-订阅者之间定义多个订阅,在这种情况下要确保被订阅的publication对象不会重叠。每一个订阅都将通过一个复制槽(见Section 26.

2021-01-10 01:06:45 18

原创 数据库PostrageSQL-逻辑复制

Chapter 31. 逻辑复制逻辑复制是一种基于数据对象的复制标识(通常是主键)复制数据对象及其更改的方法。我们使用术语“逻辑”来与物理复制加以区分,后者使用准确的块地址以及逐字节的复制方式。PostgreSQL两种机制都支持,请见Chapter 26。逻辑复制允许在数据复制和安全性上更细粒度的控制。逻辑复制使用一种发布和订阅模型,其中有一个或者更多订阅者订阅一个发布者节点上的一个或者更多publication 。订阅者从它们所订阅的publication拉取数据并且可能后续重新发布这些数据以允许级

2021-01-10 01:03:09 35 4

原创 数据库PostrageSQL-WAL内部

30.5. WAL内部WAL是自动被启用的。除了确保满足WAL日志存放所需要的磁盘空间以及一些必要的调优外(参阅Section 30.4),管理员无需执行任何操作。当每个新记录被写入时,WAL记录被追加到WAL日志中。 插入位置由日志序列号(LSN)描述,该日志序列号是日志中的字节偏移量, 随每个新记录单调递增。LSN值作为数据类型pg_lsn返回。 值可以进行比较以计算分离它们的WAL数据量,因此它们用于衡量复制和恢复的进度。WAL日志被存放在数据目录的pg_wal目录里,它是作为一个文件段的集合存

2021-01-08 21:02:49 31

原创 数据库PostrageSQL-WAL配置

30.4. WAL配置有几个WAL相关的配置参数会影响数据库性能。本节将解释它们的使用。关于服务器配置参数的设置的一般信息请参考Chapter 19。检查点是在事务序列中的点,这种点保证被更新的堆和索引数据文件的所有信息在该检查点之前已被写入。在检查点时刻,所有脏数据页被刷写到磁盘,并且一个特殊的检查点记录将被写入到日志文件(修改记录之前已经被刷写到WAL文件)。在崩溃时,崩溃恢复过程检查最新的检查点记录用来决定从日志中的哪一点(称为重做记录)开始REDO操作。在这一点之前对数据文件所做的任何修改都已经

2021-01-08 20:58:59 21

原创 数据库PostrageSQL-异步提交

30.3. 异步提交异步提交是一个允许事务能更快完成的选项,代价是在数据库崩溃时最近的事务会丢失。在很多应用中这是一个可接受的交换。如前一节所述,事务提交通常是同步的:服务器等到事务的WAL记录被刷写到持久存储之后才向客户端返回成功指示。因此客户端可以确保那些报告已被提交的事务确会被保存,即便随后马上发生了一次服务器崩溃。但是,对于短事务来说这种延迟是其总执行时间的主要部分。选择异步提交模式意味着服务器将在事务被逻辑上提交后立刻返回成功,而此时由它生成的WAL记录还没有被真正地写到磁盘上。这将为小型事务

2021-01-08 20:50:45 18

原创 数据库PostrageSQL-预写式日志(WAL)

30.2. 预写式日志(WAL)预写式日志(WAL)是保证数据完整性的一种标准方法。对其详尽的描述几乎可以在所有(如果不是全部)有关事务处理的书中找到。简单来说,WAL的中心概念是数据文件(存储着表和索引)的修改必须在这些动作被日志记录之后才被写入,即在描述这些改变的日志记录被刷到持久存储以后。如果我们遵循这种过程,我们不需要在每个事务提交时刷写数据页面到磁盘,因为我们知道在发生崩溃时可以使用日志来恢复数据库:任何还没有被应用到数据页面的改变可以根据其日志记录重做(这是前滚恢复,也被称为REDO)。因

2021-01-08 20:47:58 15

原创 数据库PostrageSQL-可靠性和预写式日志

Chapter 30. 可靠性和预写式日志本章解释预写式日志如何用于获得有效的、可靠的操作。30.1. 可靠性可靠性是任何严肃的数据库系统的重要属性,PostgreSQL尽一切可能来保证可靠的操作。可靠的操作的一个方面是,被一个提交事务记录的所有数据应该被存储在一个非易失的区域,这样就不会因为失去电力、操作系统失败以及硬件失败(当然,除了非易失区域自身失效之外)等原因导致的数据丢失。 向计算机的永久存储(磁盘驱动器或者等效的设备)成功写入数据通常可以满足这个要求。 实际上,即使计算机受到致命损坏,只要

2021-01-08 20:46:14 12

原创 数据库PostrageSQL-磁盘满失败

29.2. 磁盘满失败一个数据库管理员最重要的磁盘监控任务就是确保磁盘不会写满。一个写满了的数据磁盘可能不会导致数据的崩溃,但它肯定会让系统变得不可用。如果保存 WAL 文件的磁盘变满,会发生数据库服务器致命错误并且可能发生关闭。如果你不能通过删除一些其他的东西来释放一些磁盘空间,那么你可以通过使用表空间把一些数据库文件移动到其他文件系统上去。参阅Section 22.6获取更多信息。有些文件系统在快满的时候性能会急剧恶化,因此不要等到磁盘完全满的时候才采取行动。如果你的系统支持每用户的磁盘份额

2021-01-08 11:35:09 17

原创 数据库PostrageSQL-判断磁盘用量

Chapter 29. 监控磁盘使用本章讨论如何监控PostgreSQL数据库系统的磁盘使用情况。29.1. 判断磁盘用量每个表都有一个主要的堆磁盘文件,大多数数据都存储在其中。如果一个表有着可能会很宽(尺寸大)的列, 则另外还有一个TOAST文件与这个表相关联, 它用于存储因为太宽而不能存储在主表里面的值(参阅Section 68.2)。如果有这个附属文件,那么TOAST表上会有一个可用的索引。 当然,同时还可能有索引和基表关联。每个表和索引都存放在单独的磁盘文件里 — 如果文件超过 1G 字节,

2021-01-08 11:33:49 17

原创 数据库PostrageSQL-动态追踪

28.5. 动态追踪PostgreSQL提供了功能来支持数据库服务器的动态追踪。这样就允许在代码中的特 定点上调用外部工具来追踪执行过程。一些探针或追踪点已经被插入在源代码中。这些探针的目的是被数据库开发者和管理员使用。默认情况下,探针不被编译到PostgreSQL中;用户需要显式地告诉配置脚本使得探针可用。目前,在写本文当时DTrace1已被支持,它在 Solaris、macOS、FreeBSD、NetBSD 和 Oracle Linux 上可用。Linux 的SystemTap2项目提供了一种可用

2020-12-31 17:55:16 46 2

原创 数据库PostrageSQL-进度报告

28.4. 进度报告PostgreSQL有能力在命令执行期间报告特定命令的进度。当前,唯一一种支持进度报告的命令是VACUUM。这在未来可能会被扩充。28.4.1. VACUUM进度报告只要VACUUM正在运行,每一个当前正在清理的后端(包括autovacuum工作者进程)在pg_stat_progress_vacuum视图中都会有一行。下面的表描述了将被报告的信息并且提供了如何解释它们的信息。进度报告当前不支持VACUUM FULL,运行着VACUUM FULL的后端将不会在这个视图中列出。Tab

2020-12-28 21:01:33 22

原创 数据库PostrageSQL-查看锁

28.3. 查看锁监控数据库活动的另外一个有用的工具是pg_locks系统表。这样就允许数据库管理员查看在锁管理器里面未解决的锁的信息。例如,这个功能可以被用于:查看当前所有未解决的锁、在一个特定数据库中的关系上所有的锁、在一个特定关系上所有的锁,或者由一个特定PostgreSQL会话持有的所有的锁。判断当前数据库中带有最多未授予锁的关系(它很可能是数据库客户端的竞争源)。判断锁竞争给数据库总体性能带来的影响,以及锁竞争随着整个数据库流量的变化范围。pg_locks视图的细节在Section 5

2020-12-28 20:57:52 28

原创 数据库PostrageSQL-统计收集器

28.2. 统计收集器PostgreSQL的统计收集器是一个支持收集和报告服务器活动信息的子系统。 目前,这个收集器可以对表和索引的访问计数,计数可以按磁盘块和个体行来进行。它还跟踪每个表中的总行数、每个表的清理和分析动作的信息。它也统计调用用户定义函数的次数以及在每次调用中花费的总时间。PostgreSQL也支持报告有关系统正在干什么的 动态信息,例如当前正在被其他服务器进程执行的命令以及系统中存在哪些其他连接。 这个功能是独立于收集器进程存在的。28.2.1. 统计收集配置因为统计收集给查询执行

2020-12-28 20:56:25 29

原创 数据库PostrageSQL-监控数据库活动

Chapter 28. 监控数据库活动一个数据库管理员常常会疑惑,“系统现在正在做什么?”这一章会讨论如何搞清楚这个问题。一些工具可以用来监控数据库活动并且分析性能。这一章的大部分都致力于描述PostgreSQL的统计收集器,但是我们也不能忽视常规的 Unix 监控程序,如ps、top、iostat和vmstat。另外,一旦我们发现了一个性能差的查询,可能需要PostgreSQL的EXPLAIN命令来进行进一步的调查。Section 14.1会讨论EXPLAIN以及其他用来理解个体查询行为的方法。2

2020-12-28 20:25:50 12

原创 数据库PostrageSQL-后备服务器设置

27.3. 后备服务器设置standby_mode (boolean)指定是否将PostgreSQL服务器作为一个后备服务器启动。如果这个参数为on,当到达已归档 WAL 末尾时该服务器将不会停止恢复,但是将通过使用restore_command获得新的WAL 段以及/或者通过使用primary_conninfo设置连接到主服务器来尝试继续恢复。primary_conninfo (string)指定后备服务器用来连接主服务器的连接字符串。这个字符串的格式在Section 34.1.1中描述。如果在

2020-12-28 20:20:23 26

原创 数据库PostrageSQL-恢复目标设置

27.2. 恢复目标设置默认情况下,恢复将会一直恢复到 WAL 日志的末尾。下面的参数可以被用来指定一个更早的停止点。在recovery_target、recovery_target_lsn、recovery_target_name、recovery_target_time recovery_target_xid中,最多只能使用一个,如果在配置文件中使用了多个,将使用最后一个。recovery_target = 'immediate’这个参数指定恢复应该在达到一个一致状态后尽快结束,即尽早结束。在

2020-12-24 21:18:55 21

原创 数据库PostrageSQL-恢复配置

Chapter 27. 恢复配置这一章描述recovery.conf文件中可用的设置。它们只应用于恢复期。对于你希望执行的任意后续恢复,它们必须被重置。一旦恢复已经开始,它们就不能被更改。recovery.conf中的设置以name = 'value'形式指定。每一行指定一个参数。井号(#)表示行的剩余部分是一段注释。要在一个参数值中嵌入一个单引号,将其双写(’’)。作为一个例子文件,share/recovery.conf.sample被放置在安装的share/目录中。27.1. 归档恢复设置res

2020-12-24 21:14:46 20

原创 数据库PostrageSQL-热备

26.5. 热备术语热备用来描述处于归档恢复或后备模式中的服务器连接到服务器并运行只读查询的能力。这有助于复制目的以及以高精度恢复一个备份到一个期望的状态。术语热备也指服务器从恢复转移到正常操作而用户能继续运行查询并且保持其连接打开的能力。在热备模式中运行查询与正常查询操作相似,尽管如下所述存在一些用法和管理上的区别。26.5.1. 用户概览当hot_standby参数在一台后备服务器上被设置为真时,一旦恢复将系统带到一个一致的状态它将开始接受连接。所有这些连接都被限制为只读,甚至临时表都不能被写入。

2020-12-24 21:10:47 33

原创 数据库PostrageSQL-故障转移

26.3. 故障转移如果主服务器失效,则后备服务器应该开始故障转移过程。如果后备服务器失效,则不会有故障转移发生。如果后备服务器可以被重启(即使晚一点),由于可重启恢复的优势,那么恢复处理也能被立即重启。如果后备服务器不能被重启,则一个全新的后备服务器实例应该被创建。如果主服务器失效并且后备服务器成为了新的主服务器,那么接下来旧的主服务器重启后,你必须有一种机制来通知旧的主服务器不再成为主服务器。有些时候这被称为STONITH(Shoot The Other Node In The Head,关闭其他节

2020-12-23 21:04:14 23

原创 数据库PostrageSQL-日志传送的替代方法

26.4. 日志传送的替代方法前一节描述的内建后备模式的一种替代方案是使用一个轮询归档位置的restore_command。这是版本 8.4 及以下版本中唯一可用的选项。在这种设置中,设置standby_mode为关闭,因为你要自行实现后备操作所需的轮询。关于这种实现的一个参考请见pg_standby模块。注意在这种模式中,服务器将一次应用一整个文件的 WAL,因此如果你使用后备服务器来查询(见热备),那么主服务器上的一个动作和后备服务器上该动作变得可见之间会有一个延迟,该延迟对应着填满 WAL 文件的时

2020-12-23 21:03:33 17

原创 数据库PostrageSQL-日志传送后备服务器

26.2. 日志传送后备服务器连续归档可以被用来创建一个高可用性(HA)集群配置,其中有一个或多个后备服务器随时准备在主服务器失效时接管操作。这种能力被广泛地称为温备或日志传送。主服务器和后备服务器一起工作来提供这种能力,但这些服务器只是松散地组织在一起。主服务器在连续归档模式下操作,而每一个后备服务器在连续恢复模式下操作并且持续从主服务器读取 WAL 文件。要启用这种能力不需要对数据库表做任何改动,因此它相对于其他复制方案降低了管理开销。这种配置对主服务器的性能影响也相对较低。直接从一个数据库服务器

2020-12-22 22:49:33 29

原创 数据库PostrageSQL-高可用、负载均衡和复制

Chapter 26. 高可用、负载均衡和复制数据库服务器可以一起工作,这样如果主要的服务器失效则允许一个第二服务器快速接手它的任务(高可用性),或者可以允许多个计算机提供相同的数据(负载均衡)。理想情况下,数据库服务器能够无缝地一起工作。提供静态网页服务的网页服务器可以非常容易地通过把网页请求均衡到多个机器来组合。事实上,只读的数据库服务器也可以相对容易地组合起来。不幸的是,大部分数据库服务器收到的请求是读/写混合的,并且读/写服务器更难于组合。这是因为尽管只读数据只需要在每台服务器上放置一次,但对于任

2020-12-22 22:27:51 23

原创 数据库PostrageSQL-连续归档和时间点恢复(PITR)

25.3. 连续归档和时间点恢复(PITR)在任何时间,PostgreSQL在数据集簇目录的pg_wal/子目录下都保持有一个预写式日志(WAL)。这个日志存在的目的是为了保证崩溃后的安全:如果系统崩溃,可以“重放”从最后一次检查点以来的日志项来恢复数据库的一致性。该日志的存在也使得第三种备份数据库的策略变得可能:我们可以把一个文件系统级别的备份和WAL文件的备份结合起来。当需要恢复时,我们先恢复文件系统备份,然后从备份的WAL文件中重放来把系统带到一个当前状态。这种方法比之前的方法管理起来要更复杂,但是

2020-12-18 23:06:12 32 1

原创 数据库PostrageSQL-文件系统级别备份

25.2. 文件系统级别备份另外一种备份策略是直接复制PostgreSQL用于存储数据库中数据的文件,Section 18.2解释了这些文件的位置。你可以采用任何你喜欢的方式进行文件系统备份,例如:tar -cf backup.tar /usr/local/pgsql/data但是这种方法有两个限制,使得这种方法不实用,或者说至少比pg_dump方法差:为了得到一个可用的备份,数据库服务器必须被关闭。例如阻止所有连接的半路措施是不起作用的(部分原因是tar和类似工具无法得到文件系统状态的一个原

2020-12-18 22:42:21 22 1

空空如也

cwl_java的留言板

发表于 2020-01-02 最后回复 2020-05-17

空空如也

TA创建的收藏夹 TA关注的收藏夹

TA关注的人 TA的粉丝

提示
确定要删除当前文章?
取消 删除