[MDEV-13073] AliSQL: [Performance] Issue #40 Optimize performance of semisync Created: 2017-06-13  Updated: 2023-03-23  Resolved: 2018-03-27

Status: Closed
Project: MariaDB Server
Component/s: Replication
Fix Version/s: 10.3.5

Type: Task Priority: Major
Reporter: Sergey Vojtovich Assignee: Axel Schwenke
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Relates
relates to MDEV-15238 rpl.perf_buildin_semisync_issue40 spo... Closed
relates to MDEV-30269 Remove rpl_semi_sync_[master,slave] p... Closed
Epic Link: AliSQL patches
Sprint: 10.1.32, 10.3.6-1

 Description   

Description:
------------
This diff includes:
    1. Make semisync buidin to completely remove overhead of plugin lock.
    2. Remove LOCK_log requirement from dump thread
    3. Now user threads can wait for ACK before innodb commit.
        add rpl_semi_sync_master_wait_point to control this behavior(AFTER_COMMIT/AFTER_SYNC)
    4. Add a new ACK thread to handle ACK from slave.
    5. The IO thread flushs master info only when ACK is needed
        add rpl_semi_sync_slave_delay_master to control this behavior
    6. Fix bug#70669, if sync_binlog = 1 ,then notify dump thread after fsync of binlog file.

https://github.com/alibaba/AliSQL/commit/348783276913b0ad73d7a473498c0f8ea42ee9b0

This patch makes the variable rpl_semi_sync_slave obsolete, which is why it was removed.



 Comments   
Comment by Andrei Elkin [ 2017-11-29 ]

Axel, hallo.

The latest code patch is in `bb-10.2-semisync_ali` branch. Monty suggests to
have 1 and 2 slave separate runs. Also to compare against 5.7.
I am all ears should you have any question.

Cheers,

Andrei

Comment by Axel Schwenke [ 2018-01-23 ]

no idea why this is still assigned to me -> back to monty

Comment by Michael Widenius [ 2018-02-15 ]

This patch is already in 10.3 since November.

However, it needs to be benchmarked to ensure that we don't need to do any additional
work on it.

Comment by Axel Schwenke [ 2018-03-27 ]

I've rerun the benchmark for 10.3.5 and it is actually even faster than the branches I did before (probably due to latest InnoDB enhancements). Hence this can be shipped as is in 10.3.

# connection 03 -> bb-10.2-semisync_ali
# connection 07 -> bb-10.3-semisync
# connection 08 -> 10.3.5
 
# workload 01 -> OLTP(rw)
 
#thd    03      07      08
1       3938.6  3852.7  3869.5
2       7459.2  7261.3  7199.9
4       13119   12691   12879
8       25144   24791   24911
16      49818   48869   49342
32      96561   93955   94039
64      150180  142943  145888
128     170317  164725  164240
256     117872  115453  116282
 
# workload 02 -> insert
 
#thd    03      07      08
1       2758.2  2689.2  2589.0
2       4795.1  4714.3  4498.6
4       8233.8  8139.9  8078.8
8       15138   14820   14609
16      28524   28310   29013
32      47826   47659   49665
64      65291   63573   68569
128     66467   68718   70399
256     52182   55944   56501
 
# workload 03 -> index-update
 
#thd    03      07      08
1       2739.7  2625.6  2659.2
2       4715.1  4585.8  4478.5
4       8216.6  8207.0  7985.2
8       15207   15235   15387
16      30797   30867   31076
32      60730   60129   60990
64      96557   96185   97013
128     36013   109571  112897
256     36933   59615   46155
 
# workload 04 -> non-index-update
 
#thd    03      07      08
1       2628.6  2615.8  2633.5
2       4631.7  4559.3  4707.4
4       8132.6  8382.6  8563.9
8       15658   15538   15903
16      29896   29505   31163
32      51265   51247   58155
64      58164   58755   90635
128     57889   57987   90131
256     55673   55748   68406

Generated at Thu Feb 08 08:02:41 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.