This is the first version of the SR speedup feature for MariaDB 10.7. #195
Conversation
| * adding all fragments in the streaming log table for the given | ||
| * transaction. | ||
| */ | ||
| virtual int set_fragments_from_table() = 0; |
There was a problem hiding this comment.
This method is never called from wsrep-lib side, so it does not have to be in the service interface.
There was a problem hiding this comment.
Yes, set_fragments_from_table() method is not unused and hence not needed in wsrep-lib. I will remove it, as you suggested.
| * Return the binlog cache for the currently executing | ||
| * transaction or a NULL pointer if no such cache exists. | ||
| */ | ||
| virtual void *get_binlog_cache() = 0; |
There was a problem hiding this comment.
This method exists only to pass the void pointer as argument for one of the service interface calls. This could be handled on MariaDB side, by storing the binlog cache pointer or client session THD pointer when constructing Wsrep_storage_service object.
| size_t fragment_size_; | ||
| size_t unit_counter_; | ||
| size_t log_position_; | ||
| int sr_store_; |
There was a problem hiding this comment.
This variable could perhaps be moved into storage_service implementation on MariaDB side.
There was a problem hiding this comment.
It can not be moved to Wsrep_storage_service on the MariaDB side because the lifetime of a Wsrep_storage_service object is too short: the sr_store value should have the same lifetime as the transaction, but on the master an Wsrep_storage_service object exists only for the duration of the append_fragment() call that adds a fragment to the fragment table. In addition to this, on the slave side the Wsrep_storage_service objects are not used at all for SR transactions.
But maybe there is some other class on the MariaDB side where sr_store could be moved.
| transaction. This describes the relationship of this WSREP | ||
| transaction and the underlying InnoDB transaction. | ||
| */ | ||
| enum sr_state |
There was a problem hiding this comment.
SR state handling could perhaps be moved to MariaDB side.
There was a problem hiding this comment.
Here we have the same question as above with sr_store. We need to find a suitable place on the MariaDB side with a lifetime that is the same as the lifetime of the transaction.
This the second attempt at this PR.