eygle.com   eygle.com
eygle.com eygle
eygle.com  
 

March 14, 2022

MacOS 使用终端连接 MySQL 查询乱码的问题解决

最近在使用 MacOS 访问 MySQL 数据库时,查询总是出现乱码,数据库和表的字符集、终端设置都是 UTF8.

最后发现是 MacOS Terminal 的环境变量设置问题:

编辑配置文件

vim ~/.bash_profile

添加一样内容:

export LC_ALL=zh_CN.UTF-8

执行命令,使其生效:

source ~/.bash_profile

即可解决客户端的 Terminal 终端设置导致的乱码问题。

Posted by eygle at 2:46 PM | Permalink | Beginner (55)

December 7, 2021

openGauss 概述

本文来源于墨天轮:https://www.modb.pro/db/190317 openGauss数据库是华为公司在深度融合技术应用于数据库领域多年经验的基础上,结合企业级场景要求,推出的新一代企业级开源数据库。

openGauss是关系型数据库(relational database),采用客户端/服务器,单进程多线程架构;支持单机和一主多备部署方式,同时支持备机可读、双机高可用等特性。

openGauss有如下基本功能 :

(1) 支持标准SQL。

openGauss数据库支持标准的SQL(structured query language,结构化查询语言)。SQL标准是一个国际性的标准,会定期更新和演进。SQL标准的定义分为核心特性以及可选特性,绝大部分的数据库都没有100%支撑SQL标准。openGauss数据库支持SQL92/SQL99/SQL2003等,同时支持SQL2011大部分核心特性以及部分可选特性。

(2) 支持标准开发接口。

openGauss数据库提供业界标准的ODBC(open database connectivity,开放式数据库连接)及JDBC(java database connectivity,java数据库连接)接口,保证用户能将业务快速迁移至openGauss。目前支持标准的ODBC3.5及JDBC4.0接口,其中ODBC能够支持CentOS、openEuler、SUSE、Win32、Win64等平台,JDBC无平台差异。

(3) 支持混合存储引擎。

openGauss数据库支持行存储引擎、列存储引擎和内存存储引擎等。行存储分为inplace update和append update两种模式,前者通过单独的回滚段(undo log)来保留元组的前像以解决读写冲突,可以更自然地支持数据更新;后者将更新记录混杂在数据记录中,通过新旧版本的形式来支持数据更新,对于旧版本需要定期做vacuum操作来支持磁盘空间的回收。列存储支持数据快速分析,更适合OLAP(online analytical processing,联机分析处理)业务。内存引擎支持实时数据处理,对有极致性能要求的业务提供支撑。

(4) 支持事务。

事务支持指的是系统提供事务的能力,openGauss支持事务的原子性、一致性、隔离性和持久性。事务支持及数据一致性保证是绝大多数数据库的基本功能,只有支持了事务,才能满足事务化的应用需求。

  • A(atomicity): 原子性。整个事务中的所有操作,要么全部完成,要么全部不完成,不可能停滞在中间某个环节。

  • C(consistency): 一致性。事务需要保证从一个执行性状态转移到另一个一致性状态,不能违反数据库的一致性约束。

  • I(isolation): 隔离性。隔离事务的执行状态,使它们好像是系统在给定时间内执行的唯一操作。例如有两个事务并发执行,事务的隔离性将确保每一事务在系统中认为只有该事务在使用系统。

  • D(durability): 持久性。在事务提交以后,该事务对数据库所做的更改便持久地保存在数据库之中,不会因掉电、进程异常故障而丢失。 openGauss数据库支持事务的隔离级别有读已提交和可重复读,默认隔离级别是读已提交,保证不会读到脏数据。 事务分为隐式事务和显式事务。显式事务的相关基础接口如下。

  • Start transaction:事务开启。

  • Commit:事务提交。

  • Rollback:事务回滚。

另有用户还可以通过set transaction命令设置事务的隔离级别、读写模式或可推迟模式。

(5) 软硬结合。

openGauss数据库支持软硬件地结合,包括多核地并发访问控制、基于SSD(solid-state drive,固态硬盘)地I/O(input/output,输入/输出)优化、智能地buffer pool(缓冲池)数据管理。

