Since you ask specifically about Group Replication and state that reliability is of great importance, the MySQL 8.0: New Features in Replication post talks specifically about improvements with this functionality and MySQL 8.0. I've quoted and referenced the specific portions of this that talks about what I feel are important factors to be considered in making a determination.
Recently a new technology, MySQL Group Replication, was released in
MySQL 5.7, and later it was also included in MySQL 8. It is
continuously improved either through bug fixing or new features in
both MySQL 5.7 and MySQL 8. But this is not the only new thing in
MySQL 8. There is more.
Relevant replication areas that have been improved in MySQL 8:
- Resiliency: crash-recoverable DDLs in replication.
Performance and Efficiency
Making replication efficient and fast is also something that is
continuously worked on. In MySQL 8, there are a set of features that
enhance the replication applier pipeline, so that it is able to ingest
more load coming in, faster and in a more efficient way. Here are the
Transactions spend less time in the replication applier pipeline. There is an improved synchronization mechanism between
receiver and applier threads, which translates into less contention
between receiver and applier threads. This enhancement allows both
receiver and applier threads to do more work in parallel instead of
serializing themselves in a lock that protects the relay log.
More transactions are applied in parallel. Much improved parallel applier by relying on transaction WRITESETs (roughly the set
of rows changed). This also allows the applier to install changes in
parallel even for single threaded workloads coming in from
replication. There is much to say about this feature, but you can
learn more about the details here.
Predictable and sustained replication throughput fine tuning flow control. Flow control was also revised and improved. The user can
now fine tune a group replication cluster so that the impact of
imbalanced members is limited and the entire system converges to a
Metaphorically speaking, MySQL has had a brain transplant. It has now a new data dictionary, which among other
improvements also brings in crash-recoverable dictionary changes.
Roughly, this makes DDLs atomic and recoverable. This functionality is
also extended to include binary log recoverability for DDLs.
On recovery, recover my atomic DDLs too! When the server is restarting after a crash, the binary log and the InnoDB synchronize on
to figure out which transactions to recover to bring both to a
consistent state. Now atomic DDLs recovery also takes into account the
contents of the binary log, so that metadata and the binary log is
On recovery, recover my atomic DDLs too… Oh, and my applier positions as well! If a crash happens while a replication applier is
applying an atomic DDL, then recovery will make sure that the
replication positions are consistent with the metadata changes.