Introduction – Redundant and fault-tolerant database systems

Most of our customers are 24*7 internet properties and their applications ( i.e. entire business operations) rely heavily on availability of respective database systems nodes, These systems going unavailable cause serious impact on reputation, customer experience and revenue. To ensure business continuity under foreseeable and unforeseeable man-made or natural disasters, the database system has to be designed and built with fault tolerance and disaster recovery capabilities, in other words the component can be removed and the system should continue to operate as expected. High availability refers to the characteristics of a system that allow the system to sustain continuous operation in the event of hardware and software failures due to natural or man made causes (Webb, 2008).

How MySQL 8.0 Group Replication works ?

• MySQL Group Replication is a plugin (first released with MySQL 5.7 Server) which can provide virtually synchronous replication, with built-in conflict detection / handling and consistency guarantee, So the individual machines and/or MySQL instances can fail or be taken offline for maintenance while the distributed MySQL service continues to operate and handle application traffic.
• MySQL Group Replication is based on a Paxos implementation, which ensures that all servers receive the same set of data in the same order. There is a built-in group membership service that keeps the view of the group consistent and available for all servers at any given point in time. Servers can leave and join the group and the view is updated accordingly. Sometimes servers can leave the group unexpectedly, in which case the failure detection mechanism detects this and notifies the group that the view has changed. This is all automatic.
• In MySQL Group Replication, For a transaction to commit, the majority of the group have to agree on the order of a given transaction in the global sequence of transactions. Deciding to commit or abort a transaction is done by each server individually, but all servers make the same decision. If there is a network partition, resulting in a split where members are unable to reach agreement, then the system does not progress until this issue is resolved. Hence there is also a built-in, automatic, split-brain protection mechanism.

MySQL 8.0 Group Replication Limitations

• Maximum number of MySQL servers that can be the members of a single replication group is 9, Any further attempt made by adding more members will be refused. Functionally this appears very rational to us, Why add several MySQL instances to make the Group Replication infrastructure operationally complex ?
• If you are operating Group Replication in multi-primary mode, The SELECT … FOR UPDATE statements can cause a deadlock, This is because the lock is not shared across the members of the group, therefore the expectation for such a statement might not be reached.
• We cannot use  replication filters on Group Replication. Because, Filtering the transactions  on selected servers would make the group enabled  to reach agreement on consistent state. But, You can implement  replication filters on the replication channels that are not directly involved with  Group Replication

Handling Transaction Limit in MySQL Group Replication

• Configure group_replication_transaction_size_limit system variable to control maximum transaction size the group will tolerate, The default value is approximately 143 MB (150000000 bytes). The time taken to process a transaction is proportional to its size.
• Group Replication use compression algorithm LZ4 and it is enabled by default with threshold of 1000000 bytes (1 MB), You can tune this value by configuring the system variable group_replication_compression_threshold . We have copied below the steps to set a compression threshold:

STOP GROUP_REPLICATION;
SET GLOBAL group_replication_compression_threshold= 5242880;
START GROUP_REPLICATION; 

In the above script, We have set the compression threshold to 5MB. Now if a transaction generates a replication  message  more  than  5MB, i.e., the binary log  transaction entry is larger than 5MB, then it is compressed.

Note: You can disable the compression by setting threshold to “0“

• In Group Replication large messages are automatically fragmented. Because, When an abnormally large message is sent between Group Replication group members, it can result in some group members being reported as failed and expelled from the group. So large messages are automatically split into fragments that are sent separately and reassembled by the recipients. You can configure system variable  group_replication_communication_max_message_size ( default value is 10485760 bytes / 10 MiB ) to specify a message size above which messages are fragmented. This value cannot be larger than the system variable slave_max_allowed_packet , which is 1073741824 bytes (1 GB). You can switch off fragmentation by setting value “0” for group_replication_communication_max_message_size .

Note: In order for a replication group to use fragmentation, all group members must be at MySQL 8.0.16 or above

Conclusion

Group Replication definitely  is an off-the-shelf solution for building highly available, fault tolerant  and self-healing MySQL infrastructure operations. Even if some of the servers subsequently fail, as long it is not all or a majority, the system is still available. Depending on the number of servers which fail the group might have degraded performance or scalability, but it is still available. To conclude, MySQL Group Replication guarantees that the database service is continuously available.  But, When you are using such compelling solution for MySQL Reliability, It’s alway better to also discount limitations and tunable parameter for better performance. Thanks  for taking  time in reading this  blog and we welcome your comments.

References 

https://www.percona.com/blog/2017/08/01/group-replication-sweet-sour/ 

https://mysqlhighavailability.com/mysql-group-replication-a-quick-start-guide/ 

https://dev.mysql.com/doc/refman/8.0/en/group-replication-limitations.html

The post MySQL 8 Group Replication Limitations appeared first on The WebScale Database Infrastructure Operations Experts.

MySQL Group Replication can operate in both single-primary mode with automatic primary election, where only one server accepts updates at a time and multi-primary mode, where all servers can accept updates, even if they are issued concurrently. The built-in group membership service retains view of the group consistent and available for all servers at any given point in time, Servers can leave and join the group and the view is updated accordingly. If servers leave the group unexpectedly, the failure detection mechanism detects this and notifies the group that the view has changed, All this happens automatically !

For any transaction to commit, the majority of group members have to agree on the order of a given transaction in the global sequence of transactions. Decision to commit or abort a transaction is taken by respective servers, but all servers make same decision. In the case of systems built on network partition, When the members of the group are unable to reach agreement on a transaction, the system halt till the issue is resolved, This guarantees split-brain protection mechanism.

All these fault tolerance mechanisms are powered by Group Communication System (GCS) protocols, a group membership service, and completely safe ordered message delivery system. Group Replication is powered by Paxos algorithm (https://en.wikipedia.org/wiki/Paxos_(computer_science)), which acts as the group communication engine.

Till now, we have just posted about the capabilities of Group Replication, Now we have mentioned below (in bullets) about all the limitations of Group Replication:

• set –binlog-checksum=NONE – Group replication cannot benefit from –binlog-checksum due to the design limitation of replication event checksums.
• Gap Locks not supported – The information about gap locks are not available outside InnoDB so certification process cannot acknowledge gap locks  .
• Table Locks and Named Locks not supported – Certification process will not acknowledge table / named locks.
• Concurrent DDL versus DML Operations – Concurrent data definition statements and data manipulation statements executing against the same object but on different servers is not supported when using multi-primary mode. During execution of Data Definition Language (DDL) statements on an object, executing concurrent Data Manipulation Language (DML) on the same object but on a different server instance has the risk of conflicting DDL executing on different instances not being detected.
• Very Large Transactions.  Individual transactions that result in GTID contents which are large enough that it cannot be copied between group members over the network within a 5 second window can cause failures in the group communication. To avoid this issue try and limit the size of your transactions as much as possible. For example, split up files used with LOAD DATA INFILE into smaller chunks.
• Multi-primary Mode Deadlock.  When a group is operating in multi-primary mode, SELECT … FOR UPDATE statements can result in a deadlock. This is because the lock is not shared across the members of the group, therefore the expectation for such a statement might not be reached.

The post MySQL 8.0 Group Replication Limitations appeared first on The WebScale Database Infrastructure Operations Experts.