(6) 智能优化器。

openGauss数据库提供了智能的代价模型、智能计划选择,可以显著提升数据库性能。openGauss的执行器包含了向量化执行和LLVM(low level virtual machine,底层虚拟机,一种构架编译器的框架系统)编译执行,可以显著提升数据库性能。

(7) 支持AI。

传统数据库生态依赖于DBA(database administrator,数据库管理员)进行数据地管理、维护、监控、优化。但是在大量的数据库实例中,DBA难以支持海量实例,而AI(artificial intelligence,人工智能)则可以自动优化数据库,openGauss数据库的AI功能包括AI自调优、AI索引推荐、AI慢SQL诊断等。

(8) 支持安全。

openGauss数据库具有非常好的安全特性,包括透明加密(在磁盘的存储文件是加密的)、全密态(数据传输、存储、计算都是加密的)、防篡改(用户不可篡改)、敏感数据智能发现等。

(9) 支持函数和存储过程。

函数和存储过程是数据库中的一种重要对象,主要功能是将用户特定功能的SQL语句集进行封装并方便调用。存储过程是SQL、PL(procedural language SQL,过程语言SQL)/SQL的组合。存储过程可以使执行商业规则的代码从应用程序中移动到数据库,从而实现代码存储一次但能够被多个程序使用。

允许客户模块化程序设计,对SQL语句集进行封装,调用方便。 存储过程会进行编译缓存,可以提升用户执行SQL语句集的速度。 系统管理员通过对执行某一存储过程的权限进行限制,能够实现对相应数据访问权限的限制,避免了非授权用户对数据的访问,保证了数据的安全。 为了处理SQL语句,存储过程分配一段内存区域来保存上下文。游标是指向上下文区域的句柄或指针。借助游标,存储过程可以控制上下文区域的变化。 支持6种异常信息级别方便客户对存储过程进行调试,支持设置断点和单步调试。存储过程调试是一种调试手段,可以在存储过程开发中,一步一步跟踪存储过程执行的流程,根据变量的值,找到错误的原因或者程序的bug,提高问题定位效率。 openGauss支持SQL标准中的函数及存储过程,增强了存储过程的易用性。

(10) 兼容PostgreSQL接口。

openGauss数据库兼容PSQL客户端,兼容PostgreSQL标准接口。

(11) 支持SQL hint。

openGauss数据库支持SQL hint(hint是SQL语句的注释,可以指导优化器选择人为指定的执行计划),影响执行计划生成,提升SQL查询性能。Plan Hint为用户提供了直接影响执行计划生成的手段,用户可以通过指定join顺序、join方法、Scan方法、结果行数等多个手段进行执行计划的调优,以提升查询性能。

(12)支持Copy接口容错机制。

openGauss数据库中,用户可以使用封装好的函数创建Copy错误表,并能在使用Copy From语句时指定容错选项。指定容错选项后,openGauss数据库在执行Copy From语句过程中不会因"部分解析"、"数据格式"、"字符集"等相关的报错中断事务,而是把这些报错信息记录至错误表中,从而使得Copy From的目标文件即使有少量数据错误也可以完成入库操作。用户随后可以在错误表中对相关的错误进行定位以及进一步排查。

Posted by enmotech at 4:35 PM | Permalink |

December 3, 2021

openGauss 云安全技术

本文来源于墨天轮:https://www.modb.pro/db/185758

数据库最重要的作用是存储数据和处理分析数据。数据是整个数据库系统中最关键的资产。因此在保护系统不受侵害的基础上最为重要的任务就是保护数据的安全。常见的数据安全技术包括数据加密、数据脱敏(Data Masking)、透明加密(Transparent Data Encryption,TDE)和全程加密(Always Encryption)技术。这里囊括了数据的动态流程和静态存储行为。

一、数据加密算法

