Defragmentation support for partitioned InnoDB table #10

SunguckLee · 2014-11-24T06:22:31Z

Hi Rongrong and Speaphan.

I added some code for defragmentation of partitioned innodb table.
I want this code could be merged facebook version of mysql if there's no problem.

Really thanks for the nice features again.

Add defragmentation of partitioned innodb table to Facebook defragmentation feature.
You can specify some partition name for defragmentation with PARTITION phrase.
Without PARTITION phrase, InnoDB will defragment all partition of the table.
And running defragmentation on partition table with async_commit option, InnoDB will defragment all partitioned table in parallel (Not parallel threads, just one thread will defragment all indexes). Defragmentation of several indexes (at the same time) need a lot of disk reads and this cause the latency increasing of user query processing.

** Usage **

defragment specific partition and index

ALTER TABLE t1 DEFRAGMENT PARTITION (p0sp0, P1SP1) INDEX PRIMARY;

defragment specific partition without index

ALTER TABLE t1 DEFRAGMENT PARTITION (p0sp0, P1SP1);

defragment specific index without partition

ALTER TABLE t1 DEFRAGMENT INDEX ix_lname;

defragment whole partitioned table

ALTER TABLE t1 DEFRAGMENT;

defragment specific partition and index (async commit)

ALTER TABLE t1 DEFRAGMENT PARTITION (p0sp0, P1SP1) INDEX PRIMARY async_commit;

defragment specific partition without index (async commit)

ALTER TABLE t1 DEFRAGMENT PARTITION (p0sp0, P1SP1) async_commit;

defragment specific index without partition (async commit)

ALTER TABLE t1 DEFRAGMENT INDEX ix_lname async_commit;

defragment whole partitioned table (async commit)

ALTER TABLE t1 DEFRAGMENT async_commit;

Add defragmentation of partitioned innodb table to Facebook defragmentation feature. You can specify some partition name for defragmentation with PARTITION phrase. Without PARTITION phrase, InnoDB will defragment all partition of the table. And running defragmentation on partition table with async_commit option, InnoDB will defragment all partitioned table in parallel (Not parallel threads, just one thread will defragment all indexes). Defragmentation of several indexes (at the same time) need a lot of disk reads and this cause the latency increasing of user query processing. ** Usage ** ## defragment specific partition and index ALTER TABLE t1 DEFRAGMENT PARTITION (p0sp0, P1SP1) INDEX PRIMARY; ## defragment specific partition without index ALTER TABLE t1 DEFRAGMENT PARTITION (p0sp0, P1SP1); ## defragment specific index without partition ALTER TABLE t1 DEFRAGMENT INDEX ix_lname; ## defragment whole partitioned table ALTER TABLE t1 DEFRAGMENT; ## defragment specific partition and index (async commit) ALTER TABLE t1 DEFRAGMENT PARTITION (p0sp0, P1SP1) INDEX PRIMARY async_commit; ## defragment specific partition without index (async commit) ALTER TABLE t1 DEFRAGMENT PARTITION (p0sp0, P1SP1) async_commit; ## defragment specific index without partition (async commit) ALTER TABLE t1 DEFRAGMENT INDEX ix_lname async_commit; ## defragment whole partitioned table (async commit) ALTER TABLE t1 DEFRAGMENT async_commit;

facebook-github-bot · 2014-11-24T06:24:42Z

Thank you for your pull request and welcome to our community. We require contributors to sign our Contributor License Agreement, and we don't seem to have you on file. In order for us to review and merge your code, please sign up at https://code.facebook.com/cla - and if you have received this in error or have any questions, please drop us a line at [email protected]. Thanks!

SunguckLee · 2014-11-24T09:46:36Z

Hi, Facebook.

I signed up the Contributor License Agreement of Facebook.

Thanks.

facebook-github-bot · 2014-11-24T09:54:15Z

Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Facebook open source project. Thanks!

RDBSE_KEYDEF::pk_part_no was allocated with the wrong number of elements.

Summary: Fix issue #10 (super read only does not prevent DROP TRIGGER) - add super read only handling to mysql_create_and_drop_trigger; - tweak error message in trans_begin to note whether regular or super read only is effective; - add MTR tests for the above changes and for multi-table update which was implemented but not covered in MTR. Test Plan: Jenkins mysqltest.sh sys_vars.super_read_only_basic mysqltest.sh --release sys_vars.super_read_only_basic mysqltest.sh --asan sys_vars.super_read_only_basic mysqltest.sh --valgrind sys_vars.super_read_only_basic Reviewers: chip, tianx Reviewed By: tianx

Summary: Add defragmentation of partitioned innodb table to Facebook defragmentation feature. You can specify some partition name for defragmentation with PARTITION phrase. Without PARTITION phrase, InnoDB will defragment all partition of the table. And running defragmentation on partition table with async_commit option, InnoDB will defragment all partitioned table in parallel (Not parallel threads, just one thread will defragment all indexes). Defragmentation of several indexes (at the same time) need a lot of disk reads and this cause the latency increasing of user query processing. ** Usage ** ALTER TABLE t1 DEFRAGMENT PARTITION (p0sp0, P1SP1) INDEX PRIMARY; ALTER TABLE t1 DEFRAGMENT PARTITION (p0sp0, P1SP1); ALTER TABLE t1 DEFRAGMENT INDEX ix_lname; ALTER TABLE t1 DEFRAGMENT; ALTER TABLE t1 DEFRAGMENT PARTITION (p0sp0, P1SP1) INDEX PRIMARY async_commit; ALTER TABLE t1 DEFRAGMENT PARTITION (p0sp0, P1SP1) async_commit; ALTER TABLE t1 DEFRAGMENT INDEX ix_lname async_commit; ALTER TABLE t1 DEFRAGMENT async_commit; This was contributed as: #10 Test Plan: TBA Reviewers: steaphan, over, pengt Reviewed By: pengt

Summary: Feature: Super Read-Only This was contributed by: Laurynas Biveinis <[email protected]> Fix for issue #10 (super read only does not prevent DROP TRIGGER). - add super read only handling to mysql_create_and_drop_trigger; - tweak error message in trans_begin to note whether regular or super read only is effective; - add MTR tests for the above changes and for multi-table update which was implemented but not covered in MTR. I will squash this commit, in future branches, with: https://reviews.facebook.net/D16197 Test Plan: mtr sys_vars.super_read_only_basic I will run the automated tests on this diff now. Reviewers: inaam-rana, liang.guo.752, pivanof Reviewed By: pivanof Subscribers: jtolmer Differential Revision: https://reviews.facebook.net/D30309

