at a glance, two more things where parallel replication slaves could be useful:
- multimaster replication where incoming streams are independent
- a lot of big BLOB operations
either way I think it's more important to provide a flexible interface for both
user and SE to decide on the parallelism rather than trying to handle the task
of determining possibilities for the parallelization strictly in replication
layer,
at least initially.
Thanks,
Michael
Kristian Nielsen wrote:
[email protected] writes:
Benchmarking did not show any significant benefit of having parallel applying.
Reason is that RBR applying is so fast compared to processing
of SQL queries that applying queue did not build up. It turned out that
several applier threads were useful only when transaction length was ~200 SQL
statements.
Sounds like you are testing a CPU bound load with all data in memory?
If you test against a disk-bound load with data spread out over multiple disk
drives, you would probably see a much higher benefit. A single-threaded
replication thread is not able to utilise the possibility to have multiple
outstanding I/O running in parallel on multiple disks.
- Kristian.
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
