MariaDB Cluster (Master-Slave) Peformance on ARM

Majority of users use databases in cluster form (either master-slave or multi-master). I often get a question that if I have tried benchmarking MariaDB server in Master-Slave Setup on ARM and if yes then what is slave lag like. So this time I decided to study the same using the basic experiment focusing on slave lag.

Setup

Let’s first understand setup

  • Typical master-slave setup with a master and 2 replicating slaves.
    • Master handles only write-workload (sysbench update index).
    • Slaves handle read-workload (sysbench read only).
  • There are 2 independent experiments
    • Experiment-1: write-workload on master and read-workload on slave with slave actively replicating.
    • Experiment-2: only write workload on master and slave replication (no read-workload)
  • Server:
    • MariaDB-10.6 (10.6 post alpha - #9db14e9).
  • Master/Slave (Cost-Performance Model).
    • 16 vCPU ARM (Kunpeng 920 2.6 Ghz)
    • 10 vCPU x86 (Intel(R) Xeon(R) Gold 6151 CPU @ 3.00GHz)
  • Storage/OS:
    • NVME SSD with the same IOPS, CentOS-7.
  • Configuration details:


Benchmark and Analysis

read-write workload

benchmarking pattern

  • write-workload is executed on master and read-only workload on slaves (all workloads are executed in parallel so graph has overlap on timeline front).
  • increasing scalability from 1-128 threads. workload runs for 60 secs for each scalability and then 20 seconds of sleep.
  • script starts to monitor “seconds_behind_master (sbm)” immediately at the start of the workload and continue to monitor it till it drops to 0 and continue to remain so for sometime (to avoid false postive).


observations

  • arm continues to report higher tps and qps with growing scalability.
  • slaves from both variants start lagging with increased scalability but despite the higher throughput in arm case, lag is kept in check and both cases ends almost at same time.
  • this clearly suggests that the path for processing master-slave workload is equally efficient with arm and can easily handle increasing workloads keeping the critical parameters (like slave lag) under check.

write-only workload

benchmarking pattern

  • same as read-write just that there is no read-only workload only write workload active on master.


observations

  • arm continues to report higher tps with growing scalability.
  • second_behind_master continue to grow with the growing tps and scale linearly.
  • so even with a write-only workload, arm continues to keep the critical parameter in check.

Conclusion

Based on the experiment we can easily conclude that MariaDB Server master-slave setup continues to scale on arm (like standalone) without affecting critical parameters like scecond_behind_master. Since most of the users have master-slave kind of setup these findings should be very much comforting if you are considering moving to ARM.


If you have more questions/queries do let me know. Will try to answer them.




Written on May 4, 2021
All the product names, logo, trademarks and registered trademarks are property of their respective owners