PolarDB:Global Database Network (GDN)

Présentation

Basic edition

Multi-write edition

Un Global Database Network (GDN) se compose d'un cluster principal et de plusieurs clusters secondaires. Le cluster principal gère les requêtes en écriture, tandis que les clusters secondaires, répartis dans différentes régions, traitent les requêtes en lecture locales. Les données sont synchronisées entre tous les clusters via des liaisons à faible latence, formant ainsi une base de données logique unique.

Dans l'architecture GDN Basic Edition, les clusters secondaires transmettent les requêtes en écriture au cluster principal via un routage interrégional. Lorsque le cluster principal et les clusters secondaires sont déployés dans des régions différentes et géographiquement éloignées, la latence d'écriture sur les clusters secondaires augmente considérablement. La GDN Multi-write Edition offre une solution d'écriture multiple au niveau de la table. Chaque cluster peut ainsi effectuer des écritures locales sur les tables pour lesquelles il dispose de permissions d'écriture, réduisant efficacement la latence d'écriture interrégionale. Pour plus d'informations, reportez-vous au Guide utilisateur de la GDN multi-write edition. Remarque La PolarDB GDN Multi-write Edition est actuellement en version canary. Pour utiliser cette fonctionnalité, recherchez le numéro du groupe dans DingTalk et rejoignez-le pour toute demande. Numéro du groupe DingTalk : 30245017864

Cas d'utilisation

Redondance géographique active (déploiement multirégional) Déployez vos services dans plusieurs régions. Grâce à des fonctionnalités telles que la synchronisation interrégionale à faible latence, la séparation lecture/écriture interrégionale et l'accès local, le GDN garantit que la latence d'accès à la base de données pour les applications de chaque région est généralement inférieure à 2 secondes. Secteurs typiques : Jeux vidéo, e-commerce transfrontalier, services locaux (livraison de repas) et nouveau commerce de détail (points de vente). Architecture métier : Pour des performances optimales, les applications de chaque région lisent et écrivent directement dans la base de données locale. Les requêtes en écriture sont transmises au cluster principal pour traitement. Dans un GDN, chaque cluster (principal ou secondaire) fournit un endpoint de cluster indépendant. Connectez-vous à l'endpoint de cluster le plus proche en fonction de l'emplacement d'exécution de votre application. Les spécifications des clusters secondaires situés en Chine (Pékin) et en Chine (Shenzhen) doivent être égales ou supérieures à celles du cluster principal situé en Chine (Hangzhou). Nous vous recommandons d'utiliser les mêmes spécifications pour obtenir des performances optimales.

Reprise après sinistre géographique Utilisez le GDN pour assurer une haute disponibilité interrégionale et améliorer la sécurité des données ainsi que la disponibilité du système. En cas de défaillance du centre de données du cluster principal, vous pouvez rétablir le service en effectuant un basculement manuel vers un cluster secondaire. Le GDN prend en charge diverses architectures, telles que deux régions-trois centres de données, deux régions-quatre centres de données et trois régions-six centres de données. Secteurs typiques : Banque, titres et assurance. Architecture métier (exemple : architecture deux régions-trois centres de données) : La région principale est la Chine (Pékin) et utilise un déploiement sur deux zones de disponibilité, couvrant AZ1 et AZ2. La région de reprise après sinistre est la Chine (Shanghai) et utilise un déploiement sur une seule zone de disponibilité. Par défaut, l'application effectue des lectures et des écritures locales sur la base de données dans AZ1 de la région Chine (Pékin). Si AZ1 tombe en panne, le système bascule d'abord vers AZ2 à Pékin. Si AZ1 et AZ2 tombent toutes deux en panne, le système bascule vers AZ3 à Shanghai. Remarque Un basculement principal/secondaire dans un GDN s'effectue en moins de 10 minutes (généralement en moins de 5 minutes selon les résultats des tests). Pendant le basculement, des déconnexions transitoires pouvant durer jusqu'à 160 secondes peuvent survenir. Nous vous recommandons d'effectuer le basculement pendant les heures creuses et de vous assurer que votre application dispose d'un mécanisme de reconnexion.

Avantages

• Déploiement interrégional : Passez d'un déploiement monorégional à un déploiement multirégional sans modifier le code de votre application.

• Séparation lecture/écriture interrégionale et accès local : Dans un GDN, les requêtes en lecture sont routées vers le cluster secondaire local, tandis que les requêtes en écriture sont transmises au cluster principal.

• Configuration flexible : Les clusters principaux et secondaires disposent de configurations indépendantes, notamment les spécifications du cluster, les listes d'autorisation et les valeurs des paramètres.

• Synchronisation interrégionale à faible latence : La réplication physique asynchrone, basée sur le journal redo, et les technologies de relecture parallèle réduisent la latence de réplication interrégionale entre le cluster principal et les clusters secondaires. Cela garantit que les données restent synchronisées sur l'ensemble des clusters avec une latence de réplication généralement inférieure à deux secondes, réduisant ainsi considérablement la latence de lecture pour les applications situées dans des régions éloignées.