Summary: Add defragmentation of partitioned innodb table to Facebook defragmentation feature. You can specify some partition name for defragmentation with PARTITION phrase. Without PARTITION phrase, InnoDB will defragment all partition of the table. And running defragmentation on partition table with async_commit option, InnoDB will defragment all partitioned table in parallel (Not parallel threads, just one thread will defragment all indexes). Defragmentation of several indexes (at the same time) need a lot of disk reads and this cause the latency increasing of user query processing. ** Usage ** ALTER TABLE t1 DEFRAGMENT PARTITION (p0sp0, P1SP1) INDEX PRIMARY; ALTER TABLE t1 DEFRAGMENT PARTITION (p0sp0, P1SP1); ALTER TABLE t1 DEFRAGMENT INDEX ix_lname; ALTER TABLE t1 DEFRAGMENT; ALTER TABLE t1 DEFRAGMENT PARTITION (p0sp0, P1SP1) INDEX PRIMARY async_commit; ALTER TABLE t1 DEFRAGMENT PARTITION (p0sp0, P1SP1) async_commit; ALTER TABLE t1 DEFRAGMENT INDEX ix_lname async_commit; ALTER TABLE t1 DEFRAGMENT async_commit; This was contributed as: #10 Test Plan: TBA Reviewers: steaphan, over, pengt Reviewed By: pengt

rongrong · 2015-01-16T22:57:02Z

Your change has been merged into our repo: 8238e95. Thanks for your contribution!

Summary: Add defragmentation of partitioned innodb table to Facebook defragmentation feature. You can specify some partition name for defragmentation with PARTITION phrase. Without PARTITION phrase, InnoDB will defragment all partition of the table. And running defragmentation on partition table with async_commit option, InnoDB will defragment all partitioned table in parallel (Not parallel threads, just one thread will defragment all indexes). Defragmentation of several indexes (at the same time) need a lot of disk reads and this cause the latency increasing of user query processing. ** Usage ** ALTER TABLE t1 DEFRAGMENT PARTITION (p0sp0, P1SP1) INDEX PRIMARY; ALTER TABLE t1 DEFRAGMENT PARTITION (p0sp0, P1SP1); ALTER TABLE t1 DEFRAGMENT INDEX ix_lname; ALTER TABLE t1 DEFRAGMENT; ALTER TABLE t1 DEFRAGMENT PARTITION (p0sp0, P1SP1) INDEX PRIMARY async_commit; ALTER TABLE t1 DEFRAGMENT PARTITION (p0sp0, P1SP1) async_commit; ALTER TABLE t1 DEFRAGMENT INDEX ix_lname async_commit; ALTER TABLE t1 DEFRAGMENT async_commit; This was contributed as: #10 Test Plan: TBA Reviewers: steaphan, over, pengt Reviewed By: pengt

RDBSE_KEYDEF::pk_part_no was allocated with the wrong number of elements.

Summary: Add defragmentation of partitioned innodb table to Facebook defragmentation feature. You can specify some partition name for defragmentation with PARTITION phrase. Without PARTITION phrase, InnoDB will defragment all partition of the table. And running defragmentation on partition table with async_commit option, InnoDB will defragment all partitioned table in parallel (Not parallel threads, just one thread will defragment all indexes). Defragmentation of several indexes (at the same time) need a lot of disk reads and this cause the latency increasing of user query processing. ** Usage ** ALTER TABLE t1 DEFRAGMENT PARTITION (p0sp0, P1SP1) INDEX PRIMARY; ALTER TABLE t1 DEFRAGMENT PARTITION (p0sp0, P1SP1); ALTER TABLE t1 DEFRAGMENT INDEX ix_lname; ALTER TABLE t1 DEFRAGMENT; ALTER TABLE t1 DEFRAGMENT PARTITION (p0sp0, P1SP1) INDEX PRIMARY async_commit; ALTER TABLE t1 DEFRAGMENT PARTITION (p0sp0, P1SP1) async_commit; ALTER TABLE t1 DEFRAGMENT INDEX ix_lname async_commit; ALTER TABLE t1 DEFRAGMENT async_commit; This was contributed as: #10 Test Plan: TBA Reviewers: steaphan, over, pengt Reviewed By: pengt

RDBSE_KEYDEF::pk_part_no was allocated with the wrong number of elements.

Summary: Add defragmentation of partitioned innodb table to Facebook defragmentation feature. You can specify some partition name for defragmentation with PARTITION phrase. Without PARTITION phrase, InnoDB will defragment all partition of the table. And running defragmentation on partition table with async_commit option, InnoDB will defragment all partitioned table in parallel (Not parallel threads, just one thread will defragment all indexes). Defragmentation of several indexes (at the same time) need a lot of disk reads and this cause the latency increasing of user query processing. ** Usage ** ALTER TABLE t1 DEFRAGMENT PARTITION (p0sp0, P1SP1) INDEX PRIMARY; ALTER TABLE t1 DEFRAGMENT PARTITION (p0sp0, P1SP1); ALTER TABLE t1 DEFRAGMENT INDEX ix_lname; ALTER TABLE t1 DEFRAGMENT; ALTER TABLE t1 DEFRAGMENT PARTITION (p0sp0, P1SP1) INDEX PRIMARY async_commit; ALTER TABLE t1 DEFRAGMENT PARTITION (p0sp0, P1SP1) async_commit; ALTER TABLE t1 DEFRAGMENT INDEX ix_lname async_commit; ALTER TABLE t1 DEFRAGMENT async_commit; This was contributed as: #10 Test Plan: TBA Reviewers: steaphan, over, pengt Reviewed By: pengt

RDBSE_KEYDEF::pk_part_no was allocated with the wrong number of elements.

