Re: [Maria-developers] [Commits] af15686: MDEV-16242: MyRocks: parallel slave on a table without PK can stop with ER_KEY_NOT_FOUND
psergey@askmonty.org (Sergei Petrunia) writes:
MDEV-16242: MyRocks: parallel slave on a table without PK can stop with ER_KEY_NOT_FOUND
DRAFT: If RBR event applier uses a secondary key or a full table scan to locate a row, force waiting for prior commit to complete.
I think if you wait_for_prior_commit() also for secondary key case, you should definitely restrict it to be only for conservative parallel replication, not for optimistic/agressive. Using a secondary key seems generally fine (as opposed to full table scan), and this problem should affect only conservative mode, no need to penalise optimistic/aggressive. (But maybe that is what is meant with "DRAFT"). - Kristian.
Hi Kristian, On Thu, Jul 05, 2018 at 05:11:44PM +0200, Kristian Nielsen wrote:
psergey@askmonty.org (Sergei Petrunia) writes:
MDEV-16242: MyRocks: parallel slave on a table without PK can stop with ER_KEY_NOT_FOUND
DRAFT: If RBR event applier uses a secondary key or a full table scan to locate a row, force waiting for prior commit to complete.
I think if you wait_for_prior_commit() also for secondary key case, you should definitely restrict it to be only for conservative parallel replication, not for optimistic/agressive. Using a secondary key seems generally fine (as opposed to full table scan), and this problem should affect only conservative mode, no need to penalise optimistic/aggressive.
(But maybe that is what is meant with "DRAFT").
Got it, thanks! (This patch is indeed only for testing as Elena is still seeing some failures and I wanted to rule them out). Btw, I also have figured that MyRocks wasn't making thd_rpl_deadlock_check() calls and added these: http://lists.askmonty.org/pipermail/commits/2018-June/012653.html http://lists.askmonty.org/pipermail/commits/2018-June/012652.html but I'm still in the process of trying to get the benchmark results for this. BR Sergei -- Sergei Petrunia, Software Developer MariaDB Corporation | Skype: sergefp | Blog: http://s.petrunia.net/blog
Sergey Petrunia <sergey@mariadb.com> writes:
Btw, I also have figured that MyRocks wasn't making thd_rpl_deadlock_check() calls and added these: http://lists.askmonty.org/pipermail/commits/2018-June/012653.html http://lists.askmonty.org/pipermail/commits/2018-June/012652.html but I'm still in the process of trying to get the benchmark results for this.
Yes, good to see that work is being done to get optimistic parallel replication support into myrocks. (From the outside, it seems needlessly complex to maintain a lock-free hash externally to rocksdb to map trxid->thd - surely there must be some memory structure associated with trxid where THD could live also, eg. just m_rocksdb_tx->GetTHD() instead of m_rocksdb_tx->GetID()? But I guess it is due to some kind of encapsulation requirement / RocksDB not wanting to expose access into internals). - Kristian.
participants (2)
-
Kristian Nielsen -
Sergey Petrunia