Alauda Database Service for MySQL-MGR

Introduction

Alauda Database for MySQL-MGR is a high availability database solution based on MySQL Group Replication technology and runs on Kubernetes. It provides automated deployment and management capabilities for MySQL Group Replication clusters.

TOC

Key Features

  • High Availability: Cluster architecture based on MySQL Group Replication, implementing multi-node data automatic synchronization and fault self-healing, with automatic switchover during primary node failure, reducing service interruption risks.
  • Data Consistency: Distributed authentication based on group replication technology, ensuring data consistency.
  • Automated Management: Implementing full lifecycle management of cluster deployment, configuration updates, backup recovery, etc., through Operator, systematically reducing operational costs.
  • Elastic Scaling: Supporting online addition or removal of nodes, automatic global transaction state synchronization, adapting to dynamic business load changes.
  • Read-Write Separation: Supporting read-write separation through MySQL Router

Application Scenarios

  • Critical business databases requiring high availability
  • Distributed database scenarios demanding strong data consistency
  • Cloud-native databases needing elastic scalability

Usage Limitations

  • Group Member Count: The maximum number of MySQL replication group members is 9. At least 3 members are recommended to ensure high availability.
  • InnoDB Engine: Relies on the InnoDB storage engine; it is recommended to configure disabled_storage_engines="MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY" to disable unsupported storage engines.
  • Explicit Primary Key: Each table to be replicated must have a defined primary key or an equivalent primary key, where equivalents are non-null unique keys. Configure sql_generate_invisible_primary_key: ON to support tables without explicitly defined primary keys.
  • Network Quality: Designed to be deployed in cluster environments where server instances are located very close to each other, resulting in low network latency. High network latency can lead to replication delays or even replication failures.
  • Isolation Level Restrictions: It is recommended to use the READ COMMITTED isolation level; the SERIALIZABLE isolation level is not supported.
  • Foreign Key Restrictions: Cascading foreign keys are not recommended in multi-master mode.
  • Multi-Master Deadlocks: In multi-master mode, deadlocks may occur when using SELECT .. FOR UPDATE statements because locks are not shared among members.
  • Concurrent DDL and DML Conflicts: In multi-master mode, DDL and DML operations may cause conflicts; it is recommended to avoid concurrent DDL and DML operations.
  • Transaction Size Limitations: Ensure that the transaction size is within the group_replication_transaction_size_limit range (default approximately 143 MB) and can be completed within the group_replication_member_expel_timeout period (default 5s).
  • Heterogeneous Architecture Limitations: Due to limitations of the MySQL Clone plugin, heterogeneous scenarios are currently not supported.
  • Rolling Update Limitations: MySQL Pods will prioritize restarting secondary members first, with the primary member restarted last. This process may cause brief connection interruptions, requiring application-level retry mechanisms.