Summary: Add defragmentation of partitioned innodb table to Facebook defragmentation feature. You can specify some partition name for defragmentation with PARTITION phrase. Without PARTITION phrase, InnoDB will defragment all partition of the table. And running defragmentation on partition table with async_commit option, InnoDB will defragment all partitioned table in parallel (Not parallel threads, just one thread will defragment all indexes). Defragmentation of several indexes (at the same time) need a lot of disk reads and this cause the latency increasing of user query processing. ** Usage ** ALTER TABLE t1 DEFRAGMENT PARTITION (p0sp0, P1SP1) INDEX PRIMARY; ALTER TABLE t1 DEFRAGMENT PARTITION (p0sp0, P1SP1); ALTER TABLE t1 DEFRAGMENT INDEX ix_lname; ALTER TABLE t1 DEFRAGMENT; ALTER TABLE t1 DEFRAGMENT PARTITION (p0sp0, P1SP1) INDEX PRIMARY async_commit; ALTER TABLE t1 DEFRAGMENT PARTITION (p0sp0, P1SP1) async_commit; ALTER TABLE t1 DEFRAGMENT INDEX ix_lname async_commit; ALTER TABLE t1 DEFRAGMENT async_commit; This was contributed as: facebook#10 Test Plan: TBA Reviewers: steaphan, over, pengt Reviewed By: pengt

RDBSE_KEYDEF::pk_part_no was allocated with the wrong number of elements.

