PolarDB for MySQL Multi-master Cluster (Limitless) fait évoluer l'architecture à écriture unique et lectures multiples vers une architecture multi-écritures et multi-lectures grâce à plusieurs nœuds primaires. Cette solution cible les charges de travail de lecture/écriture à forte concurrence, telles que les environnements SaaS multilocataires, les jeux en ligne et le commerce électronique.
La figure suivante illustre l'architecture de l'édition Multi-master Cluster (Limitless) Edition.
Lorsque vous vous connectez via l'endpoint du cluster, PolarProxy route les instructions SQL vers le nœud primaire approprié.
Avantages principaux
-
Write scale-out in seconds
Cette édition prend en charge l'écriture simultanée de données dans des bases réparties sur un maximum de 63 nœuds de calcul. Le basculement dynamique des nœuds s'effectue en quelques secondes, ce qui améliore considérablement les capacités globales de lecture et d'écriture concurrentes des clusters.
-
Multiple-mater backup (no read-only nodes).
En cas de défaillance d'un nœud primaire, le basculement vers un autre nœud primaire à faible trafic s'opère en quelques secondes. Les coûts sont réduits de moitié puisqu'aucune ressource inactive supplémentaire n'est déployée pour la veille active.
Cas d'usage
L'édition Multi-master Cluster (Limitless) Edition convient parfaitement aux scénarios tels que la multilocation SaaS, les jeux vidéo et le commerce électronique, caractérisés par des volumes élevés de requêtes concurrentes en lecture et en écriture.
-
Multitenancy in SaaS: high concurrency and load balance between tenants
Scénario : Le nombre de bases de données par locataire évolue rapidement et la charge subit des variations importantes. Une planification des ressources entre différentes instances est nécessaire pour garantir une expérience utilisateur optimale.
Solution : L'édition Multi-master Cluster (Limitless) Edition permet de basculer les bases de données des locataires entre différents nœuds primaires ou d'ajouter de nouveaux nœuds primaires en quelques secondes afin d'absorber les pics de trafic, assurant ainsi l'équilibrage de charge.
-
Global gaming server and e-commerce scenarios: scaling in minutes to cater to fast-growing business requests
Scénario : Les architectures reposant sur un middleware ou une logique métier pour le sharding des bases et des tables sont couramment utilisées. Lors des mises à jour de version ou des promotions majeures, une extension rapide de la capacité du cluster est indispensable, suivie d'une réduction tout aussi rapide une fois l'événement terminé. Or, la mise à l'échelle des clusters traditionnels implique des étapes complexes de migration des données.
Solution : Grâce à son extension en quelques secondes et à son routage transparent, l'édition Multi-master Cluster (Limitless) Edition se combine efficacement avec les solutions de sharding existantes pour réduire le processus de mise à l'échelle de plusieurs jours à quelques minutes seulement.
-
Gaming applications deployed on different servers: better performance and scalability
Scénario : Durant la phase de croissance d'un jeu, les bases de données subissent une charge lourde et croissante, entraînant une augmentation continue du nombre de bases et, par conséquent, de la charge sur les nœuds primaires. À l'inverse, lors du déclin du jeu, la charge diminue significativement et les bases fusionnent, allégeant ainsi la pression sur les nœuds primaires.
Solution : Pendant la croissance, migrez certaines bases de données vers de nouveaux nœuds primaires pour équilibrer la charge. En période de déclin, regroupez les bases sur un nombre réduit de nœuds primaires afin de diminuer les coûts opérationnels.
Limites
Le moteur de base de données doit être MySQL 8.0.
La conversion directe d'un cluster Cluster edition vers un cluster Multi-master Cluster (Limitless) n'est pas prise en charge. Pour mettre à niveau l'édition du produit, consultez Mise à niveau majeure de version.
Amélioration des performances
Les tests montrent que les capacités globales de lecture et d'écriture concurrentes augmentent linéairement à mesure que les bases de données du cluster sont distribuées sur un plus grand nombre de nœuds primaires. L'extrait de code suivant présente un test de charge type :
Contexte du test : Le cluster comprend huit bases de données et huit nœuds primaires.
Procédure de test : Au départ, les huit bases partagent un seul nœud primaire. Les données sont synchronisées simultanément sur toutes les bases afin d'exécuter un test de charge identique. Durant ce test, les bases sont progressivement réparties sur deux, quatre, puis huit nœuds primaires. Observez ensuite l'évolution des performances globales du cluster.
La figure ci-dessous montre l'évolution du QPS.
Comme l'illustre la figure précédente, la répartition des bases de données sur davantage de nœuds primaires améliore significativement les capacités de lecture et d'écriture concurrentes du cluster, selon une progression linéaire.
Spécifications des nœuds et facturation
Spécifications : Les types dedicated et general-purpose sont tous deux pris en charge. Consultez Spécifications des nœuds de calcul pour Enterprise Edition.
Facturation : Reportez-vous aux sections Éléments facturables et Règles de facturation des nœuds de calcul.
Prise en main
Configurez les paramètres de base : créez un compte de base de données, configurez la liste d'autorisation du cluster et connectez-vous à la base de données.
-
Dans un cluster Multi-master Cluster (Limitless), chaque base de données ou objet de données route ses écritures via un seul nœud. Lors de la création d'une base, spécifiez un nœud primaire ou définissez
loose_innodb_mm_default_master_idsur 0 pour laisser le système sélectionner aléatoirement un nœud primaire. -
Interrogez les données à l'aide d'instructions
SELECT.PolarProxy route automatiquement les requêtes vers le nœud primaire approprié. Aucune spécification de nœud n'est requise.