zoukankan      html  css  js  c++  java
  • MyRocks DDL原理

         最近一个日常实例在做DDL过程中,直接把数据库给干趴下了,问题还是比较严重的,于是赶紧排查问题,撸了下crash堆栈和alert日志,发现是在去除唯一约束的场景下,MyRocks存在一个严重的bug,于是紧急向官方提了一个bug。其实问题比较隐蔽,因为直接一条DDL语句,数据库是不会挂了,而是在特定情况下,并且对同一个索引操作多次才会发生,因此排查问题也费了一些时间,具体bug排查和复现过程不在此展开,有兴趣的童鞋可以直接看bug链接:https://github.com/facebook/mysql-5.6/issues/602。借着排查问题的机会,我梳理了MyRocks DDL的工作流程,下文主要包括3方面内容:MyRocks数据字典,DDL操作除了修改数据本身,很重要的一个工作是维护数据字典,第二部分是MyRocks DDL的流程,主要围绕增加/删除索引的场景展开,最后一部分是分析DDL异常处理逻辑。

    数据字典
        所谓数据字典,就是存储引擎元数据的地方。数据字典可以从两个维度来看,从用户角度来看,数据字典就是information_schema表中的
    RocksDB相关的表,主要包括ROCKSDB_DDL,ROCKSDB_INDEX_FILE_MAP等。而从RockDB内部实现角度来看,所有元数据都以KV对的方式存储在system column family中。我们看到的information_schema中表的信息,其实都是通过system column family中的元数据构造出来的,同时在mysqld启动时,也会构造一份元数据存储在内存中,方便快速检索查询。下面我会列出RocksDB数据字典的几种类型,并列出每种类型KV对的形式。
    // Data dictionary types

    enum DATA_DICT_TYPE {
    DDL_ENTRY_INDEX_START_NUMBER= 1, //表与索引映射关系
    INDEX_INFO= 2, //索引
    CF_DEFINITION= 3, //column family
    BINLOG_INFO_INDEX_NUMBER= 4,  //binlog位点信息
    DDL_DROP_INDEX_ONGOING= 5, //删除索引字典任务
    INDEX_STATISTICS= 6,  //索引统计信息
    MAX_INDEX_ID= 7,  //当前最大index_id
    DDL_CREATE_INDEX_ONGOING= 8, //添加索引字典任务
    END_DICT_INDEX_ID= 255 
    };

    1). DDL_ENTRY_INDEX_START_NUMBER
    表和索引之间的映射关系
    key: Rdb_key_def::DDL_ENTRY_INDEX_START_NUMBER(0x1) + dbname.tablename
    value: version + {global_index_id}*n_indexes_of_the_table

    2). INDEX_INFO
    索引id和索引属性的关系
    key: Rdb_key_def::INDEX_INFO(0x2) + global_index_id
    value: version, index_type, key_value_format_version

    index_type:主键/二级索引/隐式主键
    key_value_format_version: 记录存储格式的版本

    3). CF_DEFINITION
    column family属性
    key: Rdb_key_def::CF_DEFINITION(0x3) + cf_id
    value: version, {is_reverse_cf, is_auto_cf}

    is_reverse_cf: 是否是reverse column family
    is_auto_cf: column family名字是否是$per_index_cf,名字自动由table.indexname组成

    4). BINLOG_INFO_INDEX_NUMBER
    binlog位点及gtid信息,binlog_commit更新此信息
    key: Rdb_key_def::BINLOG_INFO_INDEX_NUMBER (0x4)
    value: version, {binlog_name,binlog_pos,binlog_gtid}

    5). DDL_DROP_INDEX_ONGOING
    删除的索引任务
    key: Rdb_key_def::DDL_DROP_INDEX_ONGOING(0x5) + global_index_id
    value: version

    6). INDEX_STATISTICS
    索引统计信息
    key: Rdb_key_def::INDEX_STATISTICS(0x6) + global_index_id
    value: version, {materialized PropertiesCollector::IndexStats}

    7). MAX_INDEX_ID
    当前的index_id,每次创建索引index_id都从这个获取和更新
    key: Rdb_key_def::CURRENT_MAX_INDEX_ID(0x7)
    value: version, current max index id

    8). DDL_CREATE_INDEX_ONGOING
    待创建的索引任务
    key: Rdb_key_def::DDL_CREATE_INDEX_ONGOING(0x8) + global_index_id
    value: version

    DDL流程
        RocksDB引擎并没有类似InnoDB引擎的增量row_log机制,因此MyRocks还不支持Online DDL,只是对部分DDL操作支持了inplace方式,从check_if_supported_inplace_alter接口实现可知,对于DROP_INDEX, DROP_UNIQUE_INDEX和ADD_INDEX这三个操作,可以通过inplace的方式完成DDL,inplace方式的优点就是不需要拷贝表,间接减少了锁表时间,其它操作都只能通过重建表的方式来实现。下面我以inplace的方式说明DDL的执行流程,copy方式相对会更简单一些。总的入口函数是mysql_inplace_alter_table,主要包含4个阶段。
    1).检查存储引擎是否支持inplace的DDL操作
    接口:ha_rocksdb::check_if_supported_inplace_alter
    MyRocks支持inplace方式操作类型是HA_ALTER_INPLACE_SHARED_LOCK_AFTER_PREPARE,意味着执行DDL过程中会堵塞写。
    2).准备阶段
    接口:ha_rocksdb::prepare_inplace_alter_table
    对于 RocksDB引擎来说,支持inplace方式主要是添加和删除索引,因此这个过程主要做的事情是搜集需要添加、删除的索引信息。涉及到数据字典操作具体入口函数是create_key_defs,最终调用create_key_def接口,每个索引对应一个Rdb_key_def对象。这里涉及到一个主要操作是为索引产生全局有序的index_id(ddl_manager.get_and_update_next_number)。

    3).执行阶段
    接口:ha_rocksdb::inplace_alter_table
    这里主要是添加二级索引操作,具体实现在inplace_populate_sk接口。主要包括两部分内容,更新数据字典和创建索引。
    a.更新数据字典
    数据字典维护通过最终通过接口start_ongoing_index_operation完成,为新建索引构造KV对,写入system column family。
    ,所有添加的索引的KV对会作为一个事务commit,表示一批待创建索引的任务。

    begin
    put-KV:(DDL_CREATE_INDEX_ONGOING,cf_id,index_id)->(DDL_CREATE_INDEX_ONGOING_VERSION)
    commit

    b.创建索引
    接下来就是真正创建索引的操作,通过遍历PK索引,构造出新增二级索引的格式记录,然后写入索引,主要实现接口在update_sk里。由于RockDB行锁实现中,每个key对应一把锁,并且锁对象不能复用,因此锁消耗的总内存与key大小和key数量相关,为了保证系统运行中内存可控,一般开启rocksdb_commit_in_the_middle避免大事务。因此这个这个过程也会触发是否提前提交事务的检查,主要实现接口在do_bulk_commit里面。

    4).提交或回滚阶段
    接口:commit_inplace_alter_table
    a.处理待删除的索引,最终通过接口start_ongoing_index_operation(drop)完成。
    b.对于新增索引,写入索引字典信息
    c.写入表和索引的映射关系
    对表进行alter操作后,会增一些索引,并删除一些索引,因此表对应的索引关系需要重建,主要实现接口在Rdb_tbl_def::put_dict里面。
    第1),2),3)涉及的字典操作整个作为一个事务提交。

    begin
    put-KV: (DDL_DROP_INDEX_ONGOING,cf_id,index_id)->(DDL_DROP_INDEX_ONGOING_VERSION)
    put-KV: (INDEX_INFO+cf_id+index_id)->INDEX_INFO_VERSION_VERIFY_KV_FORMAT+index_type+kv_version
    put-KV: (DDL_ENTRY_INDEX_START_NUMBER,dbname_tablename)->version + {key_entry, key_entry, key_entry, ... } ,key_entry --> (cf_id, index_nr)
    commit

    d.维护数据字典在内存中对象m_ddl_hash。
    主要工作是从hash表中摘掉老的tbl对象,写入新的tbl对象,主要实现接口在Rdb_ddl_manager::put里面。

    e.清理DDL_CREATE_INDEX_ONGOING标记。
    正常执行到这里,表示新建的索引已经成功执行,需要清理DDL_CREATE_INDEX_ONGOING标记。主要实现接口在finish_indexes_operation里面,最终调用end_ongoing_index_operation将之前加入的KV对进行删除动作。
    (DDL_CREATE_INDEX_ONGOING,cf_id,index_id)->(DDL_CREATE_INDEX_ONGOING_VERSION),并将整个操作作为一个事务commit。我们可以看到,整个过程已经执行完毕,但并没有看到哪里将删除的索引真正清理掉,RocksDB里面删除索引实质是一个异步的过程,真正删除索引的动作通过后台线程Rdb_drop_index_thread完成。所以,到这里会主动触发一次唤醒rdb_drop_idx_thread的动作,告知线程有活干了。

    Rdb_drop_index_thread工作流程
    1).获取待删除索引列表key=(DDL_DROP_INDEX_ONGOING)
    2).逐一遍历每个需要删除的索引,按照(index_id,index_id+1)key范围来删除记录
    3).并调用CompactRange触发合并
    4).通过index_id来查找key,若不存在index-id相同的key,则认为index已经被清理
    5).最后调用finish_indexes_operation(DDL_DROP_INDEX_ONGOING)清理待删除索引标记,并将索引字典信息从数据字典中删除,具体实现参考delete_index_info。

    begin
    delete-key: (DDL_DROP_INDEX_ONGOING,cf_id,index_id)
    delete-key: (INDEX_INFO+cf_id+index_id)
    batch-commit

    DDL异常处理
         从上述的实现来看,我们执行一个DDL操作,除了本身索引操作的事务,涉及数据字典的操作的事务也有好几个,所以整个DDL操作并不是一个原子操作。比如在执行阶段的第1步,字典相关的操作提交后,实例crash了,那么这些字典操作内容就残留在system Column family中了,但从业务角度来看,并不影响。上面介绍的mysql_inplace_alter_table包含了DDL的主要执行过程,实际上,在此之前还会通过mysql_prepare_alter_table创建临时表定义frm文件,(文件名一般以#sql开头),该文件包含了目标表的schema定义;并在DDL结束的时候,通过mysql_rename_table更新为目标表名.frm。如果在rename之前,实例crash了,就会导致frm文件的内容仍然是老版本,但RocksDB引擎字典已经更新。从表现形式来看,就会发现show create table xxx,显示的索引内容与information_schema.ROCKSDB_DDL的数据字典不一致。前面讨论的两种情况都是inplace方式带来的问题,对于copy方式,由于需要重建表,会将临时表#sqlxxx的信息写入数据字典,如果这个动作完成后,实例crash,会导致数据字典中残留有临时表的信息。mysqld重启时,会根据字典的信息检查表是否存在,主要通过接口validate_schemas实现,具体而言,通过数据字典中的表名查找对应的frm文件,并且查找过程中会忽略#开头的临时frm文件,因此会导致只要数据字典中包含了临时表的字典信息,则会导致mysqld启动失败,并报如下错误。

    error:
    [Warning] RocksDB: Schema mismatch - Table test.#sql-b54_1 is registered in RocksDB but does not have a .frm file
    [ERROR] RocksDB: Problems validating data dictionary against .frm files, exiting
    [ERROR] RocksDB: Failed to initialize DDL manager.

    如果想正常启动,可以临时通过参数rocksdb_validate_tables=2设置忽略这个错误,毕竟临时表的数据字典不影响业务表的使用。从我这里分析来看,目前DDL在异常处理这块还处理的不够好,根本原因还在于DDL不是一个原子操作,server层和引擎层的修改在某些情况下无法保持一致,导致问题出现。

    相关实现文件和接口
    storage/rocksdb/rdb_datadic.cc //数据字典相关代码
    storage/rocksdb/rdb_i_s.cc //information_schema相关代码
    myrocks::ha_rocksdb::inplace_populate_sk //更新二级索引
    Rdb_dict_manager::get_max_index_id //获取最大index_id
    ha_rocksdb::check_if_supported_inplace_alter //检查是否支持inplace
    myrocks::ha_rocksdb::create //copy方式建表接口
    myrocks::ha_rocksdb::create_key_def //建立key对象
    myrocks::Rdb_ddl_manager::get_and_update_next_number //获取下一个index_id
    Rdb_dict_manager::start_ongoing_index_operation //添加一个建立/删除索引的任务

     

  • 相关阅读:
    ftl总结
    关于button的自动刷新
    判断json格式中是否含有key
    main方法的参数
    开发笔记--java.lang.OutOfMemoryError: PermGen space异常处理
    C/C++混合编程
    MFC 模块状态的实现
    类的私有private构造函数 ,为什么要这样做
    MFC DLL 导出函数的定义方式
    关于 AfxGetStaticModuleState ()
  • 原文地址:https://www.cnblogs.com/cchust/p/6716823.html
Copyright © 2011-2022 走看看