myrocks之事务处理

前言

mysql目前支持的事务引擎有innodb,tokudb. rocksdb加入mysql阵营后,mysql支持的事务引擎增长至3个。
myrocks目前支持的事务隔离级别有read-committed和repeatable-read. 同innodb一样,myrocks也支持MVCC机制。
可以说,myrocks提供了很好的事务支持,能够满足的一般业务的事务需求。

sequence number

谈到rocksdb事务,就必须提及rocksdb中的sequence number机制。rocksdb中的每一条记录都有一个sequence number, 这个sequence number存储在记录的key中。

InternalKey: | User key (string) | sequence number (7 bytes) | value type (1 byte) |

对于同样的User key记录,在rocksdb中可能存在多条,但他们的sequence number不同。
sequence number是实现事务处理的关键,同时也是MVCC的基础。

snapshot

snapshot是rocksdb的快照信息,snapshot实际就是对应一个sequence number. 
简单的讲,假设snapshot的sequence number为Sa, 那么对于此snapshot来说,只能看到sequence number<=sa的记录,sequence number<=sa的记录是不可见的。

  • snapshot 结构
    snapshot 主要包含sequence number和snapshot创建时间,sequence number 取自当前的sequence number.
class SnapshotImpl : public Snapshot {
  SequenceNumber number_;  // sequenct number
  int64_t unix_time_;      // snapshow创建时间
  ......
};  
  • snapshot 管理
    snapshot由全局双向链表管理,根据sequence number排序。snapshot的创建和删除都需要维护双向链表。
  • snapshot与compact
    rocksdb的compact操作与snapshot有紧密联系。以我们熟悉的innodb为例,rocksdb的compact类似于innodb的purge操作, 而snapshot类似于InnoDB的read view. innodb做purge操作时会根据已有的read view来判断哪些undo log可以purge,而rocksdb的compact操作会根据已有snapshot信息即全局双向链表来判断哪些记录在compace时可以清理。

    判断的大体原则是,从全局双向链表取出最小的snapshot sequence number Sn. 如果已删除的老记录sequence number <=Sn, 那么这些老记录在compact时可以清理掉。

MVCC

有了snapshot,MVCC实现起来就很顺利了。记录的sequence number天然的提供了记录的多版本信息。
每次查询用户记录时,并不需要加锁。而是根据当前的sequence number Sn创建一个snapshot, 查询过程中只取小于或等于Sn的最大sequence number的记录。查询结束时释放snapshot.

关键代码段