Summary: add histogram for rpl_semi_sync_master_trx_wait. 8.0 porting notes: Keeps the same histogram status variables as before since these are already being read by various applications. We should eventually remove this. Reference Patch: facebook@d1a1394 Reference Patch: facebook@15333b2e6f9 Differential Revision: D21832889 ---------------------------------------------------------------------- Fix semi_sync histogram reporting Summary: Fix a porting bug with semi_sync histograms. Reviewed By: george-reynya Differential Revision: D40964563 ---------------------------------------------------------------------- Semisync histogram double free (facebook#1290) Summary: Avoid double free on latency histogram data Before this fix, rpl.rpl_semi_sync_alias test under ASan with ``` ================================================================= ==65389==ERROR: AddressSanitizer: heap-use-after-free on address 0x0001742e17d4 at pc 0x000107febaf0 bp 0x00016ea8f710 sp 0x00016ea8f708 READ of size 4 at 0x0001742e17d4 thread T80 #0 0x107febaec in my_free(void*) my_malloc.cc:135 facebook#1 0x103cb9828 in free_latency_histogram_sysvars(SHOW_VAR*) mysqld.cc:4668 facebook#2 0x103cb99bc in prepare_latency_histogram_vars(latency_histogram*, SHOW_VAR*, unsigned long long*) mysqld.cc:4692 facebook#3 0x17c65826c in rpl_semi_sync_master_trx_wait_histogram(THD*, SHOW_VAR*, char*) semisync_source_plugin.cc:581 facebook#4 0x10be1b4cc in PFS_status_variable_cache::manifest(THD*, SHOW_VAR const*, System_status_var*, char const*, bool, bool) pfs_variable.cc:1366 facebook#5 0x10be1ba90 in PFS_status_variable_cache::do_materialize_all(THD*) pfs_variable.cc:1172 facebook#6 0x10c0ab33c in PFS_variable_cache<Status_variable>::materialize_all(THD*) pfs_variable.h:536 facebook#7 0x10c0ab294 in table_session_status::rnd_init(bool) table_session_status.cc:111 facebook#8 0x10bceb790 in ha_perfschema::rnd_init(bool) ha_perfschema.cc:1686 facebook#9 0x1033c7cec in handler::ha_rnd_init(bool) handler.cc:3157 facebook#10 0x103975380 in TableScanIterator::Init() basic_row_iterators.cc:230 facebook#11 0x103a33a18 in FilterIterator::Init() composite_iterators.h:82 facebook#12 0x103982ec0 in MaterializeIterator::MaterializeQueryBlock(MaterializeIterator::QueryBlock const&, unsigned long long*) composite_iterators.cc:845 facebook#13 0x103981410 in MaterializeIterator::Init() composite_iterators.cc:660 facebook#14 0x1049fc518 in Query_expression::ExecuteIteratorQuery(THD*) sql_union.cc:1293 facebook#15 0x1049fd358 in Query_expression::execute(THD*) sql_union.cc:1355 facebook#16 0x1047ae7ac in Sql_cmd_dml::execute_inner(THD*) sql_select.cc:870 facebook#17 0x1047ac344 in Sql_cmd_dml::execute(THD*) sql_select.cc:618 facebook#18 0x1047ffcc8 in Sql_cmd_show::execute(THD*) sql_show.cc:232 facebook#19 0x10480ab58 in Sql_cmd_show_status::execute(THD*) sql_show.cc:894 facebook#20 0x1045cea6c in mysql_execute_command(THD*, bool, unsigned long long*) sql_parse.cc:5323 facebook#21 0x1045c5dcc in dispatch_sql_command(THD*, Parser_state*, unsigned long long*) sql_parse.cc:6093 facebook#22 0x1045bb92c in dispatch_command(THD*, COM_DATA const*, enum_server_command) sql_parse.cc:2444 facebook#23 0x1045c06f8 in do_command(THD*) sql_parse.cc:1636 facebook#24 0x104cc4cc4 in handle_connection(void*) connection_handler_per_thread.cc:307 facebook#25 0x10bd130d4 in pfs_spawn_thread(void*) pfs.cc:2983 facebook#26 0x18ad47fa4 in _pthread_start+0x90 (libsystem_pthread.dylib:arm64e+0x6fa4) facebook#27 0x18ad42d9c in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d9c) 0x0001742e17d4 is located 4 bytes inside of 40-byte region [0x0001742e17d0,0x0001742e17f8) freed by thread T80 here: #0 0x139ff6de4 in wrap_free+0x98 (libclang_rt.asan_osx_dynamic.dylib:arm64e+0x3ede4) facebook#1 0x107febcfc in my_raw_free(void*) my_malloc.cc:269 facebook#2 0x107feba48 in my_free(void*) my_malloc.cc:141 facebook#3 0x103cb9828 in free_latency_histogram_sysvars(SHOW_VAR*) mysqld.cc:4668 facebook#4 0x17c6231e8 in ReplSemiSyncMaster::~ReplSemiSyncMaster() semisync_source.cc:517 facebook#5 0x17c623488 in ReplSemiSyncMaster::~ReplSemiSyncMaster() semisync_source.cc:516 facebook#6 0x17c651484 in semi_sync_master_plugin_deinit(void*) semisync_source_plugin.cc:833 facebook#7 0x10467aa90 in plugin_deinitialize(st_plugin_int*, bool) sql_plugin.cc:1123 facebook#8 0x1046730b0 in reap_plugins() sql_plugin.cc:1192 facebook#9 0x1046863b4 in mysql_uninstall_plugin(THD*, MYSQL_LEX_CSTRING) sql_plugin.cc:2602 facebook#10 0x104685374 in Sql_cmd_uninstall_plugin::execute(THD*) sql_plugin.cc:3731 facebook#11 0x1045cea6c in mysql_execute_command(THD*, bool, unsigned long long*) sql_parse.cc:5323 facebook#12 0x1045c5dcc in dispatch_sql_command(THD*, Parser_state*, unsigned long long*) sql_parse.cc:6093 facebook#13 0x1045bb92c in dispatch_command(THD*, COM_DATA const*, enum_server_command) sql_parse.cc:2444 facebook#14 0x1045c06f8 in do_command(THD*) sql_parse.cc:1636 facebook#15 0x104cc4cc4 in handle_connection(void*) connection_handler_per_thread.cc:307 facebook#16 0x10bd130d4 in pfs_spawn_thread(void*) pfs.cc:2983 facebook#17 0x18ad47fa4 in _pthread_start+0x90 (libsystem_pthread.dylib:arm64e+0x6fa4) facebook#18 0x18ad42d9c in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d9c) ``` It seems that the double invocation of `free_latency_histogram_sysvars` is correct in this case, thus protect against the double free with resetting the pointers to nullptr. Pull Request resolved: facebook#1290 Reviewed By: sunshine-Chun Differential Revision: D45277600 Pulled By: hermanlee

Summary: [Porting Notes] We want to dump raft logs to vanilla async replicas regardless of whether it's the relay log or binlog. Effectively after this change we'll dump relay logs on the followers and binlogs on the leader. When the raft role changes, the logs to the dumped are also changed. Dump_log class is introduced as a thin wrapper/continer around mysql_bin_log or rli->relay_log and is inited with mysql_bin_log to emulate vanilla mysql behavior. Dump threads use the global dump_log object instead of mysql_bin_log directly. We switch the log in dump log only when raft role changes (in binlog_change_to_binlog() and binlog_change_to_apply_log()). During raft role change we take all log releated locks (LOCK_log, LOCK_index, LOCK_binlog_end_pos, and dump log lock) to serialize it with other log operations like dumping logs. Related doc - https://fb.quip.com/oTVAAdgEi4zY This diff contains below 7 patches: D23013977 D24766787 D24716539 D24900223 D24955284 D25174166 D25775525 Reviewed By: luqun Differential Revision: D26141496 ------------------------------------------------------------------------------- Passing raw_log pointer to wait_with_heartbeat() and wait_without_heartbeat() Summary: When enable_raft_plugin is OFF Dump_log::lock() is a no-op. Which means that when enable_raft_plugin is OFF there can be a race between log switching and dump threads. This could lead to a scenario where the raw_log that wait_next_event() is working on might be different than what wait_with_heartbeat()/wait_without_heartbeat() is working on. This can cause deadlocks because wait_with_heartbeat()/wait_without_heartbeat()'s mysql_cond_wait would unlock and then lock a different log's LOCK_binlog_end_pos mutex which would then never be unlocked by wait_next_event(). Reviewed By: anirbanr-fb Differential Revision: D32152658 ----------------------------------------------------------------------------------------- Fix rpl_raft_dump_raft_logs Summary: This tests completes but fails because the following warning exists: ``` 2022-08-30T16:28:00.159525Z 11 [ERROR] [MY-013114] [Repl] Slave I/O for channel '': Got fatal error 1236 from master when reading data from binary log: 'Slave has more GTIDs than the master has, using the master's SERVER_UUID. This may indicate that the end of the binary log was truncated or that the last binary log file was lost, e.g., after a power or disk failure when sync_binlog != 1. The master may or may not have rolled back transactions that were already replicated to the slave. Suggest to replicate any transactions that master has rolled back from slave to master, and/or commit empty transactions on master to account for transactions that have been', Error_code: MY-013114 ``` Since the MTR result file is valid, we can suppress this error. Reviewed By: yichenshen Differential Revision: D39141846 ------------------------------------------------------------------------------- Fix heap overflow in group_relay_log_name handling Summary: We were accessing group_relay_log_name in Query_log_event::do_apply_event_worker() but it's assigned only after the coordinator thread encounters an end event (i.e. xid event or a query event with "COMMIT" or "ROLLBACK" query). This was causing a race between accessing group_relay_log_name in the worker thread and writing it on the coordinator thread. We don't need to set transaction position in events other than end event, so now we set transaction position in query event only if it's an end event. The race is eliminated because group_relay_log_name is set before enqueuing the event to the worker thread (in both dep repl and vanilla mts). Reviewed By: lth Differential Revision: D28767430 ------------------------------------------------------------------------------- fix memory during MYSQL_BIN_LOG::open_existing_binlog Summary: asandebug complain there are memory leaks during MYSQL_BIN_LOG open Direct leak of 50 byte(s) in 1 object(s) allocated from: #0 0x67460ef in malloc #1 0x93f0777 in my_raw_malloc(unsigned long, int) #2 0x93f064a in my_malloc(unsigned int, unsigned long, int) facebook#3 0x93f0eb0 in my_strdup(unsigned int, char const*, int) facebook#4 0x8af01a6 in MYSQL_BIN_LOG::open(unsigned int, char const*, char const*, unsigned int) facebook#5 0x8af8064 in MYSQL_BIN_LOG::open_binlog(char const*, char const*, unsigned long, bool, bool, bool, Format_description_log_event*, unsigned int, RaftRotateInfo*, bool) facebook#6 0x8b00c00 in MYSQL_BIN_LOG::new_file_impl(bool, Format_description_log_event*, RaftRotateInfo*) facebook#7 0x8d65e47 in rotate_relay_log(Master_info*, bool, bool, bool, RaftRotateInfo*) facebook#8 0x8d661c0 in rotate_relay_log_for_raft(RaftRotateInfo*) facebook#9 0x8c7696a in process_raft_queue facebook#10 0xa0fa1fd in pfs_spawn_thread(void*) facebook#11 0x7f8c9a12b20b in start_thread release these memory before assign them Reviewed By: Pushapgl Differential Revision: D28819752

Summary: add histogram for rpl_semi_sync_master_trx_wait. 8.0 porting notes: Keeps the same histogram status variables as before since these are already being read by various applications. We should eventually remove this. Reference Patch: facebook@d1a1394 Reference Patch: facebook@15333b2e6f9 Differential Revision: D21832889 ---------------------------------------------------------------------- Fix semi_sync histogram reporting Summary: Fix a porting bug with semi_sync histograms. Reviewed By: george-reynya Differential Revision: D40964563 ---------------------------------------------------------------------- Semisync histogram double free (facebook#1290) Summary: Avoid double free on latency histogram data Before this fix, rpl.rpl_semi_sync_alias test under ASan with ``` ================================================================= ==65389==ERROR: AddressSanitizer: heap-use-after-free on address 0x0001742e17d4 at pc 0x000107febaf0 bp 0x00016ea8f710 sp 0x00016ea8f708 READ of size 4 at 0x0001742e17d4 thread T80 #0 0x107febaec in my_free(void*) my_malloc.cc:135 facebook#1 0x103cb9828 in free_latency_histogram_sysvars(SHOW_VAR*) mysqld.cc:4668 facebook#2 0x103cb99bc in prepare_latency_histogram_vars(latency_histogram*, SHOW_VAR*, unsigned long long*) mysqld.cc:4692 facebook#3 0x17c65826c in rpl_semi_sync_master_trx_wait_histogram(THD*, SHOW_VAR*, char*) semisync_source_plugin.cc:581 facebook#4 0x10be1b4cc in PFS_status_variable_cache::manifest(THD*, SHOW_VAR const*, System_status_var*, char const*, bool, bool) pfs_variable.cc:1366 facebook#5 0x10be1ba90 in PFS_status_variable_cache::do_materialize_all(THD*) pfs_variable.cc:1172 facebook#6 0x10c0ab33c in PFS_variable_cache<Status_variable>::materialize_all(THD*) pfs_variable.h:536 facebook#7 0x10c0ab294 in table_session_status::rnd_init(bool) table_session_status.cc:111 facebook#8 0x10bceb790 in ha_perfschema::rnd_init(bool) ha_perfschema.cc:1686 facebook#9 0x1033c7cec in handler::ha_rnd_init(bool) handler.cc:3157 facebook#10 0x103975380 in TableScanIterator::Init() basic_row_iterators.cc:230 facebook#11 0x103a33a18 in FilterIterator::Init() composite_iterators.h:82 facebook#12 0x103982ec0 in MaterializeIterator::MaterializeQueryBlock(MaterializeIterator::QueryBlock const&, unsigned long long*) composite_iterators.cc:845 facebook#13 0x103981410 in MaterializeIterator::Init() composite_iterators.cc:660 facebook#14 0x1049fc518 in Query_expression::ExecuteIteratorQuery(THD*) sql_union.cc:1293 facebook#15 0x1049fd358 in Query_expression::execute(THD*) sql_union.cc:1355 facebook#16 0x1047ae7ac in Sql_cmd_dml::execute_inner(THD*) sql_select.cc:870 facebook#17 0x1047ac344 in Sql_cmd_dml::execute(THD*) sql_select.cc:618 facebook#18 0x1047ffcc8 in Sql_cmd_show::execute(THD*) sql_show.cc:232 facebook#19 0x10480ab58 in Sql_cmd_show_status::execute(THD*) sql_show.cc:894 facebook#20 0x1045cea6c in mysql_execute_command(THD*, bool, unsigned long long*) sql_parse.cc:5323 facebook#21 0x1045c5dcc in dispatch_sql_command(THD*, Parser_state*, unsigned long long*) sql_parse.cc:6093 facebook#22 0x1045bb92c in dispatch_command(THD*, COM_DATA const*, enum_server_command) sql_parse.cc:2444 facebook#23 0x1045c06f8 in do_command(THD*) sql_parse.cc:1636 facebook#24 0x104cc4cc4 in handle_connection(void*) connection_handler_per_thread.cc:307 facebook#25 0x10bd130d4 in pfs_spawn_thread(void*) pfs.cc:2983 facebook#26 0x18ad47fa4 in _pthread_start+0x90 (libsystem_pthread.dylib:arm64e+0x6fa4) facebook#27 0x18ad42d9c in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d9c) 0x0001742e17d4 is located 4 bytes inside of 40-byte region [0x0001742e17d0,0x0001742e17f8) freed by thread T80 here: #0 0x139ff6de4 in wrap_free+0x98 (libclang_rt.asan_osx_dynamic.dylib:arm64e+0x3ede4) facebook#1 0x107febcfc in my_raw_free(void*) my_malloc.cc:269 facebook#2 0x107feba48 in my_free(void*) my_malloc.cc:141 facebook#3 0x103cb9828 in free_latency_histogram_sysvars(SHOW_VAR*) mysqld.cc:4668 facebook#4 0x17c6231e8 in ReplSemiSyncMaster::~ReplSemiSyncMaster() semisync_source.cc:517 facebook#5 0x17c623488 in ReplSemiSyncMaster::~ReplSemiSyncMaster() semisync_source.cc:516 facebook#6 0x17c651484 in semi_sync_master_plugin_deinit(void*) semisync_source_plugin.cc:833 facebook#7 0x10467aa90 in plugin_deinitialize(st_plugin_int*, bool) sql_plugin.cc:1123 facebook#8 0x1046730b0 in reap_plugins() sql_plugin.cc:1192 facebook#9 0x1046863b4 in mysql_uninstall_plugin(THD*, MYSQL_LEX_CSTRING) sql_plugin.cc:2602 facebook#10 0x104685374 in Sql_cmd_uninstall_plugin::execute(THD*) sql_plugin.cc:3731 facebook#11 0x1045cea6c in mysql_execute_command(THD*, bool, unsigned long long*) sql_parse.cc:5323 facebook#12 0x1045c5dcc in dispatch_sql_command(THD*, Parser_state*, unsigned long long*) sql_parse.cc:6093 facebook#13 0x1045bb92c in dispatch_command(THD*, COM_DATA const*, enum_server_command) sql_parse.cc:2444 facebook#14 0x1045c06f8 in do_command(THD*) sql_parse.cc:1636 facebook#15 0x104cc4cc4 in handle_connection(void*) connection_handler_per_thread.cc:307 facebook#16 0x10bd130d4 in pfs_spawn_thread(void*) pfs.cc:2983 facebook#17 0x18ad47fa4 in _pthread_start+0x90 (libsystem_pthread.dylib:arm64e+0x6fa4) facebook#18 0x18ad42d9c in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d9c) ``` It seems that the double invocation of `free_latency_histogram_sysvars` is correct in this case, thus protect against the double free with resetting the pointers to nullptr. Pull Request resolved: facebook#1290 Reviewed By: sunshine-Chun Differential Revision: D45277600 Pulled By: hermanlee

Summary: [Porting Notes] We want to dump raft logs to vanilla async replicas regardless of whether it's the relay log or binlog. Effectively after this change we'll dump relay logs on the followers and binlogs on the leader. When the raft role changes, the logs to the dumped are also changed. Dump_log class is introduced as a thin wrapper/continer around mysql_bin_log or rli->relay_log and is inited with mysql_bin_log to emulate vanilla mysql behavior. Dump threads use the global dump_log object instead of mysql_bin_log directly. We switch the log in dump log only when raft role changes (in binlog_change_to_binlog() and binlog_change_to_apply_log()). During raft role change we take all log releated locks (LOCK_log, LOCK_index, LOCK_binlog_end_pos, and dump log lock) to serialize it with other log operations like dumping logs. Related doc - https://fb.quip.com/oTVAAdgEi4zY This diff contains below 7 patches: D23013977 D24766787 D24716539 D24900223 D24955284 D25174166 D25775525 Reviewed By: luqun Differential Revision: D26141496 ------------------------------------------------------------------------------- Passing raw_log pointer to wait_with_heartbeat() and wait_without_heartbeat() Summary: When enable_raft_plugin is OFF Dump_log::lock() is a no-op. Which means that when enable_raft_plugin is OFF there can be a race between log switching and dump threads. This could lead to a scenario where the raw_log that wait_next_event() is working on might be different than what wait_with_heartbeat()/wait_without_heartbeat() is working on. This can cause deadlocks because wait_with_heartbeat()/wait_without_heartbeat()'s mysql_cond_wait would unlock and then lock a different log's LOCK_binlog_end_pos mutex which would then never be unlocked by wait_next_event(). Reviewed By: anirbanr-fb Differential Revision: D32152658 ----------------------------------------------------------------------------------------- Fix rpl_raft_dump_raft_logs Summary: This tests completes but fails because the following warning exists: ``` 2022-08-30T16:28:00.159525Z 11 [ERROR] [MY-013114] [Repl] Slave I/O for channel '': Got fatal error 1236 from master when reading data from binary log: 'Slave has more GTIDs than the master has, using the master's SERVER_UUID. This may indicate that the end of the binary log was truncated or that the last binary log file was lost, e.g., after a power or disk failure when sync_binlog != 1. The master may or may not have rolled back transactions that were already replicated to the slave. Suggest to replicate any transactions that master has rolled back from slave to master, and/or commit empty transactions on master to account for transactions that have been', Error_code: MY-013114 ``` Since the MTR result file is valid, we can suppress this error. Reviewed By: yichenshen Differential Revision: D39141846 ------------------------------------------------------------------------------- Fix heap overflow in group_relay_log_name handling Summary: We were accessing group_relay_log_name in Query_log_event::do_apply_event_worker() but it's assigned only after the coordinator thread encounters an end event (i.e. xid event or a query event with "COMMIT" or "ROLLBACK" query). This was causing a race between accessing group_relay_log_name in the worker thread and writing it on the coordinator thread. We don't need to set transaction position in events other than end event, so now we set transaction position in query event only if it's an end event. The race is eliminated because group_relay_log_name is set before enqueuing the event to the worker thread (in both dep repl and vanilla mts). Reviewed By: lth Differential Revision: D28767430 ------------------------------------------------------------------------------- fix memory during MYSQL_BIN_LOG::open_existing_binlog Summary: asandebug complain there are memory leaks during MYSQL_BIN_LOG open Direct leak of 50 byte(s) in 1 object(s) allocated from: #0 0x67460ef in malloc #1 0x93f0777 in my_raw_malloc(unsigned long, int) #2 0x93f064a in my_malloc(unsigned int, unsigned long, int) facebook#3 0x93f0eb0 in my_strdup(unsigned int, char const*, int) facebook#4 0x8af01a6 in MYSQL_BIN_LOG::open(unsigned int, char const*, char const*, unsigned int) facebook#5 0x8af8064 in MYSQL_BIN_LOG::open_binlog(char const*, char const*, unsigned long, bool, bool, bool, Format_description_log_event*, unsigned int, RaftRotateInfo*, bool) facebook#6 0x8b00c00 in MYSQL_BIN_LOG::new_file_impl(bool, Format_description_log_event*, RaftRotateInfo*) facebook#7 0x8d65e47 in rotate_relay_log(Master_info*, bool, bool, bool, RaftRotateInfo*) facebook#8 0x8d661c0 in rotate_relay_log_for_raft(RaftRotateInfo*) facebook#9 0x8c7696a in process_raft_queue facebook#10 0xa0fa1fd in pfs_spawn_thread(void*) facebook#11 0x7f8c9a12b20b in start_thread release these memory before assign them Reviewed By: Pushapgl Differential Revision: D28819752

Summary: After bumping the thread stack size to 10MB for ASAN, this test started failing because the Bison parser ran out of stack before the thread did. This test deliberately tries to cause a thread stack overflow by generating an arbitrarily deeply nested SQL query to exercise the `check_stack_overrun` logic. Because our thread stack is so large in ASAN, we hit the Bison "stack" instead first. From the error log: ``` CURRENT_TEST: main.execution_constants mysqltest: At line 42: Query '$query_head 0 $query_tail' failed with wrong error 3950: 'Out of memory', should have failed with any of '0,1436' errors. ``` Parser OOM Stack: ``` (lldb) bt * thread #42, name = 'connection', stop reason = breakpoint 1.1 * frame #0: 0x000000000a33ea53 mysqld`my_error(nr=<unavailable>, MyFlags=<unavailable>) at my_error.cc:217:3 frame #1: 0x0000000008065a21 mysqld`MYSQLerror(location=<unavailable>, thd=<unavailable>, (null)=<unavailable>, s=<unavailable>) (.__uniq.242601085889238811981650692569837157750) at sql_yacc.yy:302:5 [artificial] frame #2: 0x0000000008034304 mysqld`MYSQLparse(YYTHD=<unavailable>, parse_tree=<unavailable>) at sql_yacc.cc:25323:9 frame #3: 0x0000000008009085 mysqld`THD::sql_parser(this=<unavailable>) at sql_class.cc:3811:7 frame #4: 0x00000000082b1f4c mysqld`parse_sql(thd=0x0000628000300100, parser_state=<unavailable>, creation_ctx=<unavailable>) at sql_parse.cc:7963:34 frame #5: 0x00000000082a060d mysqld`dispatch_sql_command(thd=<unavailable>, parser_state=<unavailable>, last_timer=<unavailable>) at sql_parse.cc:5993:11 frame #6: 0x000000000829bd7b mysqld`dispatch_command(thd=<unavailable>, com_data=<unavailable>, command=<unavailable>) at sql_parse.cc:2445:7 frame #7: 0x000000000829e5e9 mysqld`do_command(thd=<unavailable>) at sql_parse.cc:1636:18 frame #8: 0x00000000086c5e34 mysqld`handle_connection(arg=0x00006030001e0940) (.__uniq.188644437719200549207133117087266310382) at connection_handler_per_thread.cc:307:13 frame #9: 0x000000000b3e123b mysqld`pfs_spawn_thread(arg=0x000061600044f4a0) (.__uniq.322994040891040637281203315118403052672) at pfs.cc:2983:3 frame #10: 0x00007ffff7c9abaf libc.so.6`start_thread(arg=<unavailable>) at pthread_create.c:434:8 frame #11: 0x00007ffff7d2d17c libc.so.6`__clone3 at clone3.S:81 ``` sql/sql_yacc.yy: ``` static void MYSQLerror(YYLTYPE *location, THD *thd, Parse_tree_root **, const char *s) { if (strcmp(s, "syntax error") == 0) { thd->syntax_error_at(*location); } else if (strcmp(s, "memory exhausted") == 0) { my_error(ER_DA_OOM, MYF(0)); ... ``` mysql-fork/_build-8.0-ASanDebug/sql/sql_yacc.cc: ``` yyoverflow (YY_("memory exhausted"), &yyss1, yysize * YYSIZEOF (*yyssp), &yyvs1, yysize * YYSIZEOF (*yyvsp), &yyls1, yysize * YYSIZEOF (*yylsp), &yystacksize); ``` Differential Revision: D51233935 fbshipit-source-id: 04391603e7baef0c6e6fa4f308de0aad545474c2

Summary: add histogram for rpl_semi_sync_master_trx_wait. 8.0 porting notes: Keeps the same histogram status variables as before since these are already being read by various applications. We should eventually remove this. Reference Patch: facebook@d1a1394 Reference Patch: facebook@15333b2e6f9 Differential Revision: D21832889 ---------------------------------------------------------------------- Fix semi_sync histogram reporting Summary: Fix a porting bug with semi_sync histograms. Reviewed By: george-reynya Differential Revision: D40964563 ---------------------------------------------------------------------- Semisync histogram double free (facebook#1290) Summary: Avoid double free on latency histogram data Before this fix, rpl.rpl_semi_sync_alias test under ASan with ``` ================================================================= ==65389==ERROR: AddressSanitizer: heap-use-after-free on address 0x0001742e17d4 at pc 0x000107febaf0 bp 0x00016ea8f710 sp 0x00016ea8f708 READ of size 4 at 0x0001742e17d4 thread T80 #0 0x107febaec in my_free(void*) my_malloc.cc:135 facebook#1 0x103cb9828 in free_latency_histogram_sysvars(SHOW_VAR*) mysqld.cc:4668 facebook#2 0x103cb99bc in prepare_latency_histogram_vars(latency_histogram*, SHOW_VAR*, unsigned long long*) mysqld.cc:4692 facebook#3 0x17c65826c in rpl_semi_sync_master_trx_wait_histogram(THD*, SHOW_VAR*, char*) semisync_source_plugin.cc:581 facebook#4 0x10be1b4cc in PFS_status_variable_cache::manifest(THD*, SHOW_VAR const*, System_status_var*, char const*, bool, bool) pfs_variable.cc:1366 facebook#5 0x10be1ba90 in PFS_status_variable_cache::do_materialize_all(THD*) pfs_variable.cc:1172 facebook#6 0x10c0ab33c in PFS_variable_cache<Status_variable>::materialize_all(THD*) pfs_variable.h:536 facebook#7 0x10c0ab294 in table_session_status::rnd_init(bool) table_session_status.cc:111 facebook#8 0x10bceb790 in ha_perfschema::rnd_init(bool) ha_perfschema.cc:1686 facebook#9 0x1033c7cec in handler::ha_rnd_init(bool) handler.cc:3157 facebook#10 0x103975380 in TableScanIterator::Init() basic_row_iterators.cc:230 facebook#11 0x103a33a18 in FilterIterator::Init() composite_iterators.h:82 facebook#12 0x103982ec0 in MaterializeIterator::MaterializeQueryBlock(MaterializeIterator::QueryBlock const&, unsigned long long*) composite_iterators.cc:845 facebook#13 0x103981410 in MaterializeIterator::Init() composite_iterators.cc:660 facebook#14 0x1049fc518 in Query_expression::ExecuteIteratorQuery(THD*) sql_union.cc:1293 facebook#15 0x1049fd358 in Query_expression::execute(THD*) sql_union.cc:1355 facebook#16 0x1047ae7ac in Sql_cmd_dml::execute_inner(THD*) sql_select.cc:870 facebook#17 0x1047ac344 in Sql_cmd_dml::execute(THD*) sql_select.cc:618 facebook#18 0x1047ffcc8 in Sql_cmd_show::execute(THD*) sql_show.cc:232 facebook#19 0x10480ab58 in Sql_cmd_show_status::execute(THD*) sql_show.cc:894 facebook#20 0x1045cea6c in mysql_execute_command(THD*, bool, unsigned long long*) sql_parse.cc:5323 facebook#21 0x1045c5dcc in dispatch_sql_command(THD*, Parser_state*, unsigned long long*) sql_parse.cc:6093 facebook#22 0x1045bb92c in dispatch_command(THD*, COM_DATA const*, enum_server_command) sql_parse.cc:2444 facebook#23 0x1045c06f8 in do_command(THD*) sql_parse.cc:1636 facebook#24 0x104cc4cc4 in handle_connection(void*) connection_handler_per_thread.cc:307 facebook#25 0x10bd130d4 in pfs_spawn_thread(void*) pfs.cc:2983 facebook#26 0x18ad47fa4 in _pthread_start+0x90 (libsystem_pthread.dylib:arm64e+0x6fa4) facebook#27 0x18ad42d9c in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d9c) 0x0001742e17d4 is located 4 bytes inside of 40-byte region [0x0001742e17d0,0x0001742e17f8) freed by thread T80 here: #0 0x139ff6de4 in wrap_free+0x98 (libclang_rt.asan_osx_dynamic.dylib:arm64e+0x3ede4) facebook#1 0x107febcfc in my_raw_free(void*) my_malloc.cc:269 facebook#2 0x107feba48 in my_free(void*) my_malloc.cc:141 facebook#3 0x103cb9828 in free_latency_histogram_sysvars(SHOW_VAR*) mysqld.cc:4668 facebook#4 0x17c6231e8 in ReplSemiSyncMaster::~ReplSemiSyncMaster() semisync_source.cc:517 facebook#5 0x17c623488 in ReplSemiSyncMaster::~ReplSemiSyncMaster() semisync_source.cc:516 facebook#6 0x17c651484 in semi_sync_master_plugin_deinit(void*) semisync_source_plugin.cc:833 facebook#7 0x10467aa90 in plugin_deinitialize(st_plugin_int*, bool) sql_plugin.cc:1123 facebook#8 0x1046730b0 in reap_plugins() sql_plugin.cc:1192 facebook#9 0x1046863b4 in mysql_uninstall_plugin(THD*, MYSQL_LEX_CSTRING) sql_plugin.cc:2602 facebook#10 0x104685374 in Sql_cmd_uninstall_plugin::execute(THD*) sql_plugin.cc:3731 facebook#11 0x1045cea6c in mysql_execute_command(THD*, bool, unsigned long long*) sql_parse.cc:5323 facebook#12 0x1045c5dcc in dispatch_sql_command(THD*, Parser_state*, unsigned long long*) sql_parse.cc:6093 facebook#13 0x1045bb92c in dispatch_command(THD*, COM_DATA const*, enum_server_command) sql_parse.cc:2444 facebook#14 0x1045c06f8 in do_command(THD*) sql_parse.cc:1636 facebook#15 0x104cc4cc4 in handle_connection(void*) connection_handler_per_thread.cc:307 facebook#16 0x10bd130d4 in pfs_spawn_thread(void*) pfs.cc:2983 facebook#17 0x18ad47fa4 in _pthread_start+0x90 (libsystem_pthread.dylib:arm64e+0x6fa4) facebook#18 0x18ad42d9c in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d9c) ``` It seems that the double invocation of `free_latency_histogram_sysvars` is correct in this case, thus protect against the double free with resetting the pointers to nullptr. Pull Request resolved: facebook#1290 Reviewed By: sunshine-Chun Differential Revision: D45277600 Pulled By: hermanlee

jonahcohen referenced this pull request in MySQLOnRocksDB/mysql-5.6 Dec 19, 2014

Fix issue #10: Segfault in RDBSE_KEYDEF::get_primary_key_tuple

096314e

RDBSE_KEYDEF::pk_part_no was allocated with the wrong number of elements.

rongrong closed this Jan 16, 2015

hermanlee pushed a commit that referenced this pull request Sep 14, 2015

Fix issue #10: Segfault in RDBSE_KEYDEF::get_primary_key_tuple

d6a0735

RDBSE_KEYDEF::pk_part_no was allocated with the wrong number of elements.

mariadb-DanielLee mentioned this pull request Nov 27, 2015

mysqld some times crashes at the end of Random Query Generator test #111

Closed

This was referenced Dec 8, 2015

MyRocks slave crashed because of the wrong errkey. #120

Closed

mysqld crashed when running a RQG transactions test, not reproducible at will #123

Closed

This was referenced Dec 28, 2015

handle_fatal_signal (sig=11) in thd_ha_data #129

Closed

Assertion `v->cfd_->internal_comparator().Compare(start, end) <= 0' failed. #131

Closed

spetrunia added a commit that referenced this pull request Jan 5, 2016

Fix issue #10: Segfault in RDBSE_KEYDEF::get_primary_key_tuple

2a032aa

RDBSE_KEYDEF::pk_part_no was allocated with the wrong number of elements.

rameshvs02 mentioned this pull request Feb 18, 2016

InnoDB: Failing assertion: no_trx || parent_trx->is_primary in file ha_innodb.cc line 11527 #170

Closed

mariadb-DanielLee mentioned this pull request Apr 28, 2016

RQG test failed with a core dump #237

Closed

RickPizzi mentioned this pull request Oct 21, 2016

MyRocks: 1 hour stall in DelayWrite() during bulk load #348

Closed

spetrunia mentioned this pull request Nov 16, 2016

rocksdb.bulk_load test times out #428

Closed

alxyang mentioned this pull request Jan 23, 2017

Flush memtable and compact L0 files for read only workloads #427

Open

hermanlee pushed a commit that referenced this pull request Jan 31, 2017

Fix issue #10: Segfault in RDBSE_KEYDEF::get_primary_key_tuple

ddef429

RDBSE_KEYDEF::pk_part_no was allocated with the wrong number of elements.

VitaliyLi pushed a commit to VitaliyLi/mysql-5.6 that referenced this pull request Feb 9, 2017

Fix issue facebook#10: Segfault in RDBSE_KEYDEF::get_primary_key_tuple

a6f1d9f

RDBSE_KEYDEF::pk_part_no was allocated with the wrong number of elements.

hermanlee mentioned this pull request Aug 23, 2024

Implement LAST_INSERT_IDS function #1469

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Defragmentation support for partitioned InnoDB table #10

Defragmentation support for partitioned InnoDB table #10

SunguckLee commented Nov 24, 2014

facebook-github-bot commented Nov 24, 2014

SunguckLee commented Nov 24, 2014

facebook-github-bot commented Nov 24, 2014

rongrong commented Jan 16, 2015

Defragmentation support for partitioned InnoDB table #10

Defragmentation support for partitioned InnoDB table #10

Conversation

SunguckLee commented Nov 24, 2014

defragment specific partition and index

defragment specific partition without index

defragment specific index without partition

defragment whole partitioned table

defragment specific partition and index (async commit)

defragment specific partition without index (async commit)

defragment specific index without partition (async commit)

defragment whole partitioned table (async commit)

facebook-github-bot commented Nov 24, 2014

SunguckLee commented Nov 24, 2014

facebook-github-bot commented Nov 24, 2014

rongrong commented Jan 16, 2015