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

1. 引言

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

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

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

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

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

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

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

2.1 同步IO

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

场景一. linux不支持native aio， Page cleaner线程刷脏，同步写

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

　　调用栈：

 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，同步写

　　调用栈：

 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) 

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

　　调用栈：

 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的表空间写入操作。

 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

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

逻辑预读调用栈：

 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)

线性预读调用栈：

 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 aio，innodb_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_flush、os_file_set_size、os_file_close、os_file_delete， 这些函数依次依赖于open\ fsync\lseek\close\unlink 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

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

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 文件元数据操作

 open(const char *__file, int __oflag, …)
 close (int __fd);
 rename (const char *__old, const char *__new)
 fcntl(int __fd, int __cmd, ...)
 unlink(const char *__name)
 mkdir(const char *__path)
 rmdir(const char *__path)
 ftruncate(int __fd, __off64_t __length)
 posix_fallocate(int __fd, __off64_t __offset,__off64_t __len)

4.2 同步IO接口

 lseek(int __fd, __off64_t __offset, int __whence)
 read(int __fd, void *__buf, size_t __nbytes)
 write(int __fd, const void *__buf, size_t __n)
 pread(int __fd, void *__buf, size_t __nbytes, __off64_t __offset)
 pwrite(int __fd, const void *__buf, size_t __nbytes, __off64_t __offset)
 fsync(int __fd)

4.3 异步IO接口

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

4.4 挂载

mount
umount

4.5 杂项

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