DBIter::FindNextUserEntryInternal

 if (ikey.sequence <= sequence_) {
   if (skipping &&
      user_comparator_->Compare(ikey.user_key, saved_key_.GetKey()) <= 0) {
     num_skipped++;  // skip this entry
     PERF_COUNTER_ADD(internal_key_skipped_count, 1);
   } else {
     switch (ikey.type) {
       case kTypeDeletion:
       case kTypeSingleDeletion:
         // Arrange to skip all upcoming entries for this key since
         // they are hidden by this deletion.
         saved_key_.SetKey(
             ikey.user_key,
             !iter_->IsKeyPinned() || !pin_thru_lifetime_ /* copy */);
         skipping = true;
         num_skipped = 0;
         PERF_COUNTER_ADD(internal_delete_skipped_count, 1);
         break;
       case kTypeValue:
         valid_ = true;
         saved_key_.SetKey(
             ikey.user_key,
             !iter_->IsKeyPinned() || !pin_thru_lifetime_ /* copy */);
         return;
       case kTypeMerge:

       ......

隔离级别

隔离级别也是通过snapshot来实现的。在innodb中,隔离级别为read-committed时,事务中每的个stmt都会建立一个read view, 隔离级别为repeatable-read时,只在事务开启时建立一次read view. rocksdb同innodb类似,隔离级别为read-committed时,事务中每的个stmt都会建立一个snapshot, 隔离级别为repeatable-read时,只在事务开启时第一个stmt建立一次snapshot.

关键代码片段

rocksdb_commit:

  if (my_core::thd_tx_isolation(thd) <= ISO_READ_COMMITTED)
  {
    // For READ_COMMITTED, we release any existing snapshot so that we will
    // see any changes that occurred since the last statement.
    tx->release_snapshot();
  }
  • 隔离级别实现差异
    在read committed隔离级别下,如果一个大事务要更新1000w行,当它更新了前900w行时,
    同时另一个事务已经更新了后100w行,那么myrocks会重新获取快照,再次尝试更新,这样 更新的是新提交的数据,也符合read committed逻辑。具体的讨论可以参考最近的issue#340. 而之前的处理方式是直接报死锁错误。
rocksdb::Status ha_rocksdb::get_for_update(
    Rdb_transaction*             tx,
    rocksdb::ColumnFamilyHandle* column_family,
    const rocksdb::Slice&        key,
    std::string*                 value) const
{
  rocksdb::Status s= tx->get_for_update(column_family, key, value);

  // If we have a lock conflict and we are running in READ COMMITTTED mode
  // release and reacquire the snapshot and then retry the get_for_update().
  if (s.IsBusy() && my_core::thd_tx_isolation(ha_thd()) == ISO_READ_COMMITTED)
  {
    tx->release_snapshot();
    tx->acquire_snapshot(false);

    s= tx->get_for_update(column_family, key, value);
  }

  return s;
}

innodb不会出现上述情况,当第一个大事更新是会持有b树的index lock, 第二个事务会一直等待index lock直至第一个事务提交完成。

myrocks目前只支持一种锁类型:排他锁(X锁),并且所有的锁信息都保存在内存中。

  • 锁结构
    每个锁实际上存储的哪条记录被哪个事务锁住。
struct LockInfo {
  TransactionID txn_id;

  // Transaction locks are not valid after this time in us
  uint64_t expiration_time;
  ......
  }

每个锁实际是key和LockInfo的映射. 锁信息都保存在map中

struct LockMapStripe {
  std::unordered_map<std::string, LockInfo> keys;
  ......
}

为了减少全局锁信息访问的冲突, rocksdb将锁信息进行按key hash分区,

struct LockMap {
    std::vector<LockMapStripe*> lock_map_stripes_;
}

同时每个column family 存储一个这样的LockMap.

using LockMaps = std::unordered_map<uint32_t, std::shared_ptr<LockMap>>;
LockMaps lock_maps_;

锁相关参数:

max_num_locks:事务锁个数限制
expiration:事务过期时间

通过设置以上两个参数,来控制事务锁占用过多的内存。

  • 死锁检测

rocksdb内部实现了简单的死锁检测机制,每次加锁发生等待时都会向下面的map中插入一条等待信息,表示一个事务id等待另一个事务id.
同时会检查wait_txn_map_是否存在等待环路,存在环路则发生死锁。

std::unordered_map<TransactionID, TransactionID> wait_txn_map_;

死锁检测关键代码片段

TransactionLockMgr::IncrementWaiters:

    for (int i = 0; i < txn->GetDeadlockDetectDepth(); i++) {
      if (next == id) {
        DecrementWaitersImpl(txn, wait_id);
        return true;
      } else if (wait_txn_map_.count(next) == 0) {
        return false;
      } else {
        next = wait_txn_map_[next];
      }
    }

死锁检测相关参数

deadlock_detect:是否开启死锁检测
deadlock_detect_depth:死锁检查深度,默认50

  • gap lock

    innodb中是存在gap lock的,主要是为了实现repeatable read和唯一性检查的。
    而在rocksdb中,不支持gap lock(rocksdb insert是也会多对唯一键加锁,以防止重复插入,
    严格的来讲也算是gap lock).

    那么在rocksdb一些需要gap lock的地方,目前是报错和打印日志来处理的。

    相关参数
    gap_lock_write_log: 只打印日志,不返回错误
    gap_lock_raise_error: 打印日志并且返回错误

  • 锁示例

    直接看例子

binlog XA & 2pc

myrocks最近也支持了binlog xa.
在开启binlog的情况下,myrocks提交时,会经历两阶段提交阶段。
prepare阶段,根据server层生成的xid(由MySQLXid+server_id+qurey_id组成),在rockdb内部执行2pc操作,生成Prepare(xid),EndPrepare()记录。
commit阶段,根据事务成还是失败,生成Commit(xid)或Rollback(xid)记录。

rocksdb 2pc参考这里

总结

myrocks在事务处理方面还有些不完善的地方,比如锁类型只有单一的X锁,不支持gap lock,纯内存锁占用内存等。 myrocks社区正在持续改进中,一起期待。

时间: 2024-10-03 13:39:03

myrocks之事务处理的相关文章

myrocks记录格式分析

概况 rocksdb作为KV存储引擎,那么myrocks记录最终会以kv的形式存储在rocksdb中.MySQL中的表一般由若干索引组成, 在innodb存储引擎中,每个索引对应一颗B树,而在rocksdb存储引擎中,索引对应于rocksdb中一段连续范围的数据.具体来说,这个范围是此索引id和id+1之间的所有数据.如果表的所有索引都在一个column family, 那表的这些索引数据在物理上基本是连续的.可以参考之前文章中的图示 myrocks记录格式 myrocks以索引为单位,将表的所

数据库的事务处理---PDO实现

事务处理用一句简单的术语称为"原子操作",即一件事情,要么全部完成,要么一个也别完成:有一种一荣俱荣,一损俱损的感觉. 最常用的就是在交易过程中,比如在网络中,甲方付费给乙方,钱确认付款,但是乙方并未确认收款,那么,甲方的账户并不会减少,乙方的账户也并不会增加. 只有当甲方确认付款,乙方确认收款,两个步骤都完成,并且不出现错误的时候,双方的账户才会改变 看代码也许更好理解 1 <?php 2 try{ 3 $pdo=new PDO("mysql:host=localho

mysql 事务处理

知识点: 事务处理是什么? 当数据库表呈树状机构设计时,我们对一个表进行增.删.改的操作,可能会要求对另外的表进行相同的操作,为了保证这多个sql能同时执行成功,就要使用mysql的事务处理. 注意:只有增删改的操作可以进行回滚,alter等操作不可行! 事务特性: 1.原子性:所有的sql执行操作必须全部成功,否则则回滚到处理前状态 2.一致性: 确保数据库正确地改变状态后,成功提交的事务. 3.隔离性: 使事务操作彼此独立的和透明的. 4.持久性: 确保提交的事务的结果或效果的系统出现故障的

第一次接触终极事务处理——Hekaton

在这篇文章里,我想给出如何与终极事务处理(Extreme Transaction Processing (XTP) )的第一步接触,即大家熟知的Hakaton.如果你想对XTP有个很好的概况认识,我推荐Kalen Delaney写的关于它的白皮书,另外微软研究院也发布了题为“对于内存数据库的高性能并发控制机制(High-Performance Concurrency Control Mechanisms for Main-Memory Databases)”的研究白皮书,点此下载. 所有XTP维

JDBC的进化3--补充:事务处理

接着JDBC的进化3,我们来说数据库事务. 事务:一组逻辑操作单元,使数据从一种状态变换到另一种状态. 怎么理解呢? 一组逻辑单元:我认为指的是多条的DML操作,只是一条DML语句的话,对于mysql来说,执行完成功就自动提交了,没成功的话,就没成功喽,这样说来,一条DML语句就相当于一个原子,不可再分了. 从一种状态变换到另一种状态:即这组操作是成功了还是失败了,他们必须同时都成功,有一个失败,就退回到起点.例如银行的转账,不能一个成功,一个失败吧. 来看看JDBC的事务处理: 先来看看,在什

Redis缓存技术学习系列之事务处理

?在本系列的第一篇文章中,我们主要针对Redis中的"键"和"值"进行了学习.我们可以注意到,Redis是一个C/S架构的数据库,在我们目前的认知中,它是通过终端中的一条条命令来存储和读取的,即它是一个非常典型的"请求-响应"模型.可是我们知道在实际的应用中,我们要面对的或许是更为复杂的业务逻辑,因为Redis中不存在传统关系型数据库中表的概念,因此在使用Redis的过程中,我们要面对两个实际的问题,即如何更好的维护数据库中的"键&qu

MyRocks文档-Getting Started with MyRocks

Getting Started with MyRocks Download Facebook MySQL 5.6, then build from source 安装步骤,这都不会就不用往下做了,直接给连接https://github.com/facebook/mysql-5.6/wiki/Build-Steps Set up my.cnf 想要把RocksDB引擎给启动起来,你至需要把至少下面这一些参数给写到my.cnf文件里面去 [mysqld] rocksdb default-storag

MyRocks文档-Init

原文地址:https://github.com/facebook/mysql-5.6/wiki 因为最近要用到MyRocks,所以文档还是要看看的,翻译不对的地方大家多多指正,谢谢. [目录] Overview 2017-2-3 21:00:00 [Init...]

分布式系统的事务处理【转】

转:http://coolshell.cn/articles/10910.html 当我们在生产线上用一台服务器来提供数据服务的时候,我会遇到如下的两个问题: 1)一台服务器的性能不足以提供足够的能力服务于所有的网络请求. 2)我们总是害怕我们的这台服务器停机,造成服务不可用或是数据丢失. 于是我们不得不对我们的服务器进行扩展,加入更多的机器来分担性能上的问题,以及来解决单点故障问题. 通常,我们会通过两种手段来扩展我们的数据服务: 1)数据分区:就是把数据分块放在不同的服务器上(如:uid %