This document compares various MySQL replication options including asynchronous replication, semi-synchronous replication, Schooner Active Cluster synchronous replication, Oracle GoldenGate, Tungsten Replicator, and Linux DRBD. It finds that asynchronous and semi-synchronous replication in MySQL 5.5.8 have limited sustainable performance and can result in premature sharding, while Schooner Active Cluster provides a 4-5x boost in sustainable replication performance through its tightly-integrated synchronous approach. The document also includes results from the DBT2 benchmark showing differences in throughput, response time, CPU and storage utilization, and network bandwidth across the different solutions.

1. MySQL replication alternatives: Pros and Cons Darpan Dinker VP Engineering Schooner Information Technology, Inc.http://www.schoonerinfotech.com/ Oracle, MySQL, Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.

2. MySQL/InnoDB Replication Replication for databases is critical High Availability: avoid SPOF, fail-over for service continuity, DR Scale-Out: scale reads on replicas Misc. administrative tasks: upgrades, schema changes, backup, PITR ... MySQL/InnoDB with base replication has serious gaps Failover is not straight-forward Possibility of data loss and data inconsistency Possibility of stale data read on Slaves Writes on Master need to be de-rated to Slave’s single-thread applier performance (forcing unnecessary sharding) Applications and deployments need to work around these issues or live with the consequences Several alternatives exist with different design considerations

3. Replication Options for MySQL/InnoDB on Commodity HW Qualitative Comparison Integrated Replication External Replication MySQL async Available in MySQL 5.1, 5.5 MySQL semi-sync Available in MySQL 5.5 Schooner sync Available in Schooner Active Cluster GoldenGate Tungsten DRBD Available on Linux

5. Master does not wait for Slave

6. Slave determines how much to read and from which point in the binary log

7. Slave can be arbitrarily behind master in reading and applying changes

8. Read on slave can give old data

9. No checksums in binary or relay log stored on disk, data corruption possible

10. Upon a Master’s failure

11. Slave may not have latest committed data resulting in data loss

13. Master does not wait for Slave

14. Slave determines how much to read and from which point in the binary log

15. Slave can be arbitrarily behind master in reading and applying changes

16. Read on slave can give old data

17. No checksums in binary or relay log stored on disk, data corruption possible

18. Upon a Master’s failure

19. Slave may not have latest committed data resulting in data loss

21. On commit, Master waits for an ACK from Slave

22. Slave logs the transaction event in relay log and ACKs (may not apply yet)

23. Slave can be arbitrarily behind master in applying changes

24. Read on slave can give old data

25. No checksums in binary or relay log stored on disk, data corruption possible

26. Upon a Master’s failure

28. On commit, Master waits for an ACK from Slave

29. Slave logs the transaction event in relay log and ACKs (may not apply yet)

30. Slave can be arbitrarily behind master in applying changes

31. Read on slave can give old data

32. No checksums in binary or relay log stored on disk, data corruption possible

33. Upon a Master’s failure

35. After commit, all Slaves guaranteed to receive and commit the change

36. Slave in lock-step with Master

37. Read on slave gives latest committed data

38. Checksums in log stored on disk

39. Upon a Master’s failure

40. Fail-over to a slave is fully integrated and automatic

41. Application writes continue on new master instantaneously

43. After commit, all Slaves guaranteed to receive and commit the change

44. Slave in lock-step with Master

45. Read on slave gives latest committed data

46. Checksums in log stored on disk

47. Upon a Master’s failure

48. Fail-over to a slave is fully integrated and automatic

49. Application writes continue on new master instantaneously

51. Master does not wait for Slave

52. Changes applied on slave similar to MySQL

53. Slave can be arbitrarily behind master in reading and applying changes

54. Read on slave can give old data

55. Heterogeneous Database support

56. Oracle, Microsoft SQL Server, IBM DB2, MySQLOracle and MySQL are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.

58. Master does not wait for Slave

59. Changes applied on slave similar to MySQL

