本系列为 CMU 15-445 Fall 2022 Database Systems 数据库系统 [卡内基梅隆] 课程重点知识点摘录。
lock_timeout 锁等待超时。语句在试图获取表、索引、行或其他数据库对象上的锁时等到超过指定的毫秒数,该语句将被中止。 不推荐在postgresql.conf中设置,因为会影响所有的会话。
串行化的隔离级别和高性能就是相互矛盾的吗?也许不是,一个称为可串行化快照隔离(SSI, serializable snapshot isolation)算法很有前途。提供完整的可串行化保证,而性能与快照隔离相比只有很小性能损失。 SSI在 2008 年首次被提出,如今既用于单节点DB(PostgreSQL9.1后的可串行化)和分布式DB(FoundationDB)。由于 SSI 与其他并发控制机制相比还很年轻,还在实践中证明自己。
表面看,RC已满足事务所需的一切特征:支持中止(原子性),防止读取不完整的事务结果,并防止并发写的混乱。这点很关键!为我们的开发省去一大堆麻烦。
墨墨导读:最近电子工业出版社博文视点出版了《PostgreSQL指南:内幕探索》,日前「数据和云」公众号推荐了这本书并赠送了五本,百多位用户参与,几十条留言未能放出,为了让大家更好地学习开源数据PostgreSQL,经出版社官方授权,刊载本书部分章节内容以飨读者,本文节选了第十章《基本备份与时间点恢复》10.1-10.2。
并发 BUG 很难通过测试找到,因为这样的错误只有在特殊时序下才会触发。这样的时序问题可能非常少发生,通常很难重现 1。并发性也很难推理,特别是在大型应用中,你不一定知道哪些其他代码正在访问DB。只有一个用户访问数据时,应用开发就够麻烦了,多用户并发更困难,每个数据都可能被多个用户修改。
任何数据库都有死锁,MYSQL的死锁有相关的工具,或者去日志查找,postgresql的死锁又怎么搞,今天的来说说。
在我们之前的文章中,我们讨论了多模式索引[1]的设计,这是一种用于Lakehouse架构的无服务器和高性能索引子系统,以提高查询和写入性能。在这篇博客中,我们讨论了构建如此强大的索引所需的机制,异步索引机制的设计,类似于 PostgreSQL[2] 和 MySQL[3] 等流行的数据库系统,它支持索引构建而不会阻塞写入。
PostgreSQL中的时间线用于区分原始数据库集簇和恢复生成的数据库集簇,它是PITR的核心概念。此文描述了与时间线相关的两件事,分别是时间线标识和时间线历史文件。
原文:http://www.enmotech.com/web/detail/1/733/1.html (上)
并行计划没有什么特殊的地方,并行逻辑基本都在ExecGather函数中实现的:
作者介绍:林锦,腾讯云数据库团队高级工程师,曾任云计算初创公司系统架构师,从事分布式系统研发7年,2017年加入腾讯云,从事NewSQL研发工作,目前主要负责CynosDB for PostgreSQL开发工作。
Galera Cluster是MariaDB的一个双活多主集群,其可以使得MariDB的所有节点保持同步,Galera为MariaDB提供了同步复制(相对于原生的异步复制),因此其可以保证HA,且其当前仅支持XtraDB/InnoDB存储引擎(扩展支持MyISAM),并且只可在Linux下使用。 从MariaDB 10.1开始,在Galera Cluster中默认已经包含了wsrep API。在MariaDB 10.0和MariaDB 5.5时还是独立的,所以在安装部署上可能会有所不同,具体看MariaDB官方介绍。
PG流复制场景下,默认配置下, 如果在PG从库执行长时间的查询,会出现查询的报错。提示
如果两个事务操作的是不同的数据, 即不存在数据依赖关系, 则它们可以安全地并行执行。但是当出现某个事务修改数据而另一个事务同时要读取该数据, 或者两个事务同时修改相同数据时, 就会出现并发问题。
Postgres-XL 是一款Postgres-XC升级的产品, 如果说PGXC是在PG添加了集群的功能主打OLTP的功能为卖点, PGXL 是一款基于PGXC添加了OLAP功能的支持MPP架构的, 但不是简单的POSTGRESQL 单机的功能的堆叠,本身基于的是PG早期的9.5 ,目前最新的版本是Postgres-XL 10R1.1 的版本。
为实现高可靠,系统必须处理这些问题。但完善容错机制工作量巨大,要仔细考虑所有可能出错的事情,并充分测试。
下面的参数目的是用在PostgreSQL源代码上, 并且在某些情况下可以帮助恢复严重损坏了的数据库。在一个生产数据库中没有理由使用它们。同样,它们被从例子postgresql.conf文件中排除。请注意许多这些参数要求特殊的源代码编译标志才能工作。
用户命令触发状态机函数导致事务状态流转,流转时按对应状态调用底层事务处理函数干活。
如果打开这个参数,PostgreSQL服务器将尝试确保更新被物理地写入到磁盘,做法是发出fsync()系统调用或者使用多种等价的方法(见wal_sync_method)。
client_min_messages (enum) 控制被发送给客户端的消息级别。有效值是DEBUG5、 DEBUG4、DEBUG3、DEBUG2、 DEBUG1、LOG、NOTICE、 WARNING、ERROR。 每个级别都包括其后的所有级别。级别越靠后,被发送的消息越少。默认值是NOTICE。 注意LOG在这里有与log_min_messages中不同的排名。 INFO 级别的消息总是被发送到客户端。
企业IT系统迁移到公有云上已然是正在发生的趋势。数据库服务,作为公有云上提供的关键组件,是企业客户是否愿意将自己运行多年的系统搬到云上的关键考量之一。另一方面,自从System R开始,关系数据库系统已经大约四十年的历史了。尤其是随着互联网的发展,业务对数据库实例的吞吐量要求越来越高。对于很多业务来说,单个物理机器所能提供的最大吞吐量已经不能满足业务的高速发展。因此,数据库集群是很多IT系统绕不过去的坎。
RC和快照隔离级别主要都是为解决 只读事务遇到并发写时可以看到什么(虽然中间也涉及脏写),还没触及另一种情况:两个写事务并发,而脏写只是写并发的特例。
https://www.citusdata.com/blog/2022/03/26/test-drive-citus-11-beta-for-postgres/
一般实现数据库的并发会采用三种方式,分别是多版本并发控制(MVCC),严格两阶段锁(S2PL),乐观并发控制(OCC).在MVCC中,每个更新操作都会创建新的一个数据版本,并保留旧版本。当事务读取数据对象时候,系统会根据一定的策略选择一个数据版本读取,这样读写都不会互相干扰。基于S2PL的数据库系统在写操作发生时会阻塞相应对象上的读操作,因为写入者获得了操作对象的互斥锁。PostgreSQL采用了基于MVCC的变体,叫做快照隔离级别(SI) 目前Oracle数据使用undo来实现快照隔离级别。当新数据写入
Fujitsu OSS团队和PostgreSQL开源社区合作在PG14中添加了在逻辑复制中对两阶段提交进行解密的功能。下面看看这项功能是什么?
exit_on_error (boolean) 如果为真,任何错误将中止当前会话。默认情况下,这个值被设置为假,这样只有 FATAL 错误(致命)将中止会话。
分布式事务,尤其是使用两阶段提交实现的分布式事务,毁誉参半。一方面,他们可以提供其他方式难以实现的安全保证;另一方面,由于运维复杂、降低性能、承诺过多,他们广受诟病。为了避免分布式事务带来的运维复杂度,很多云服务选择不支持分布式事务。
随着计算机和信息技术的迅猛发展,行业应用系统的规模迅速扩大,行业应用所产生的数据量呈爆炸式增长,动辄达到数百TB甚至数百PB的规模,已远远超出传统计算技术和信息系统的处理能力,集中式数据库面对大规模数据处理逐渐表现出其局限性。因此,人们希望寻找一种能快速处理数据和及时响应用户访问的方法,也希望对数据进行集中分析、管理和维护。这已经成为迫切需求。
综上所述,为了保证XA事务的一致性和可靠性,需要使用XA协议进行分布式事务的管理,使用分布式事务日志记录事务操作,设计幂等性操作,借助数据库的分布式事务支持,以及使用分布式锁和分布式一致性算法来确保分布式系统的数据一致和可靠性。
日常中我们进行安装PostgreSQL后都需要对其进行配置基础配置,以便其能有效发挥出服务器的性能,下面是我进行整理后的postgresql.conf配置文件的相关注释,方便大家对于各个属性进行熟悉。
在管理数据库时,性能是一项非常重要而又复杂的任务。它可能会受到系统的配置、硬件甚至设计的影响。有趣的是,PostgreSQL和MySQL都配置了兼容性和稳定性,这取决于我们的数据库设计的硬件基础架构。
这些设置控制内建流复制特性(见Section 26.2.5)的行为。服务器将可以是主控服务器或后备服务器。主控机能发送数据,而后备机总是被复制数据的接收者。当使用级联复制(见Section 26.2.7)时,后备服务器也可以是发送者,同时也是接收者。这些参数主要用于发送服务器和后备服务器,尽管某些只在主服务器上有意义。如果有必要,设置可以在集群中变化而不出问题。
在 Arctype 社区里,我们回答了很多关于数据库性能的问题,尤其是 Postgres 和 MySQL 这两个之间的性能问题。在管理数据库中,性能是一项至关重要而又复杂的任务。它可能受到配置、硬件、或者是操作系统的影响。PostgreSQL 和 MySQL 是否具有稳定性和兼容性取决于我们的硬件基础架构。
首先逻辑复制早期在 PG 10 之前是通过插件的方式来实现其功能的,在PG10合并进数据库系统中。
MariaDB Galera Cluster(下文简称 MGC 集群),是一套在 MySQL innodb 存储引擎上面实现多主、数据实时同步以及强一致性的关系存储架构,业务层面无需做读写分离工作,数据库读写压力都能按照既定的规则分发到 各个节点上去,在数据方面完全兼容 MariaDB 和 MySQL。
(这篇是PG视角看GTM、后面在总结一篇GTM内部逻辑) (前面是一些概念,后面是GDB走读)
(第一篇PG视角、下一篇GTM视角) (前面是乱七八糟的一些概念,最后一部分是GDB走读)
数据库服务器可以一起工作,这样如果主要的服务器失效则允许一个第二服务器快速接手它的任务(高可用性),或者可以允许多个计算机提供相同的数据(负载均衡)。理想情况下,数据库服务器能够无缝地一起工作。提供静态网页服务的网页服务器可以非常容易地通过把网页请求均衡到多个机器来组合。事实上,只读的数据库服务器也可以相对容易地组合起来。不幸的是,大部分数据库服务器收到的请求是读/写混合的,并且读/写服务器更难于组合。这是因为尽管只读数据只需要在每台服务器上放置一次,但对于任意服务器的一次写动作却必须被传播给所有的服务器,这样才能保证未来对于那些服务器的读请求能返回一致的结果。
问题的起因是,在做repmgr 恢复的时候,经常有同学说恢复的时候, repmgr rejion node 的时候pg_rewind 会报错,与时间线有关。(pg_rewind之前是写过的清参阅之前的文字)
MongoDB以下内容列出了运行事务的一些生产注意事项。无论是在副本集还是分片集群上运行事务,这些都适用。要在分片集群上运行事务,另请参阅生产注意事项(分片集群)来了解专门针对分片集群的额外注意事项。
本文介绍了 PostgreSQL 9.6 在 OLTP 场景下的性能提升,包括大表 join、大索引扫描、排序、聚合、多版本并发控制、无锁架构、wal写入优化等。通过测试和对比,表明 PostgreSQL 9.6 在 TPC-C 和 TPC-H 场景下性能都有了显著提升,甚至可以满足大部分 OLTP 业务需求。
您可能已经在数据库的文档中看到了隔离级别,感到有些手足无措。很少有日常使用事务的例子真正提到了隔离。大多数使用数据库的默认隔离级别,并希望获得最好的隔离级别。这是一个需要理解的基本话题,如果你花点时间来研究这个指南,你会对SQL事务隔离有深入的认识。 基本的定义 为了正确地理解SQL隔离级别,我们首先应该考虑事务本身。交易的概念来自合同法:法律交易必须是原子的(要么所有的条款都适用,要么没有),一致的(遵守法律协议),并且是持久的(在承诺之后,各方不能收回他们的承诺)。这些属性是数据库管理系统中流行的“AC
CitusDB 是基于 PostgreSQL 扩展(类似 PHP 扩展)实现的 PostgreSQL 集群。
openGauss是关系型数据库,采用客户端/服务器,单进程多线程架构;支持单机和一主多备部署方式,同时支持备机可读、双机高可用等特性。
在分布式计算领域,共识问题是最重要而基础的问题。从表面上看含义很直接:可以粗略的理解为多个节点就某件事达成共识。乍看起来,你会觉得,这有什么难的?但不幸的是,很多系统都因为低估了共识算法的实现难度而问题百出。
最近,当开发人员David Glasser了解MongoDB默认执行脏读的糟糕方式时,MongoDB再次成为Reddit的佼佼者。在本文中,我们将解释什么是隔离级别和脏读以及如何在流行的数据库中实现它们。
领取专属 10元无门槛券
手把手带您无忧上云