数据加解密是防止数据隐私泄露最为常见也最为有效的手段之一。数据在经过加密后以密文形式存放在指定的目录下。加密的意义在于,通过一系列复杂的迭代计算,将原本的明文转换为随机的没有任何具体含义的字符串,即密文。当所使用的加密算法足够安全时,攻击者在有限的计算资源下将很难根据密文获取到明文信息。

常见的加密算法可分为对称加密算法和非对称算法。其中最为著名的非对称加密算法叫RSA算法,其密钥长度须达到3072才可以保证其安全性,即强安全。常见的对称加密算法为AES算法,如AES128和AES256。相比于非对称加密算法,对称加密算法运算速度快,密文长度增长少,安全性容易证明,所需要的密钥长度短,但也存在密钥分发困难,不可以用于数字签名等缺点。除了上述介绍的加密算法外,还有很多其他强安全算法,在此不一一介绍。下面将重点介绍openGauss中所支持的数据加密能力。

首先openGauss在内核定义了数据加解密的函数,并对外提供了数据加解密的接口,函数接口为:

gsencryptaes128(text, initial_value);

其中,text为需要加密的明文数据,initial_value为生成密钥时需要的初始化向量。该函数可以被灵活的应用在SQL语法的各个地方。如通过使用INSERT语法插入数据或者查询数据时均可以绑定该函数对数据进行加密处理,具体如下:

SELECT * FROM gsencryptaes128(tbl.col, '1234');

通过该查询,用户可以直接返回表tbl中的col列的密文信息。

与加密函数相对应的是解密函数,其接口格式定义为:

gsdecryptaes128(cypertext, initial_value);

其中cypertext为加密之后的密文,initial_value需要为与加密时所采用的相同的值才可以。否则使用该函数也无法得到正确明文。

除了基本的数据加解密接口外,openGauss还在多个特性功能里提供了数据加解密功能。其中第一个提供加解密功能的特性是数据导入导出;第二个提供加解密功能的特性是数据库备份恢复。

二、数据脱敏技术

在很多应用场景下,用户需要通过拥有表中某一列的访问权来执行任务,但是又不能获取所做事务之外其他的权限。以快递人员举例,快递人员在递送包裹的时候需要知道收件人的联系方式和姓氏,但是无需知道对应的收件人的全称。在快递收件人信息部分,如果同时定义了收件人的姓名和电话,则暴露了收件人的隐私信息,"有心之人"可以通过此信息进行虚假信息构造或利用该隐私信息进行财产欺诈。因此在很多情况下,所定义的敏感信息是不建议对外展现的。

数据脱敏是解决此类问题的最有效方法之一,通过对敏感数据信息的部分信息或全量信息进行特殊处理可以有效掩盖敏感数据信息的真实部分,从而达到保护数据隐私信息的目的。数据脱敏按照脱敏呈现的时机可以分为数据动态脱敏和数据静态脱敏,其中前者在数据运行时对数据进行特殊处理,后者在数据存储的时候进行特殊处理以防止攻击者通过提取数据文件来直接获取敏感信息。在本文中,将重点介绍数据动态脱敏技术。

数据动态脱敏的安全意义在于:

用户在实际操作的时候无需真实数据只需要使用一个变化后的数据进行操作,可有效规避数据信息的直接暴露。 在不同的国家及地区的法律合规中,如GDPR,约定不同的用户在管理数据的时候具有不同的访问对象权限。 对于表中的同一列数据信息,不同的用户应具有不同的用途。

数据动态脱敏功能在数据库内核实际上表现为数据处理函数。通过函数处理使得数据库中的数据在返回给实际查询用户时数据值发生变更,如用户所有的年龄信息值在返回给客户端时均显示为"0";又或是字符串数据中的部分字节位变更为其他字符,如信用卡卡号"1234 5678 0910 1112"在返回给客户端时显示为"XXXX XXXX XXXX 1112"。

在openGauss系统中,数据动态脱敏策略的语法定义如下所示:

CREATE MASKINGPOLICY policyname

(

(masking_clause)

[filter_clause]

[ENABLE|DISABLE]

); 其中具体的参数说明如下:

  • maskingclause语法定义如下: MASKINGFUNCTION(PARAMETERS) ON (SCOPE(FQDN)) | (LABEL(resourcelabelname)) [, ...]*;

