云原生数据库mysql对共享存储分布式文件系统的接口需求分析

1. 引言

  云原生数据库跟分布式mpp数据库是有差异的,虽然两者都是计算与存储分离,但是在资源的占用上有所不同。云原生数据库是shard everything架构,其依赖的存储资源、内存资源、事务资源在云中都是共享、弹性伸缩的。由分布式文件系统提供按需分配、租户隔离的块存储,由分布式内存池提供buffer pool占用的大块内存。分布式mpp数据库则是shard nothing架构,其依赖的存储资源、内存资源、事务资源是单个物理节点上的资源,在SQL计算层进行了分布式计算逻辑的分发。

  本文重点介绍共享存储,如果分布式文件系统的iops、每秒刷盘数能够比单个物理节点上的性能线性提升,那么云原生数据库mysqltps也会随之提升,而且mysql的原生SQL语法都是支持的,包括嵌套子查询、存储过程、函数等。分布式mppSQL计算层做分布式计算逻辑的分发,这些可能会被裁减掉。

  单机mysql的事务型存储引擎innodb的表空间数据存储依赖于单个linux节点的VFS提供的posix标准的文件操作接口。VFS作为各个具体文件系统(ext4xfsext3等)的抽象层,屏蔽了各个具体文件系统的实现差异,对应用层提供了统一、标准的posix文件操作接口。类似于阿里云的polardbpolarfs的依赖,其实polardb就是mysql的内核源码的二次开发而成的。本文重点罗列云原生数据库mysql在各个场景下对posix文件操作接口需求。

  分布式弹性文件系统要具体地实现这些接口,各个接口的语义要完全符合posix标准。并提供mount挂载的功能,将其实现的具体接口注册到VFS内部,mysql将表空间放置到挂载了分布式弹性文件系统的路径下,innodb内部对表空间文件操作时候,实际上就调用了分布式文件系统提供的文件操作的api

  innodb的表空间有用户表空间、系统表空间、Redo日志、Undo表空间。本文重点分析用户表空间对文件操作接口的需求,应该也涵盖了其余的表空间对文件操作接口的需求。

用户对用户表空间的操作主要有两类,一类是表空间数据的读写,另一类是表空间DDL操作,对应到posix标准的文件操作接口,一类是文件数据读写IO,另一类是文件的元数据操作。

 

 

 

2. 表空间数据的读写操作

 

2.1 同步IO

 

  同步IO会阻塞调用线程,直到IO完成,调用线程才返回,pwrite/pread函数是线程安全的同步IOlseek+read/write函数非线程安全,需要加互斥锁,并发量大的时候,对性能有一定的影响。以下几种场景下,会使用同步IO

 

场景一. linux不支持native aioPage cleaner线程刷脏,同步写

 

  从buffer pool中刷脏页时候,如果不支持native aio,则通过simulated aio模拟异步写进行dirty page的写入表空间操作,本质上是同步写

 

  调用栈

1 buf_flush_page_cleaner_worker → pc_flush_slot → buf_flush_do_batch →  buf_do_flush_list_batch → buf_flush_page_and_try_neighbors → buf_flush_try_neighbors → buf_flush_page  → buf_flush_write_block_low → fil_io(sync=false) → os_aio → os_aio_func →AIO::wake_simulated_handler_thread

 

场景二. 刷脏时,如果double write buffer写满,将double write buffer中数据写入系统表空间ibdata文件,同步写

  调用栈:

 

buf_flush_page → buf_dblwr_flush_buffered_writes → fil_io(sync=true) 

 

场景三. 事务buffer中数据写入Redo log file,同步写

  调用栈:

 

1 innobase_commit_low → trx_commit_for_mysql → trx_commit → trx_commit_in_memory → trx_flush_log_if_needed_low → log_write_up_to → log_group_write_buf → log_group_write_buf → fil_io(sync=true) 

 

场景四,用户线程触发的数据块请求读写,同步读写

  调用栈:

 

1 ha_innobase::index_read → row_search_mvcc →  row_sel_get_clust_rec_for_mysql→  buf_page_get_gen → buf_read_page → buf_read_page_low → fil_io(sync=true)

 

 

 

 

 

2.2异步IO

  异步IO不会阻塞调用线程,提交IO请求后,调用线程就返回,可以做其余的操作,后台线程会轮询IO的完成情况,如果执行完成可以调用相关的回调函数。

在支持native aio的情况下,innodb的后台 Page cleaner线程刷脏,预读走的就是异步IO流程,主要以下两个场景。

场景一. linux支持native aio Page cleaner线程刷脏,异步写

  从buffer pool中刷脏页时候,如果支持native aio,则通过 io_submit异步io接口进行dirty page的表空间写入操作。

1 buf_flush_page_cleaner_worker → pc_flush_slot → buf_flush_do_batch →  buf_do_flush_list_batch → buf_flush_page_and_try_neighbors → buf_flush_try_neighbors →buf_flush_page  → buf_flush_write_block_low → fil_io(sync=false)→ os_aio → os_aio_func → AIO::linux_dispatch  →  io_submit

 