Prérequis et limites

Tarification

Les frais liés à un Global Database Network (GDN) comprennent les coûts du cluster ainsi que les éventuels frais de réplication des données transfrontalières. Les règles de facturation sont les suivantes :

• Scénarios gratuits :

  Vos clusters principaux et secondaires sont tous deux déployés dans des régions de Chine continentale, ou tous deux déployés dans la région Chine (Hong Kong) ou d'autres régions outre-mer. Exemples :

  • Le cluster principal et les clusters secondaires se trouvent tous en Chine continentale. Par exemple, le cluster principal est en Chine (Chengdu) et les clusters secondaires sont dans des régions telles que Chine (Hangzhou) ou Chine (Shenzhen).

  • Le cluster principal et les clusters secondaires se trouvent tous dans la région Chine (Hong Kong) ou d'autres régions outre-mer. Par exemple, le cluster principal est à Singapour et le cluster secondaire est aux Philippines (Manille).

• Scénarios payants :

  Des frais transfrontaliers s'appliquent lorsqu'un GDN traverse la frontière de la Chine continentale, par exemple si un cluster se trouve en Chine continentale et un autre en Chine (Hong Kong) ou dans une région outre-mer. Exemples :

  • Le cluster principal se trouve en Chine continentale et le cluster secondaire hors de Chine continentale. Par exemple, le cluster principal est en Chine (Chengdu) et le cluster secondaire est dans une région telle que Chine (Hong Kong) ou Singapour.

  • Le cluster principal se trouve hors de Chine continentale et le cluster secondaire en Chine continentale. Par exemple, le cluster principal est à Singapour et le cluster secondaire est dans une région telle que Chine (Hangzhou) ou Chine (Shenzhen).

• Règle de facturation : 0,80 USD par Go, facturé à l'heure. Les frais sont calculés chaque heure en fonction du volume de données du journal redo physiquement répliqué du cluster principal vers un cluster secondaire transfrontalier. Ces frais de trafic peuvent être estimés en interrogeant la position physique convertie à partir du numéro de séquence du journal (LSN).

  Exemple de facturation

  Exemple

  À 09:00, vous interrogez la position d'écriture physique du journal et constatez qu'elle est ib_logfile1/648143676. À 10:00, la position est mise à jour vers ib_logfile3/648142342. La quantité de données écrites durant cette heure correspond à la différence entre les deux positions.

  1. Quantité écrite dans le fichier de départ (ib_logfile1) : Soustrayez l'offset de départ de la taille totale du fichier. Chaque fichier journal fait 1 GB (1,073,741,824 bytes). La quantité écrite est de 1073741824 - 648143676 = 425598148 octets.

  2. Quantité écrite dans le fichier intermédiaire (ib_logfile2) : Une fois ib_logfile1 plein, le système écrit complètement ib_logfile2. Cette quantité est de 1,073,741,824 bytes (1 GB).

  3. Quantité écrite dans le fichier final (ib_logfile3) : Il s'agit de l'offset final, soit 648142342 octets.

  Par conséquent, la quantité totale écrite est de 425598148 + 1073741824 + 648142342 = 2147482314 octets. Cela représente 2147482314 / 1024 / 1024 / 1024 = 1.999998 Go (arrondi à six décimales par défaut). Les frais de transfert de données transfrontalières pour cette heure sont d'environ 1.999998 GB × USD 0.80/GB = USD 1.5999984.

  Interroger la progression de l'écriture du journal et l'offset du fichier physique

  -- Query the current write progress of the log system.
  SHOW STATUS LIKE 'Innodb_log_write_lsn'; 
  +----------------------+------------+
  | Variable_name        | Value      |
  +----------------------+------------+
  | Innodb_log_write_lsn | 1721889596 |
  +----------------------+------------+
  
  -- Query the physical file offset in bytes.
  SELECT lsn_to_pos(1721889596); 
  +------------------------+
  | lsn_to_pos(1721889596) |
  +------------------------+
  | ib_logfile1/648143676  |
  +------------------------+

Prise en main

1. Créer et gérer un réseau de bases de données global : Sélectionnez un cluster répondant aux prérequis pour servir de cluster principal du GDN.

2. Ajouter un cluster secondaire : Accédez à la page d'achat PolarDB pour ajouter un cluster secondaire au GDN que vous avez créé.

3. Se connecter à un réseau de bases de données global : Dans un GDN, chaque cluster (principal et secondaire) fournit un endpoint de cluster indépendant. Connectez-vous à l'endpoint du cluster le plus proche en fonction de la région de votre application. Le GDN fournit également un nom de domaine global. Cette fonctionnalité offre un accès local et un endpoint stable qui persiste lors d'un basculement du cluster principal.