定义了针对不同数据集合对象所采用的脱敏函数。这里LABEL为数据库安全标签,数据库安全标签实际上定义了一组数据内部的表对象或表中的部分列,用于标记相应数据脱敏策略的范围。

  • filterclause语法定义如下: FILTER ON FILTERTYPE(filter_value [, ...]) [, ...];

定义了数据动态脱敏策略所支持的过滤条件。

一个实际的数据动态脱敏案例如下:

CREATE MASKINGPOLICY mymasking_policy

creditcardmasking ON LABEL (mask_credcard),

maskall ON LABEL (mask_all)

FILTER ON IP(local), ROLES(dev);

其中,mymaskpolidy为定义的数据动态脱敏策略名字;creditcardmasking以及maskall为定义的masking处理函数,分别用于处理从属于maskcredcard对象集合和maskall对象集合;maskcredcard和maskall代表不同的Label对象,这些Label对象名称将作为唯一标识记录在系统表中。FILTER表示当前动态脱敏策略所支持的连接源,连接源指的是实际数据库管理员使用何种用户,从何IP源位置发起,使用何种APP应用来访问当前的数据库。通过使用FILTER可以有效定义系统的访问源信息,并规避不应该访问当前系统的行为。

openGauss在系统内部预定义了七种数据脱敏策略。具体如下表所示:

数据脱敏策略 屏幕快照 2021-12-03 上午10.04.45.png

用户在实际使用时,还可以根据自己的需求自行定义数据脱敏策略。

三、透明加密技术

当数据在静态存储状态时,除了使用常见的静态脱敏进行数据隐私保护外。另外一种行之有效的方法是透明加密(TDE)。事实上,静态脱敏在实际应用过程中是存在一定的限制的。用户并不能对所有的数据类型都施加静态脱敏措施。

数据透明加密从加密策略出发,即使用户数据被导出,也可以有效解决数据信息泄露风险。数据透明加密的初衷是为了防止第三方人员绕过数据库认证机制,直接读取数据文件中的数据(数据文件中的数据虽然是二进制数据,但是仍然是明文存放)。所以对数据库的数据文件进行加密后,必须在数据库启动后,用户通过正常途径连接数据库,才可以读取解密后的数据,达到数据保护的目的。

openGauss实施透明加密策略,首先是需要确定一个数据库密钥(Database Encryption Key,DEK),该DEK由系统密钥管理系统(Key Management Service,KMS)生成,数据库密钥密文(Encrypted Database Encryption Key,EDEK)以文件方式(gstdekeys.cipher)存储于数据库系统中。该DEK一次生成,终身使用,不可变更,不可轮换。在快照(即备份)恢复时,需要使用此前的DEK。

数据库节点在每次启动时,通过读取本地存储的密钥信息和密钥密文(EDEK),向KMS机器上的URL地址,传入密钥版本名(version-name),密钥名(name),IV值和数据库加密密钥密文值,从而获取到解密后的数据库加密密钥DEK。此密钥会缓存在节点的内存当中,当数据库需要加解密数据时从内存中拷贝密钥明文。

openGauss支持两种格式的透明加密算法,通过GUC参数transparentencryptionalgo来进行控制,当前支持的算法包括AES-CTR-128和SM4-CTR-128。加密模式选用CTR(CounTeR,计数器模式)的原因是CTR流加密可以保证明文和密文长度相等。明文和密文长度相等是由数据块(Block)的大小决定的,因为内存和磁盘存储格式对Block的大小是有要求的(默认8K)。特别的,在openGauss列存储中,列存储单元(Column Unit,CU)的最大大小是有限制的,所以也不能存在加密后长度超过最大限制。

一个完整的透明加密流程如下图所示。即该特性的生命周期共分为3个阶段:安装阶段、启动阶段和使用阶段。

  • 安装阶段用户通过安装部署的配置,生成密钥记录文件和GUC参数。

  • 启动阶段依据密钥记录文件和GUC参数,获取到明文。

  • 使用阶段用户根据密钥算法标记和全局缓存明文,完成数据落盘的加密和数据读取的解密。

