MySQL · 特性分析 · MySQL 5.7 外部XA Replication实现及缺陷分析

本文涉及的产品
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
RDS MySQL Serverless 高可用系列,价值2615元额度,1个月
简介:

MySQL 5.7 外部XA Replication实现及缺陷分析

MySQL 5.7增强了分布式事务的支持,解决了之前客户端退出或者服务器关闭后prepared的事务回滚和服务器宕机后binlog丢失的情况。

为了解决之前的问题,MySQL5.7将外部XA在binlog中的记录分成了两部分,使用两个GTID来记录。执行prepare的时候就记录一次binlog,执行commit/rollback再记录一次。由于XA是分成两部分记录,那么XA事务在binlog中就可能是交叉出现的。Slave端的SQL线程在apply的时候需要能够在这些不同事务间切换。

但MySQL XA Replication的实现只考虑了Innodb一种事务引擎的情况,当添加其他事务引擎的时候,原本的一些代码逻辑就会有问题。同时MySQL源码中也存在宕机导致主备不一致的缺陷。

MySQL 5.7 外部XA Replication源码剖析

Master写入

当执行 XA START ‘xid’后,内部xa_state进入XA_ACTIVE状态。

bool Sql_cmd_xa_start::trans_xa_start(THD *thd)
{
 xid_state->set_state(XID_STATE::XA_ACTIVE);

第一次记录DML操作的时候,通过下面代码可以看到,对普通事务在binlog的cache中第一个event记录’BEGIN’,如果是xa_state处于XA_ACTIVE状态就记录’XA START xid’,xid为序列化后的。

static int binlog_start_trans_and_stmt(THD *thd, Log_event *start_event)
{
 if (cache_data->is_binlog_empty())
 {
 if (is_transactional && xs->has_state(XID_STATE::XA_ACTIVE))
 {
 /*
 XA-prepare logging case.
 */
 qlen= sprintf(xa_start, "XA START %s", xs->get_xid()->serialize(buf));
 query= xa_start;
 }
 else
 {
 /*
 Regular transaction case.
 */
 query= begin;
 }

 Query_log_event qinfo(thd, query, qlen,
 is_transactional, false, true, 0, true);
 if (cache_data->write_event(thd, &qinfo))
 DBUG_RETURN(1);

XA END xid的执行会将xa_state设置为XA_IDLE。

bool Sql_cmd_xa_end::trans_xa_end(THD *thd)
{
 xid_state->set_state(XID_STATE::XA_IDLE);

当XA PREPARE xid执行的时候,binlog_prepare会通过检查thd的xa_state是否处于XA_IDLE状态来决定是否记录binlog。如果在对应状态,就会调用MYSQL_BINLOG的commit函数,记录’XA PREPARE xid’,将之前cache的binlog写入到文件。

static int binlog_prepare(handlerton *hton, THD *thd, bool all) {
 DBUG_RETURN(all && is_loggable_xa_prepare(thd) ?
 mysql_bin_log.commit(thd, true) : 0);


inline bool is_loggable_xa_prepare(THD *thd) {
 return DBUG_EVALUATE_IF("simulate_commit_failure",
 false,
 thd->get_transaction()->xid_state()->
 has_state(XID_STATE::XA_IDLE));

TC_LOG::enum_result MYSQL_BIN_LOG::commit(THD *thd, bool all)
{
 if (is_loggable_xa_prepare(thd))
 {
 XID_STATE *xs= thd->get_transaction()->xid_state();
 XA_prepare_log_event end_evt(thd, xs->get_xid(), one_phase);
 err= cache_mngr->trx_cache.finalize(thd, &end_evt, xs)
 }

当XA COMMIT/ROLLBACK xid执行时候,调用do_binlog_xa_commit_rollback记录’XA COMMIT/ROLLBACK xid’。

TC_LOG::enum_result MYSQL_BIN_LOG::commit(THD *thd, bool all)
{
 if (thd->lex->sql_command == SQLCOM_XA_COMMIT)
 do_binlog_xa_commit_rollback(thd, xs->get_xid(),
 true)))

int MYSQL_BIN_LOG::rollback(THD *thd, bool all)
{
 if (thd->lex->sql_command == SQLCOM_XA_ROLLBACK)
 if ((error= do_binlog_xa_commit_rollback(thd, xs->get_xid(), false)))

由于XA PREPARE单独记录binlog,那么binlog中的events一个xa事务就可能是分隔开的。举个例子,session1中xid为’a’的分布式事务执行xa prepare后,session2中执行并提交了xid为’z’的事务,然后xid ‘a’才提交。我们可以看到binlog events中xid ‘z’的events在’a’的prepare和commit之间。

session1:
xa start 'a'; insert into t values(1);
xa end 'a';
xa prepare 'a';

session2:
xa start 'z'; insert into t values(2);
xa end 'z';
xa prepare 'z';
xa commit 'z';

session1:
xa commit 'a';


| mysql-bin.000008 | 250 | Gtid | 324 | 298 | SET @@SESSION.GTID_NEXT= 'uuid:9' |
| mysql-bin.000008 | 298 | Query | 324 | 385 | XA START X'61',X'',1 |
| mysql-bin.000008 | 385 | Table_map | 324 | 430 | table_id: 72 (test.t) |
| mysql-bin.000008 | 430 | Write_rows_v1 | 324 | 476 | table_id: 72 flags: STMT_END_F |
| mysql-bin.000008 | 476 | Query | 324 | 561 | XA END X'61',X'',1 |
| mysql-bin.000008 | 561 | XA_prepare | 324 | 598 | XA PREPARE X'61',X'',1 |
| mysql-bin.000008 | 598 | Gtid | 324 | 646 | SET @@SESSION.GTID_NEXT= 'uuid:10' |
| mysql-bin.000008 | 646 | Query | 324 | 733 | XA START X'7a',X'',1 |
| mysql-bin.000008 | 733 | Table_map | 324 | 778 | table_id: 72 (test.t) |
| mysql-bin.000008 | 778 | Write_rows_v1 | 324 | 824 | table_id: 72 flags: STMT_END_F |
| mysql-bin.000008 | 824 | Query | 324 | 909 | XA END X'7a',X'',1 |
| mysql-bin.000008 | 909 | XA_prepare | 324 | 946 | XA PREPARE X'7a',X'',1 |
| mysql-bin.000008 | 946 | Gtid | 324 | 994 | SET @@SESSION.GTID_NEXT= 'uuid:11' |
| mysql-bin.000008 | 994 | Query | 324 | 1082 | XA COMMIT X'7a',X'',1 |
| mysql-bin.000008 | 1082 | Gtid | 324 | 1130 | SET @@SESSION.GTID_NEXT= 'uuid:12' |
| mysql-bin.000008 | 1130 | Query | 324 | 1218 | XA COMMIT X'61',X'',1 |

Slave 重放

由于XA事务在binlog中是会交叉出现的,Slave的SQL线程如果按照原本普通事务的方式重放,那么就会出现SQL线程中还存在处于prepared状态的事务,就开始处理下一个事务了,锁状态、事务状态等会错乱。所以SQL线程需要能够支持这种情况下不同事务间的切换。

SQL线程要做到能够在执行XA事务时切换到不同事务,需要做到server层保留原有xid的Transaction_ctx信息,引擎层也保留原有xid的事务信息。

server层保留原有xid的Transaction_ctx信息是通过在prepare的时候将thd中xid的Transaction_ctx信息从transacion_cache中detach掉,创建新的保留了XA事务信息的Transaction_ctx放入transaction_cache中。

bool Sql_cmd_xa_prepare::execute(THD *thd)
 !(st= applier_reset_xa_trans(thd)))

bool applier_reset_xa_trans(THD *thd) transaction_cache_detach(trn_ctx);

bool transaction_cache_detach(Transaction_ctx *transaction)
 res= create_and_insert_new_transaction(&xid, was_logged);

引擎层的实现并不是通过在prepare的时候创建新trx_t的来保存原有事务信息。而是在XA START的时候将原来thd中所有的engine ha_data单独保留起来,为XA事务创建新的。在XA PREPARE的时候,再将原来的reattach回来,将XA的从thd detach掉,解除XA和thd的关联。引擎层添加了新的接口replace_native_transaction_in_thd来支持上述操作。对于Slave的SQL线程,函数调用如下:

//engine 新添加的接口 struct handlerton
{
 void (*replace_native_transaction_in_thd)(THD *thd, void *new_trx_arg, void **ptr_trx_arg);

//XA START函数调用 bool Sql_cmd_xa_start::execute(THD *thd)
{
 thd->rpl_detach_engine_ha_data();

void THD::rpl_detach_engine_ha_data()
{
 rli->detach_engine_ha_data(this);

//每个Storage engine都调用detach_native_trx void Relay_log_info::detach_engine_ha_data(THD *thd)
{
 plugin_foreach(thd, detach_native_trx,
 MYSQL_STORAGE_ENGINE_PLUGIN, NULL);

my_bool detach_native_trx(THD *thd, plugin_ref plugin, void *unused) {
 if (hton->replace_native_transaction_in_thd)
 hton->replace_native_transaction_in_thd(thd, NULL,
 thd_ha_data_backup(thd, hton));

//XA PREPARE函数调用 bool Sql_cmd_xa_prepare::execute(THD *thd)
{
 !(st= applier_reset_xa_trans(thd)))

bool applier_reset_xa_trans(THD *thd) {
 attach_native_trx(thd);

//对事务涉及到的引擎调用reattach_engine_ha_data_to_thd。 static void attach_native_trx(THD *thd) {
 if (ha_info)
 {
 for (; ha_info; ha_info= ha_info_next)
 {
 handlerton *hton= ha_info->ht();
 reattach_engine_ha_data_to_thd(thd, hton);
 ha_info_next= ha_info->next();
 ha_info->reset();
 }
 }

inline void reattach_engine_ha_data_to_thd(THD *thd, const struct handlerton *hton) {
 if (hton->replace_native_transaction_in_thd)
 hton->replace_native_transaction_in_thd(thd, *trx_backup, NULL);

当XA COMMIT/ROLLBACK执行的时候,如果当前thd中没有对应的xid,就会从transaction_cache中查找对应xid的state信息,然后调用各个引擎的commit_by_xid/rollback_by_xid接口提交/回滚XA事务。

bool Sql_cmd_xa_commit::trans_xa_commit(THD *thd)
{
 if (!xid_state->has_same_xid(m_xid))
 {
 Transaction_ctx *transaction= transaction_cache_search(m_xid);
 ha_commit_or_rollback_by_xid(thd, m_xid, !res);

static void ha_commit_or_rollback_by_xid(THD *thd, XID *xid, bool commit) {
 plugin_foreach(NULL, commit ? xacommit_handlerton : xarollback_handlerton,
 MYSQL_STORAGE_ENGINE_PLUGIN, xid);

static my_bool xacommit_handlerton(THD *unused1, plugin_ref plugin, void *arg) {
 if (hton->state == SHOW_OPTION_YES && hton->recover)
 hton->commit_by_xid(hton, (XID *)arg);

static my_bool xarollback_handlerton(THD *unused1, plugin_ref plugin, void *arg) {
 if (hton->state == SHOW_OPTION_YES && hton->recover)
 hton->rollback_by_xid(hton, (XID *)arg); 

由于XA COMMIT/XA ROLLBACK是单独作为一部分,这部分并没有原来XA事务涉及到库、表的信息,所以XA COMMIT在Slave端当slave-parallel-type为DATABASE时是无法并发执行的,在slave端强制设置mts_accessed_dbs为OVER_MAX_DBS_IN_EVENT_MTS使其串行执行。

bool Log_event::contains_partition_info(bool end_group_sets_max_dbs)
{
 case binary_log::QUERY_EVENT:
 {
 Query_log_event *qev= static_cast<Query_log_event*>(this);
 if ((ends_group() && end_group_sets_max_dbs) ||
 (qev->is_query_prefix_match(STRING_WITH_LEN("XA COMMIT")) ||
 qev->is_query_prefix_match(STRING_WITH_LEN("XA ROLLBACK"))))
 {
 res= true;
 qev->mts_accessed_dbs= OVER_MAX_DBS_IN_EVENT_MTS;
 }

MySQL5.7 外部XA Replication实现的缺陷分析

Prepare阶段可能导致主备不一致

MySQL中普通事务提交的时候,需要先在引擎中prepare,然后再写binlog,之后再做引擎commit。但在MySQL执行XA PREPARE的时候先写入了binlog,然后才做引擎的prepare。如果引擎在做prepare的时候失败或者服务器crash就会导致binlog和引擎不一致,主备进入不一致的状态。

在MySQL5.7中对模拟simulate_xa_failure_prepare的DEBUG情况做如下修改,使之模拟在Innodb引擎prepare的时候失败。

--- a/sql/handler.cc
+++ b/sql/handler.cc
@@ -1460,10 +1460,12 @@ int ha_prepare(THD *thd)
 thd->status_var.ha_prepare_count++;
 if (ht->prepare)
 {
- DBUG_EXECUTE_IF("simulate_xa_failure_prepare", {
- ha_rollback_trans(thd, true);
- DBUG_RETURN(1);
- });
+ if (ht->db_type == DB_TYPE_INNODB) {
+ DBUG_EXECUTE_IF("simulate_xa_failure_prepare", {
+ ha_rollback_trans(thd, true);
+ DBUG_RETURN(1);
+ });
+ }
 if (ht->prepare(ht, thd, true))
 {
 ha_rollback_trans(thd, true);

然后运行下面的case,可以看到Master上的XA失败后被回滚。但由于这个时候已经写入了binlog events,导致Slave端执行了XA事务,留下一个处于prepared状态的XA事务。

replication.test:

--disable_warnings
source include/master-slave.inc;
--enable_warnings
connection master;
CREATE TABLE ti (c1 INT) ENGINE=INNODB;
XA START 'x'; INSERT INTO ti VALUES(1);
XA END 'x'; SET @@session.debug = '+d,simulate_xa_failure_prepare'; --error ER_XA_RBROLLBACK
XA PREPARE 'x'; --echo #Master
XA RECOVER;

--sync_slave_with_master
connection slave;
--echo #Slave
XA RECOVER;


replication.result:

include/master-slave.inc
[connection master]
CREATE TABLE ti (c1 INT) ENGINE=INNODB;
XA START 'x'; INSERT INTO ti VALUES(1);
XA END 'x'; SET @@session.debug = '+d,simulate_xa_failure_prepare';
XA PREPARE 'x';
ERROR XA100: XA_RBROLLBACK: Transaction branch was rolled back
#Master
XA RECOVER;
formatID gtrid_length bqual_length data
#Slave
XA RECOVER;
formatID gtrid_length bqual_length data
1 1 0 x

在MySQL5.7源码中,如果在binlog和InnoDB引擎都prepare之后是不是数据就安全了呢?我们在ha_prepare函数中while循环调用完所有引擎prepare函数之后添加如下DEBUG代码,可以控制在prepare调用结束后服务器crash掉。

--- a/sql/handler.cc
+++ b/sql/handler.cc
@@ -1479,6 +1479,7 @@ int ha_prepare(THD *thd)
 }
 ha_info= ha_info->next();
 }
+ DBUG_EXECUTE_IF("crash_after_xa_prepare", DBUG_SUICIDE(););

 DBUG_ASSERT(thd->get_transaction()->xid_state()->
 has_state(XID_STATE::XA_IDLE));

然后跑下面的testcase。可以看到即使所有引擎都prepare了,宕机重启后XA RECOVER还是还是没有能够找回之前prepare的事务。而且这个时候我们查看binlog文件可以看到binlog已经写成功,这也会导致主备不一致。很明显,应该是InnoDB引擎丢失了prepare的日志。那么是什么原因导致这个问题?感兴趣的同学可以查看int MYSQL_BIN_LOG::ordered_commit(THD *thd, bool all, bool skip_commit)和innobase中trx_prepare的代码,看process_flush_stage_queue和flush_logs和thd->durability_property的相关逻辑。这里不再展开详细叙述。

replication.test:

-- source include/have_log_bin.inc CREATE TABLE ti (c1 INT) ENGINE=INNODB;
XA START 'x'; INSERT INTO ti VALUES(1);
XA END 'x'; SET @@session.debug = '+d,crash_after_xa_prepare'; --exec echo "wait" > $MYSQLTEST_VARDIR/tmp/mysqld.1.expect --error 2013
XA PREPARE 'x'; --source include/wait_until_disconnected.inc --let $_expect_file_name= $MYSQLTEST_VARDIR/tmp/mysqld.1.expect --source include/start_mysqld.inc
XA RECOVER;
show binlog events in 'mysql.000001';


replication.result:
CREATE TABLE ti (c1 INT) ENGINE=INNODB;
XA START 'x'; INSERT INTO ti VALUES(1);
XA END 'x'; SET @@session.debug = '+d,crash_after_xa_prepare';
XA PREPARE 'x';
ERROR HY000: Lost connection to MySQL server during query
# restart
XA RECOVER;
formatID gtrid_length bqual_length data
show binlog events in 'mysql.000001';
Log_name Pos Event_type Server_id End_log_pos Info
mysql.000001 4 Format_desc 1 123 Server ver: 5.7.19org-debug-log, Binlog ver: 4
mysql.000001 123 Previous_gtids 1 154
mysql.000001 154 Anonymous_Gtid 1 219 SET @@SESSION.GTID_NEXT= 'ANONYMOUS'
mysql.000001 219 Query 1 331 use `test`; CREATE TABLE ti (c1 INT) ENGINE=INNODB
mysql.000001 331 Anonymous_Gtid 1 396 SET @@SESSION.GTID_NEXT= 'ANONYMOUS'
mysql.000001 396 Query 1 483 XA START X'78',X'',1
mysql.000001 483 Table_map 1 528 table_id: 222 (test.ti)
mysql.000001 528 Write_rows 1 568 table_id: 222 flags: STMT_END_F
mysql.000001 568 Query 1 653 XA END X'78',X'',1
mysql.000001 653 XA_prepare 1 690 XA PREPARE X'78',X'',1 

上面两个问题的修复,都可以通过先执行事务引擎的prepare操作,再调用binlog的prepare来解决。

不支持server中使用多个事务引擎

在上面实现分析中可以看到Slave在执行XA START的时候,由于这个时候并不知道该XA事务涉及到哪些引擎,所以对所有Storage engine引擎都调用了detach_native_trx。但在XA PREPARE的时候,源码中只对XA涉及到的引擎调用了reattach_engine_ha_data_to_thd。对于引擎可插拔的MySQL来说,当server中不止一个事务引擎,这里就会存在有的引擎原thd中的trx被detach后没有被reattach。

我们可以拿支持tokudb的percona server做对应实验。对DEBUG编译的server,执行下面replication的testcase。该case对TokuDB做一个完整的XA事务后,再向Innodb写入。运行该case,slave端会产生assert_fail的错误。因为TokuDB执行XA事务时,将Innodb的ha_data放入backup,但由于Innodb没有参与该XA事务,所以并没有reattach,导致gdb可以看到assert_fail处InnoDB的ha_ptr_backup不为NULL,不符合预期。

replication.test
--disable_warnings
source include/master-slave.inc;
--enable_warnings
connection master;
create table tk(c1 int) engine=tokudb;
create table ti(c1 int) engine=innodb;

xa start 'x';
insert into tk values(1);
xa end 'x';
xa prepare 'x';
xa commit 'x';

insert into ti values(2);

__assert_fail
thd->ha_data[ht_arg->slot].ha_ptr_backup == __null || (thd->get_transaction()->xid_state()-> has_state(XID_STATE::XA_ACTIVE))"

(gdb) p thd->ha_data[ht_arg->slot].ha_ptr_backup
$1 = (void *) 0x2b11e0401070

修复问题,可以在需要reattach_engine_ha_data_to_thd的代码处,对所有storage engine再次调用该操作。

不支持新接口的事务引擎重放新XA事务会出错

对于不支持reattach_engine_ha_data_to_thd的事务引擎实际是不支持重放MySQL5.7新XA方式生成的binlog的,但在源码中并没有合适禁止操作。这就会导致slave在apply的时候数据错乱。

继续使用支持tokudb的percona server做实验。由于TokuDB并没有实现reattach_engine_ha_data_to_thd接口,Slave在重放XA事务的时候,在TokuDB引擎中实际就在原本关联thd的trx上操作,并没有生成新的trx。这就会导致数据等信息错乱,可以看到下面的例子。session1做了一个XA事务,插入数值1,prepare后并没有提交。随后另一个session插入数值2,但在slave同步后,数值2无法查询到。在session1提交了XA事务,写入TokuDB的数值1、2才在slave端查询到。

replication.test:

--disable_warnings
source include/master-slave.inc;
--enable_warnings
connection master;
--echo #Master create table tk(c1 int) engine=tokudb;
xa start 'x'; insert into tk values(1);
xa end 'x';
xa prepare 'x';
connect(m, localhost, root, , test, $MASTER_MYPORT);
insert into tk values(2); select * from tk; --sync_slave_with_master
connection slave;
--echo #Slave select * from tk;

connection master;
--echo #Master
xa commit 'x'; select * from tk; --sync_slave_with_master
connection slave;
--echo #Slave select * from tk;

connection master;
drop table tk;



replication.result:

include/master-slave.inc
[connection master]
#Master
create table tk(c1 int) engine=tokudb;
xa start 'x'; insert into tk values(1);
xa end 'x';
xa prepare 'x'; insert into tk values(2); select * from tk;
c1
2
#Slave
select * from tk;
c1
#Master
xa commit 'x'; select * from tk;
c1
1
2
#Slave
select * from tk;
c1
1
2
drop table tk; 

修复该问题,需要对没有实现新接口的事务引擎在执行XA时候给与合适的禁止操作,同时需要支持新XA的事务引擎要实现reattach_engine_ha_data_to_thd接口。

相关实践学习
基于CentOS快速搭建LAMP环境
本教程介绍如何搭建LAMP环境,其中LAMP分别代表Linux、Apache、MySQL和PHP。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助 &nbsp; &nbsp; 相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
相关文章
|
1月前
|
存储 JSON 关系型数据库
《MySQL 简易速速上手小册》第9章:高级 MySQL 特性和技巧(2024 最新版)
《MySQL 简易速速上手小册》第9章:高级 MySQL 特性和技巧(2024 最新版)
43 1
|
1月前
|
SQL 关系型数据库 MySQL
MySQL8.0索引新特性
MySQL8.0索引新特性
20 0
|
2天前
|
SQL 关系型数据库 MySQL
MySQL数据库基础练习系列8、成绩录入与分析系统
MySQL数据库基础练习系列8、成绩录入与分析系统
9 1
|
3天前
|
SQL JSON 关系型数据库
MySQL 8.0新特性?
【6月更文挑战第14天】MySQL 8.0新特性?
13 1
|
3天前
|
存储 关系型数据库 MySQL
【MySQL技术内幕】2.6-InnoDB关键特性
【MySQL技术内幕】2.6-InnoDB关键特性
12 0
|
4天前
|
SQL 关系型数据库 MySQL
基于Hive的天气情况大数据分析系统(通过hive进行大数据分析将分析的数据通过sqoop导入到mysql,通过Django基于mysql的数据做可视化)
基于Hive的天气情况大数据分析系统(通过hive进行大数据分析将分析的数据通过sqoop导入到mysql,通过Django基于mysql的数据做可视化)
|
8天前
|
关系型数据库 MySQL 数据库
MySQL 8.0 新特性之不可见主键
【6月更文挑战第9天】MySQL 8.0 引入了不可见主键特性,提供更灵活的数据库管理方式。不可见主键能减少业务逻辑干扰,提高数据安全性和隐私,同时在某些场景下更适用。示例展示了如何创建和使用不可见主键,但需要注意它可能带来的理解和调试难题。此特性增加了设计和管理数据库的选项,适用于对数据隐私有高要求的场景。随着技术发展,不断学习和探索新特性将提升数据库性能和功能。
32 9
|
10天前
|
SQL 安全 关系型数据库
MySQL数据库——事务-简介、事务操作、四大特性、并发事务问题、事务隔离级别
MySQL数据库——事务-简介、事务操作、四大特性、并发事务问题、事务隔离级别
15 1
|
12天前
|
关系型数据库 MySQL 分布式数据库
数据库专家带你体验PolarDB MySQL版 Serverless的极致弹性特性
作为数据库专家,我有幸带大家深入体验阿里巴巴自主研发的下一代关系型分布式云原生数据库——PolarDB MySQL版的Serverless极致弹性特性。在这个云原生和分布式技术飞速发展的时代,Pola
|
21天前
|
Oracle 关系型数据库 MySQL
【MySQL】事务四大特性ACID、并发事务问题、事务隔离级别
【MySQL】事务四大特性ACID、并发事务问题、事务隔离级别
38 4

推荐镜像

更多