All Products
Search
Document Center

PolarDB:Global Database Network (GDN) untuk Multi-write

Last Updated:Mar 25, 2026

Pada edisi dasar Global Database Network (GDN), kluster secondary meneruskan permintaan write ke kluster primary. Proses ini dapat menyebabkan latensi write yang signifikan ketika kluster berada pada jarak fisik yang jauh. GDN untuk Multi-write menyediakan solusi multi-write tingkat tabel yang memungkinkan setiap sub-kluster melakukan write secara lokal ke tabel yang memiliki izin write. Desain ini mendukung akses berbasis kedekinan baik untuk operasi read maupun write, sehingga secara efektif mengurangi latensi write antar-wilayah.

Catatan

PolarDB GDN untuk Multi-write saat ini sedang dalam pratinjau publik. Untuk menggunakan fitur ini, bergabunglah dengan grup DingTalk kami untuk meminta akses.

Nomor grup DingTalk: 30245017864

Cara kerja

GDN untuk Multi-write menggunakan teknologi replikasi fisik PolarDB untuk menyediakan kemampuan multi-write tingkat tabel dalam penerapan cross-region. Mekanisme intinya adalah sebagai berikut:

  • Kepemilikan izin write tingkat tabel: Izin write untuk setiap tabel diberikan secara eksklusif hanya kepada satu sub-kluster, sehingga hanya sub-kluster tersebut yang dapat menulis ke tabel tersebut kapan pun.

  • Write lokal: Setiap sub-kluster dapat melakukan write secara lokal ke tabel yang memiliki izin write, memungkinkan pembaruan data dengan latensi rendah dan throughput tinggi.

  • Sinkronisasi data global: Semua perubahan data disinkronkan secara real time ke sub-kluster lain melalui tautan replikasi fisik berkinerja tinggi, yang menjamin konsistensi data global.

  • Keterbacaan data lengkap: Semua sub-kluster dapat langsung membaca data terbaru dari semua tabel, mendukung akses read lokal dalam skenario cross-region.

Berikut contoh dengan tiga sub-kluster di Tiongkok (Hong Kong), Singapura, dan Jerman (Frankfurt):

  • Anda membuat Tabel A di sub-kluster Tiongkok (Hong Kong). Secara default, izin write untuk tabel ini dimiliki oleh sub-kluster Tiongkok (Hong Kong).

  • Anda membuat Tabel B di sub-kluster Singapura. Izin write untuk tabel ini dimiliki oleh sub-kluster Singapura.

  • Anda membuat Tabel C di sub-kluster Jerman (Frankfurt). Izin write untuk tabel ini dimiliki oleh sub-kluster Jerman (Frankfurt).

Semua operasi write pada Tabel A di sub-kluster Tiongkok (Hong Kong) diterapkan langsung ke data lokal. Pada saat yang sama, sub-kluster ini menerima perubahan data untuk Tabel B dan Tabel C secara real time dari sub-kluster Singapura dan Jerman (Frankfurt) melalui replikasi fisik. Dengan demikian, sub-kluster Tiongkok (Hong Kong) tidak hanya dapat melakukan write lokal secara efisien (Tabel A), tetapi juga dapat langsung membaca data terbaru dari semua tabel (Tabel A, Tabel B, dan Tabel C). Prinsip yang sama berlaku untuk sub-kluster Singapura dan Jerman (Frankfurt).

image

Prasyarat

Kluster PolarDB Anda harus menjalankan MySQL 8.0.2.

Buat GDN untuk Multi-write

  1. Minta akses: PolarDB GDN untuk Multi-write saat ini sedang dalam pratinjau publik. Untuk menggunakan fitur ini, bergabunglah dengan grup DingTalk kami untuk meminta akses. Nomor grup DingTalk: 30245017864

  2. Buat dan kelola Global Database Network: Pilih kluster yang memenuhi prasyarat untuk dijadikan kluster primary dari Global Database Network (GDN).

    Penting

    Saat Anda membuat GDN untuk Multi-write, kluster primary akan restart sekali.

  3. Tambahkan dan kelola kluster secondary: Buka halaman pembelian PolarDB untuk menambahkan kluster secondary ke GDN.

  4. Hubungkan ke Global Database Network: Dalam GDN, setiap sub-kluster (kluster primary dan secondary) menyediakan titik akhir kluster independen. Anda dapat menghubungkan ke titik akhir kluster terdekat berdasarkan wilayah aplikasi Anda. Selain itu, GDN menyediakan nama domain global, yang tidak hanya memungkinkan akses berbasis kedekinan tetapi juga tetap tidak berubah setelah terjadi alih bencana kluster primary.

  5. Berdasarkan kebutuhan bisnis Anda, buat tabel yang diperlukan di sub-kluster wilayah tertentu. Hal ini memungkinkan setiap sub-kluster melakukan write secara lokal ke tabel yang memiliki izin write, sehingga mendukung akses berbasis kedekinan untuk operasi read dan write serta secara efektif mengurangi latensi write cross-region.