透明加密流程.png

四、全程加密技术

无论是当前通用数据脱敏方案,还是数据透明加密方案,其所解决的都是部分状态或部分流程下的数据隐私安全。数据库攻击者可通过其他不同的攻击技术手段在数据以明文存在的阶段或处于内存中的时候抓取数据流信息,从而达到获取数据隐私数据的目的。如果数据在整个生命周期过程中都能够处于加密的形态,且密钥掌握在用户自己手中。则数据库用户可有效的防止数据隐私安全泄露。

全程加密技术就是在这种场景下诞生的。其核心是使得数据从用户手中进入到数据库系统后一直处于加密状态,用户所关心的数据分析过程也在密态状态下完成。在整个数据分析处理过程中,即使用户数据被攻击者窃取,由于密钥一直掌握在客户自己手中,攻击者也无法获得相关的信息。目前该技术处于研发阶段,对应产品尚未向客户发布。

openGauss数据库分成三个阶段来实现完整的全程加密功能。

  • 第一阶段是客户端全程加密能力,系统在客户端提供数据加解密模块和密钥管理模块,在这种设计思路下数据在客户端完成加密后进入数据库,在完成处理分析返回结果的时候在客户端完成解密功能,客户端全程加密的缺陷在于只能支持等值类查询。

  • 在第二阶段,将在服务端实现基于密文场景的密文查询和密文检索能力,使得数据库具备更加强大的处理能力。

  • 第三阶段openGauss将构建基于可信硬件的可信计算能力。在此我们将基于鲲鹏芯片来构建数据库的可信计算能力。在可信硬件中,完成对数据的解密和计算。数据从可信硬件进入到真实世界后,将再加密成密文返回给客户。 一个完整的openGauss数据库全程加密方案架构如图所示。 openGauss 全程加密示意图.png

首先来介绍openGauss客户端全程加密方案,我们也称之为客户端列加密方案(Client Column Encryption,CCE)。在该方案中,首先应该由用户来指定对哪一列数据进行加密,通过在指定的属性列后面加上关键字"encrypted"来进行标记,如下述语法所示:

CREATE TABLE test_encrypt(creditcard varchar(19) encrypted);

为了有效保证加密数据的安全性并支持数据的密态查询,在内核中我们选用确定性AES算法,具体来说其加密算法为:

AEADAES256CBCHMACSHA256。整个方案中使用双层密钥方案,第一层根密钥用户向密钥管理中心获取,作为根密钥(master key)。第二层为数据加密密钥,也称之为工作密钥。工作密钥通过根密钥加密后存放在服务器端。在加密列创建完成后,如果没有工作密钥,则系统会单独为该列创建一个工作密钥。不同的属性列可以通过创建语法指定并共享列加密密钥。

为保证整个系统的安全性,加密工作密钥的加密算法强度应高于使用工作密钥加密数据的强度。在openGauss数据库中,我们使用RSA-OAEP算法来加密工作密钥,而根密钥仅存放在客户端。密钥层次关系如图所示。

全程加密方案密钥管理方案.png

由于采用确定性加密算法,对于相同的明文,所获取的密文也是相同的。在这种机制下,客户端全程加密可有效的支持等值查询,我们只需要将对应的查询条件中的参数按照对应属性列的加密算法进行加密,并传给服务端即可。一个完整的客户端全程加密逻辑流程如图所示。在流程图的客户端部分,我们需要优先检查相关信息的有效性。 客户端加密方案查询流程图.png 客户端全程加密方案是非常简单易懂的,通过确定加密机制保障结果的正确性和完整性。但对于日益复杂的查询任务来说,客户端全程加密方案是远远不够的。因为客户端全程加密仅仅能满足那些等值查询的查询任务,如等值条件查询、分组、连接操作等等。对于那些更为复杂的数据搜索,比较查询、范围查询等等,则需要更为复杂的密态查询算法或服务端可信硬件方案。

