PolarDB:Ajouter et gérer des clusters secondaires

Prérequis

Vous devez d'abord créer un Global Database Network (GDN) avant d'y ajouter un cluster secondaire.

Tarification

Les frais liés à un Global Database Network (GDN) comprennent les coûts du cluster ainsi que les éventuels frais de réplication transfrontalière des données. 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 bien tous deux 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 situé en Chine (Chengdu) et les clusters secondaires 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 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 est en Chine continentale et le cluster secondaire hors de Chine continentale. Par exemple, le cluster principal est en Chine (Chengdu) et le cluster secondaire dans une région telle que Chine (Hong Kong) ou Singapour.

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

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

  Exemple de facturation

  Exemple

  À 09h00, vous interrogez la position d'écriture physique du journal et constatez qu'elle est ib_logfile1/648143676. À 10h00, la position passe à ib_logfile3/648142342. La quantité de données écrites durant cette heure correspond à la différence entre ces 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 donc de 1073741824 - 648143676 = 425598148 octets.

  2. Quantité écrite dans le fichier intermédiaire (ib_logfile2) : Une fois ib_logfile1 plein, le système écrit intégralement 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.

  Ainsi, la quantité totale écrite est de 425598148 + 1073741824 + 648142342 = 2147482314 octets. Cela représente 2147482314 / 1024 / 1024 / 1024 = 1.999998 Go (arrondi par défaut à six décimales). Les frais de transfert transfrontalier pour cette heure s'élèvent à environ 1.999998 GB × USD 0.80/GB = USD 1.5999984.

  Interroger la progression d'é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  |
  +------------------------+

Remarques d'utilisation

Un Global Database Network (GDN) synchronise les données via un mécanisme de réplication physique basé sur les journaux redo. Par conséquent, l'activation du journal binaire n'est pas requise par défaut. Si votre charge de travail nécessite une synchronisation des journaux binaires entre les clusters (par exemple pour l'abonnement aux données), assurez-vous que le paramètre du journal binaire (loose_polar_log_bin) est configuré de manière identique sur les clusters principaux et secondaires. Sinon, vous risquez une incohérence des données du journal binaire après un basculement principal/secondaire.

Ajouter un cluster secondaire

Un Global Database Network (GDN) utilise l'Express Connect transfrontalier de China Unicom et le Cloud Enterprise Network (CEN) transfrontalier pour permettre l'ajout de clusters secondaires transfrontaliers. Une configuration est qualifiée de transfrontalière lorsque les clusters principaux et secondaires se trouvent dans différents types de régions, tels que définis ci-dessous. L'ajout d'un cluster secondaire transfrontalier nécessite une préparation supplémentaire.

• Chine continentale : Chine (Hangzhou), Chine (Shanghai), Chine (Shenzhen), Chine (Heyuan), Chine (Guangzhou), Chine (Qingdao), Chine (Beijing), Chine (Zhangjiakou), Chine (Hohhot), Chine (Ulanqab) et Chine (Chengdu).

• Autres régions : Chine (Hong Kong), Japon (Tokyo), Corée du Sud (Séoul), Singapour, Malaisie (Kuala Lumpur), Indonésie (Jakarta), Philippines (Manille), Thaïlande (Bangkok), Allemagne (Francfort), États-Unis (Silicon Valley), États-Unis (Virginie) et Royaume-Uni (Londres).

Retirer un cluster secondaire

1. Connectez-vous à la console PolarDB. Dans le volet de navigation de gauche, cliquez sur Global Database Network (GDN).

2. Sur la page Global Database Network (GDN), localisez le GDN cible et cliquez sur son GDN ID pour accéder à la page de détails.

3. Dans la section Clusters, localisez le cluster secondaire cible et cliquez sur Remove dans la colonne Actions.

   Remarque

   • Le processus de retrait prend environ cinq minutes.

   • Pendant le processus de retrait, tous les endpoints de connexion des clusters du GDN, y compris ceux du cluster en cours de retrait, restent disponibles pour un accès normal à la base de données.

   • Seuls les clusters secondaires peuvent être retirés d'un GDN. Le cluster principal ne peut pas être retiré.

   • Une fois retiré d'un GDN, un cluster secondaire cesse de synchroniser les données avec le cluster principal et passe en mode lecture/écriture.

   • Après le retrait d'un cluster d'un GDN, il est impossible de l'y ajouter à nouveau en tant que cluster secondaire. Effectuez cette action avec prudence.

4. Lisez attentivement les remarques dans la boîte de dialogue contextuelle, puis cliquez sur OK pour retirer le cluster secondaire.

Basculer le cluster principal

1. Connectez-vous à la console PolarDB. Dans le volet de navigation de gauche, cliquez sur Global Database Network (GDN).

2. Sur la page Global Database Network (GDN), localisez le GDN cible et cliquez sur son GDN ID pour accéder à la page de détails.

3. Dans la section Clusters, localisez le cluster secondaire cible et cliquez sur Switch to Primary Cluster dans la colonne Operation.

4. Dans la boîte de dialogue Primary/Secondary Switchover, sélectionnez le cluster secondaire qui deviendra le nouveau cluster principal, puis cliquez sur OK.

   Remarque

   • Un basculement principal/secondaire n'échange pas les endpoints de connexion des deux clusters. Une mise à jour de la configuration de votre application peut s'avérer nécessaire. Par exemple, si le cluster principal original possédait un endpoint public, assurez-vous que le nouveau cluster principal en possède également un afin d'éviter tout problème d'accès à l'application. Pour consulter les endpoints de connexion, voir Consulter les endpoints de connexion et les ports.

   • Un basculement principal/secondaire dans un GDN s'effectue en moins de 10 minutes (généralement en moins de 5 minutes selon les tests). Pendant le basculement, des déconnexions transitoires pouvant atteindre 160 secondes peuvent survenir. Nous recommandons d'effectuer le basculement pendant les heures creuses et de veiller à ce que votre application dispose d'un mécanisme de reconnexion.

   • Si vous activez le commutateur Forced Switchover dans la boîte de dialogue Primary/Secondary Switchover :

     • Vous ne pouvez pas spécifier de cluster cible pour un basculement forcé. Le système promeut automatiquement le cluster secondaire ayant le numéro de séquence de journal (LSN) le plus élevé en tant que nouveau cluster principal.

     • Un basculement forcé comporte un risque de perte de données. Le cluster principal original est automatiquement retiré après le basculement. Effectuez cette action avec prudence.

Recréer un cluster secondaire

FAQ

Documentation associée

• Se connecter à un Global Database Network : Décrit comment établir une connexion à un GDN.

• Créer un nom de domaine global : Explique comment créer un endpoint de connexion unifié offrant un accès à la région la plus proche et persistant lors d'un basculement du cluster principal.

API associées