60. Slave can be arbitrarily behind master in reading and applying changes

61. Read on slave can give old data

62. Heterogeneous Database support

63. Oracle, Microsoft SQL Server, IBM DB2, MySQLOracle and MySQL are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.

65. Master does not wait for Slave

66. Changes applied on slave similar to MySQL

67. Slave can be arbitrarily behind master in reading and applying changes

68. Read on slave can give old data*

69. Heterogeneous Database support

70. MySQL, PostgreSQL

71. Global Tx ID, useful to point to new master upon failure

72. SaaS & ISP feature: Parallel replication for multi-tenant MySQL databasesTungsten is a registered trademark of Continuent http://code.google.com/p/tungsten-replicator/

74. Master does not wait for Slave

75. Changes applied on slave similar to MySQL

76. Slave can be arbitrarily behind master in reading and applying changes

77. Read on slave can give old data*

78. Heterogeneous Database support

79. MySQL, PostgreSQL

80. Global Tx ID, useful to point to new master upon failure

81. SaaS & ISP feature: Parallel replication for multi-tenant MySQL databasesTungsten is a registered trademark of Continuent http://code.google.com/p/tungsten-replicator/

83. After each commit, the Stand-by server is guaranteed to have identical blocks on device

84. Stand-by in lock-step with Master

85. Stand-by server does not service load

86. No data-loss

87. Upon a Master’s failure

88. MySQL is started on stand-by, database recovery takes ~minutes

89. Stand-by is made new Master

91. After each commit, the Stand-by server is guaranteed to have identical blocks on device

92. Stand-by in lock-step with Master

93. Stand-by server does not service load

94. No data-loss

95. Upon a Master’s failure

96. MySQL is started on stand-by, database recovery takes ~minutes

97. Stand-by is made new Master

99. On-line Transaction Processing (OLTP) performance test

100. Fair-usage implementation of the TPC-C benchmark

101. Simulates a wholesale parts supplier with a database containing inventory and customer information

102. Benchmark scale determined by number of warehouses

103. Results here based on a scale of 1000

104. Use InnoDB storage engine with 48GB buffer pool and full consistency/durability settings

106. CPU: 2x Intel Xeon X5670 processors, 6 cores/12 threads per processor, 2.93 GHz

107. DRAM: 72GB

108. HDD: 2x300GB 2.5” 10k RPM HDD RAID-1, with LSI M5015 controllerwith NVRAM writeback cache for logging

109. Flash: 8x200GB OCZ MLC SSDs with LSI 9211controller, md RAID-0

110. Network: 1x Chelsio 10Gb Ethernet NIC

112. Results: Master CPU Utilization Master CPU Utilization (%)

113. Results: Master CPU Utilization Master CPU Utilization (%) Higher throughput means higher CPU utilization, better system balance

114. Results: Transient Behavior on Master SAC 5.5 Async 5.5 Semi-sync Inconsistent performance with 5.5 Async

115. Results: Slave Utilization Slave CPU Utilization (%)

116. Results: Transient Behavior on Slave SAC 5.5 Async 5.5 Semi-sync Fluctuations with 5.5 Async

117. Results: Storage IO Utilization Master Storage IOPS Utilization (%)

118. Results: Storage IO Utilization Master Storage IOPS Utilization (%) Higher throughput means higher storage bandwidth, better system balance

119. Results: Network Utilization Replication Network Utilization (%) Replication Network Bandwidth (MB/s)

120. Results: Network Utilization Replication Network Utilization (%) Replication Network Bandwidth (MB/s) Higher throughput means higher replication bandwidth, better system balance

122. How the Replication Options Compare *Using external tools and scripts

123. Try it out!Schooner Active Cluster is available for a free trial.http://www.schoonerinfotech.com/free_trials Darpan Dinker darpan@schoonerinfotech.com Twitter: @darpandinker Schooner Information Technology, Inc.http://www.schoonerinfotech.com/