事实上,密文查询算法和检索算法在学术界一直都是热点的研究方向,如OPE(Order Preserve Encryption)/ORE(Order Reveal Encryption)算法、SSE(Symmetric Searchable Encryption)算法等。openGauss将针对排序、范围查询、模糊检索实现纯软件态的密文查询和密文检索。纯软方案的缺陷在于由于在密文状态下进行运算,会导致系统整体性能变慢。为了支持密态计算,需要密文在计算完成后解密的结果与明文计算所获得的结果相同。全同态加密是最行之有效的算法,可有效解决数据在密文形态下的加法和乘法计算,而不暴露相关明文信息。但是全同态加密最大的问题在于其性能过于低效,以至于没有一款商业数据库支持该能力,哪怕是部分同态加密能力,如加法同态或者乘法同态。

在第三阶段,openGauss将提供基于可信硬件的密态计算能力。其核心是数据以密文形态进入服务端可信硬件中并完成所需要的密文计算。可信硬件将系统内核分为安全世界和非安全世界。数据计算完成后再以密文形态返回给非安全世界,并最终返回给客户端。目前通用的Intel芯片和ARM芯片均提供了相类似的功能。在Intel芯片中,该隔离区域被称之为SGX(Software Guard Extensions)。SGX是一个被物理隔离的区域,数据即使以明文形式存放在该物理区域内,攻击者也无法访问。在ARM架构中,与其类似的功能被称之为Trust Zone,基于Trust Zone,人们可以构建可信操作系统(Trusted OS),然后可以开发相对应的可信应用。基于可信计算环境,用户可以解密这些数据进行各类数据库查询操作。当数据离开这些环境后,数据则以密文形态存在,并返回给客户再进行解密。从而起到保护数据隐私的目的。

Posted by enmotech at 10:02 AM | Permalink |

November 30, 2021

MacOS Monterey在腾讯会议声音不起作用coreaudiod重置

最近总是遇到腾讯会议启动,电脑的音频失效情况。经验值,以下重启 coreaudiod 的逻辑有效。

MacOS Monterey 的系统。

启动终端并输入以下命令:

sudo killall coreaudiod

Return ,输入您的管理员密码,然后再次检查声音。 coreaudiod进程应该重新启动。

在极少数情况下,可能还存在听不到声音的问题。可以尝试以下命令:

sudo launchctl start com.apple.audio.coreaudiod

launchctl命令启动守护进程并重新初始化coreaudiod进程。

在我的情况下,通过第一个命令,声音得到了恢复。

Posted by eygle at 9:10 AM | Permalink | System (106)

November 25, 2021

openGauss 分布式事务

前面我们简要介绍了单机事务和分布式事务的区别,也指出了在分布式情况下,可能存在特有的原子性和一致性问题。本文主要介绍在openGauss数据库中,如何保证分布式事务的原子性和强一致性。

1 分布式事务原子性和两阶段提交协议

为了保证分布式事务的原子性,防止出现如图10-2中所示的部分DN提交、部分DN回滚的"中间态"事务,openGauss采用两阶段提交(2PC)协议。

两阶段提交流程示意图.png

两阶段提交流程示意图

如上图所示,顾名思义,两阶段提交协议将事务的提交操作分为两个阶段:

  • 阶段一,准备阶段(prepare phase),在这个阶段,将所有提交操作所需要使用到的信息和资源全部写入磁盘,完成持久化;

  • 阶段二,提交阶段(commit prepared phase),根据之前准备好的提交信息和资源,执行提交或回滚操作。 两阶段提交协议之所以能够保证分布式事务原子性的关键在于:一旦准备阶段执行成功,那么提交需要的所有信息都完成持久化下盘,即使后续提交阶段某个DN发生执行错误,该DN可以再次从持久化的提交信息中尝试提交,直至提交成功。最终该分布式事务在所有DN上的状态一定是相同的,要么所有DN都提交,要么所有DN都回滚。因此,对外来说,该事务的状态变化是原子的。

下表总结了在openGauss分布式事务中的不同阶段,如果发生故障或执行失败,分布式事务的最终提交/回滚状态,读者可自行推演,本文不再赘述。