场景二. 线性或者逻辑预读,异步读

 

逻辑预读调用栈:

 

1 ha_innobase::index_read → row_search_mvcc → row_sel_get_clust_rec_for_mysql → buf_page_get_gen → buf_read_ahead_random → fil_io(sync=false)

 

 

线性预读调用栈:

 

1 ha_innobase::index_read → row_search_mvcc → row_sel_get_clust_rec_for_mysql → buf_page_get_gen → buf_read_ahead_linear→ fil_io(sync=false)

2.3 刷盘

如果innodb_flush_method设置了O_DSYNC,日志文件(ib_logfileXXX)使用O_SYNC打开,因此写完数据不需要调用函数fsync刷盘,数据文件(ibd)使用default模式打开,因此写完数据需要调用fsync刷盘。

如果innodb_flush_method设置了fsync或者不设置,数据文件和日志文件都使用default模式打开,写完数据都需要使用fsync来刷盘。

如果innodb_flush_method设置了O_DIRECT,日志文件(ib_logfileXXX)使用default模式打开,写完数据需要调用fsync函数刷盘,数据文件(ibd)使用O_DIRECT模式打开,写完数据需要调用fsync刷盘。

如果innodb_flush_method设置为O_DIRECT_NO_FSYNC,文件打开方式与O_DIRECT模式类似,区别是,数据文件写完后,不调用fsync来刷盘,主要针对O_DIRECT能保证文件的元数据也落盘的FS

如果使用linux native aioinnodb_flush_method一定要配置成O_DIRECT,否则会退化成同步IO

 

3. 表空间DDL操作

 

 

3.1 create table

 

 

创建表时候调用,调用流程如下:

ha_innobase::create → dict_build_tablespace_for_table → fil_idb_create

依次依赖于 os_file_create os_file_flushos_file_set_sizeos_file_closeos_file_delete, 这些函数依次依赖于open fsynclseekcloseunlink posix文件标准接口。

 

3.1 drop table

删除表的时候调用,调用栈如下。

ha_innobase::delete_table → row_drop_table_for_mysql → row_drop_single_table_tablespace → fil_delete_tablespace → unlink

 

3.2 rename table

重命名表的时候调用,调用栈如下。

ha_innobase::rename_table → row_rename_table_for_mysql → row_rename_table_for_mysql → dict_table_rename_in_cache→ fil_rename_tablespace → rename

 

3.3 truncate table

截断表时候调用,默认表空间截留4page的大小。调用栈如下。

ha_innobase::truncate → row_truncate_table_for_mysql → row_truncate_complete → truncate_t::truncate → os_file_truncate_posix → ftruncate

 

3.4 extend  tablespace

innodb表空间文件大小是动态扩展的,如果表空间中的数据页不够,则需要对表空间文件进行预扩展,比如往聚集索引中大量插入数据的时候。调用栈如下

row_ins_clust_index_entry_low → btr_cur_pessimistic_insert → fsp_try_extend_data_file → fsp_try_extend_data_file → fil_space_extend → posix_fallocate

 

4.posix标准的文件操作接口列表

 

4.1 文件元数据操作

 

1 open(const char *__file, int __oflag, …)
2 close (int __fd);
3 rename (const char *__old, const char *__new)
4 fcntl(int __fd, int __cmd, ...)
5 unlink(const char *__name)
6 mkdir(const char *__path)
7 rmdir(const char *__path)
8 ftruncate(int __fd, __off64_t __length)
9 posix_fallocate(int __fd, __off64_t __offset,__off64_t __len)

 

 

 

4.2 同步IO接口

 

1 lseek(int __fd, __off64_t __offset, int __whence)
2 read(int __fd, void *__buf, size_t __nbytes)
3 write(int __fd, const void *__buf, size_t __n)
4 pread(int __fd, void *__buf, size_t __nbytes, __off64_t __offset)
5 pwrite(int __fd, const void *__buf, size_t __nbytes, __off64_t __offset)
6 fsync(int __fd)

 

 

4.3 异步IO接口

 

1 io_setup(int maxevents, io_context_t *ctxp);
2 io_destroy(io_context_t ctx);
3 io_submit(io_context_t ctx, long nr, struct iocb *ios[]);
4 io_cancel(io_context_t ctx, struct iocb *iocb, struct io_event *evt);
5 io_getevents(io_context_t ctx, long min_nr, long nr, struct io_event *events, struct timespec *timeout);

 

 

 

4.4 挂载

 

mount
umount

 

 

4.5 杂项

 

其余文件属性、权限类的操作,就不一一列举了。

 

本站资源均源自网络,若涉及您的版权、知识产权或其他利益,请附上版权证明邮件告知。收到您的邮件后,我们将在72小时内删除。
若下载资源地址错误或链接跳转错误请联系站长。站长q:770044133。

» 云原生数据库mysql对共享存储分布式文件系统的接口需求分析

发表评论

免登录下载网,提供全网最优质的资源集合!