Kelola izin write tabel

Saat Anda membuat tabel di sub-kluster, sub-kluster tersebut secara default memiliki izin write untuk tabel tersebut. Izin write untuk setiap tabel hanya dimiliki oleh satu sub-kluster dalam satu waktu, sedangkan semua sub-kluster lain memiliki akses read-only ke tabel tersebut secara default.

Transfer izin write

Gunakan pernyataan DDL berikut untuk mentransfer izin write tabel secara dinamis antar sub-kluster:

Pernyataan

Deskripsi

ALTER TABLE <table_name> GDN_RELEASE;

Melepaskan izin write tabel dari sub-kluster saat ini. Setelah dieksekusi, tabel menjadi read-only di sub-kluster saat ini.

ALTER TABLE <table_name> GDN_FETCH;

Mengambil izin write tabel di sub-kluster saat ini. Sebelum menjalankan pernyataan ini, Anda harus melepaskan izin write dari kluster asal terlebih dahulu.

Lihat kepemilikan izin write

Anda dapat memeriksa output pernyataan SHOW CREATE TABLE untuk menentukan apakah sub-kluster saat ini memiliki izin write untuk suatu tabel:

  • Jika output berisi tag /* GDN_REMOTE */, izin write untuk tabel tersebut dimiliki oleh sub-kluster lain, dan sub-kluster saat ini hanya memiliki akses read-only.

  • Jika output tidak berisi tag /* GDN_REMOTE */, sub-kluster saat ini memiliki izin write untuk tabel tersebut.

Contoh

Contoh berikut menunjukkan cara mentransfer izin write untuk tabel t_A, yang dibuat di sub-kluster Tiongkok (Hong Kong), ke sub-kluster Singapura.

  1. Buat tabel di sub-kluster Tiongkok (Hong Kong) dan konfirmasi kepemilikan izin write-nya.

    -- Buat tabel di sub-kluster Tiongkok (Hong Kong).
    CREATE TABLE t_A (id INT PRIMARY KEY);
    
    -- Periksa skema tabel. Output tidak berisi tag GDN_REMOTE, yang menunjukkan bahwa izin write dimiliki oleh sub-kluster saat ini.
    SHOW CREATE TABLE t_A\G
    Create Table: CREATE TABLE `t_A` (
      `id` int(11) NOT NULL,
      PRIMARY KEY (`id`)
    ) ENGINE=InnoDB DEFAULT CHARSET=utf8
  2. Melepaskan izin write untuk tabel di sub-kluster Tiongkok (Hong Kong).

    ALTER TABLE t_A GDN_RELEASE;
    
    -- Periksa lagi. Output berisi tag GDN_REMOTE, yang menunjukkan bahwa izin write telah dilepaskan.
    SHOW CREATE TABLE t_A\G
    Create Table: CREATE TABLE `t_A` (
      `id` int(11) NOT NULL,
      PRIMARY KEY (`id`)
    ) /* GDN_REMOTE */ ENGINE=InnoDB DEFAULT CHARSET=utf8
  3. Ambil izin write untuk tabel di sub-kluster Singapura.

    ALTER TABLE t_A GDN_FETCH;
    
    -- Periksa skema tabel. Output tidak berisi tag GDN_REMOTE, yang menunjukkan bahwa izin write telah dialihkan ke sub-kluster saat ini.
    SHOW CREATE TABLE t_A\G
    Create Table: CREATE TABLE `t_A` (
      `id` int(11) NOT NULL,
      PRIMARY KEY (`id`)
    ) ENGINE=InnoDB DEFAULT CHARSET=utf8
  4. Di sub-kluster Jerman (Frankfurt), periksa tabel untuk memastikan bahwa tabel tersebut masih read-only.

    -- Output berisi tag GDN_REMOTE, yang menunjukkan bahwa izin write tidak dimiliki oleh sub-kluster saat ini.
    SHOW CREATE TABLE t_A\G
    Create Table: CREATE TABLE `t_A` (
      `id` int(11) NOT NULL,
      PRIMARY KEY (`id`)
    ) /* GDN_REMOTE */ ENGINE=InnoDB DEFAULT CHARSET=utf8