发生故障或执行失败时事务的最终状态

屏幕快照 2021-11-25 下午3.43.05.png

2 分布式事务一致性和全局事务管理

为了防止瞬时不一致现象,支持分布式事务的强一致性,我们需要全局范围内的事务号和快照,以保证全局MVCC和快照的一致性。在openGauss中,GTM负责提供和分发全局的事务号和快照。对于任何一个读事务,其都需要到GTM上获取全局快照;对于任何一个写事务,其都需要到GTM上获取全局事务号。

为了防止瞬时不一致现象,支持分布式事务的强一致性,我们需要全局范围内的事务号和快照,以保证全局MVCC和快照的一致性。在openGauss中,GTM负责提供和分发全局的事务号和快照。对于任何一个读事务,其都需要到GTM上获取全局快照;对于任何一个写事务,其都需要到GTM上获取全局事务号。

分布式事务一致性问题示意图.png

分布式事务一致性问题示意图

在上图中加入GTM,并考虑两阶段提交流程之后,分布式读-写并发事务的流程如下图所示。对于读事务来说,由于写事务在其从GTM获取的快照中,因此即使写事务在不同DN上的提交顺序和读事务的执行顺序不同,也不会造成不一致的可见性判断和不一致的读取结果。

读-写并发下全局事务号和快照的分发流程示意图.png

读-写并发下全局事务号和快照的分发流程示意图

细心的读者会发现,在上图的两阶段提交流程中,写事务T1在各个DN上完成准备阶段之后,首先第一步是到GTM上结束T1事务(将T1从全局快照中移除),然后第二步再到各个DN上进行提交阶段。在这种情况下,如果查询事务T2是在第一步和第二步之间在GTM上获取快照,并到各个DN上执行查询的话,那么T2事务读到的T1事务插入的记录v1和v2,它们xmin对应的XID1已经不在T2事务获取到的全局快照中,因此v1和v2的可见性判断会完全基于T1事务的提交状态。然而,此时XID1对应的T1事务在各个DN上可能还没有全部或部分完成提交阶段,那么就会出现各个DN上可见性不一致的情况。

为了防止上面这种问题出现,在openGauss中采用本地二阶段事务补偿机制。如下图所示,对于在DN上读取到的记录,如果其xmin或者xmax已经不在快照中,但是它们对应的写事务还在准备阶段,那么查询事务将会等到这些写事务在DN本地完成提交阶段之后,再进行可见性判断。考虑到通过两阶段提交协议,可以保证各个DN上事务最终的提交或回滚状态一定是一致的,因此在这种情况下各个DN上记录的可见性判断也一定是一致的。

读-写并发下本地两阶段事务补偿流程示意图.png

读-写并发下本地两阶段事务补偿流程示意图

3 小结

本文主要结合openGauss数据库的事务机制和实现原理,基于显式事务和隐式事务,介绍事务块状态机的变化,以及openGauss事务ACID特性的实现方式。尤其的,对于分布式场景下的事务原子性和一致性问题,介绍openGauss采取的多种解决技术方案,以保证数据库最终对外呈现的ACID不受分布式执行框架的影响。

Posted by enmotech at 2:52 PM | Permalink | modb.pro (35)

近期发表

  • openGauss 数据库并发控制 - November 24, 2021
  • openGauss 数据库事务概览 - November 22, 2021
  • openGauss 数据库内存引擎 - November 19, 2021
  • openGauss 数据库列存储引擎 - November 18, 2021
  • 墨天轮国产数据库沙龙 | 胡彦军:华为GaussDB迁移工具解密 - November 17, 2021
  • 国产数据库沙龙 | 张晓庆:GoldenDB分布式数据库自动安装与备份恢复 - November 17, 2021
  • openGauss 数据库存储概览 - November 16, 2021
  • 循序渐进 openGauss :初始化参数的设置、查询和修改 - November 15, 2021
  • openGauss 高级特性介绍 - November 15, 2021
  • openGauss 数据库执行器概述 - November 11, 2021


  • CopyRight © 2004 ~ 2012 eygle.com, All rights reserved.