PolarDB for MySQL Multi-master Cluster (Limitless) Edition meningkatkan arsitektur dari model satu penulis-multi pembaca menjadi model multi-penulis-multi pembaca. Fitur ini mendukung penulisan konkuren ke database atau objek data yang berbeda pada node komputasi yang berbeda, serta penjadwalan dinamis database dan objek data di seluruh node dengan perpindahan yang selesai dalam hitungan detik. Fitur ini secara signifikan meningkatkan kemampuan baca-tulis konkuren kluster. Objek data yang didukung mencakup tabel, tampilan, pemicu, event, prosedur tersimpan, dan user-defined function. Topik ini menjelaskan cara menggunakan Multi-master Cluster (Limitless) Edition.
Prasyarat
Anda telah membeli kluster Multi-master Cluster (Limitless) Edition. Untuk informasi lebih lanjut, lihat Pembelian kustom dan Beli klaster langganan.
Anda telah membuat Akun istimewa. Untuk informasi lebih lanjut, lihat Buat Akun istimewa.
Anda telah terhubung ke kluster database. Untuk informasi lebih lanjut, lihat Hubungkan ke kluster database.
Multi-master Cluster (Limitless) Edition didukung pada PolarDB for MySQL 8.0.
Batasan
Data untuk setiap database atau objek data hanya dapat ditulis dari satu node. Anda tidak dapat membaca atau menulis data pada node yang tidak memiliki database atau objek data terkait yang ditetapkan padanya. Secara default, operasi dilakukan pada tingkat database. Untuk melakukan operasi pada tingkat objek data, Anda harus menggunakan sintaks tertentu untuk mengganti tingkat isolasi.
Kueri data lintas node RW tidak didukung. Jika pernyataan SQL kueri melibatkan database atau objek data pada beberapa node RW, sistem akan melaporkan kesalahan. Sebelum menjalankan kueri semacam itu, Anda harus memindahkan titik akhir semua database atau objek data yang terlibat ke satu node RW.
Hanya titik akhir kluster, yang didukung, bukan titik akhir utama.
Mode berikut didukung untuk mengganti titik akhir:
Pada tingkat isolasi database, Anda dapat mengganti titik akhir database.
Pada tingkat isolasi objek data, Anda dapat mengganti titik akhir objek data.
Tentukan node RW saat membuat database
Anda dapat membuat database pada node RW tertentu. Sintaksnya adalah sebagai berikut:
CREATE DATABASE name [POLARDB_WRITE_NODE master_id];Dalam mode isolasi database, data untuk setiap database hanya dapat ditulis dari satu node.
Jika Anda menghilangkan
[POLARDB_WRITE_NODE master_id], node RW yang digunakan untuk membuat database ditentukan oleh nilai parameter loose_innodb_mm_default_master_id. Jika nilai parameter loose_innodb_mm_default_master_id adalah 0, sistem akan memilih secara acak node RW tempat database dibuat. Anda dapat membuka halaman di PolarDB console untuk melihat dan mengubah parameter kluster atau node.Untuk melihat distribusi database di seluruh node, lihat Kueri distribusi database.
Contoh: Buat database bernama db1 pada RW1.
CREATE DATABASE db1 POLARDB_WRITE_NODE 1;Untuk membuat database db1 pada RW2, ubah angka 1 menjadi 2 pada contoh di atas.
Hapus database pada node RW tertentu
Anda dapat menghapus database pada node RW tertentu. Sintaksnya adalah sebagai berikut:
DROP DATABASE name;Contoh: Hapus database db1 dari node RW1.
DROP DATABASE db1;Anda tidak perlu menentukan POLARDB_WRITE_NODE saat menghapus database.
Ganti titik akhir database
Anda dapat mengganti titik akhir database ke node RW lain. Sintaksnya adalah sebagai berikut:
ALTER DATABASE name POLARDB_WRITE_NODE master_id;Contoh: Ganti titik akhir database db1 ke RW2.
ALTER DATABASE db1 POLARDB_WRITE_NODE 2;Mengganti titik akhir biasanya merupakan operasi yang memakan waktu. Waktu eksekusi bergantung pada dua faktor berikut:
Jumlah tabel dalam database. Perpindahan akan lebih lambat jika database berisi banyak tabel.
Tekanan Data Manipulation Language (DML) pada database selama perpindahan. Perpindahan akan lebih lambat jika tekanan DML tinggi.
Ganti dari tingkat isolasi database ke tingkat isolasi objek data
Secara default, tingkat isolasi untuk Kluster Multi-master adalah tingkat database. Artinya, semua objek data dalam database yang sama hanya dapat diakses dari satu node RW. Untuk memungkinkan objek data dalam database yang sama diakses dari beberapa node RW, Anda dapat mengubah tingkat isolasi dari tingkat database ke tingkat objek data. Sintaksnya adalah sebagai berikut:
ALTER DATABASE name TO TABLE_LOCK POLARDB_WRITE_NODE master_id;Dalam pernyataan ini, name adalah nama database dan master_id adalah titik akhir objek data.
Contoh: Ubah tingkat isolasi untuk database db1 dari tingkat database ke tingkat objek data, dan tetapkan titik akhir ke RW2.
ALTER DATABASE db1 TO TABLE_LOCK POLARDB_WRITE_NODE 2;Mengganti tingkat isolasi biasanya merupakan operasi yang memakan waktu. Waktu eksekusi bergantung pada dua faktor berikut:
Jumlah objek dalam database. Perpindahan akan lebih lambat jika database berisi banyak objek.
Tekanan DML pada database selama perpindahan. Perpindahan akan lebih lambat jika tekanan DML tinggi.
Ganti dari tingkat isolasi objek data ke tingkat isolasi database
Setelah Anda mengubah granularitas isolasi database ke tingkat objek data, Anda dapat mengembalikannya ke tingkat isolasi database untuk memudahkan manajemen. Untuk melakukannya, gunakan pernyataan berikut:
ALTER DATABASE name TO DB_LOCK POLARDB_WRITE_NODE master_id;Dalam pernyataan ini, name adalah nama database dan master_id adalah titik akhir database.
Contoh: Ubah tingkat isolasi untuk database db1 dari tingkat objek data ke tingkat database, dan tetapkan titik akhir ke RW1.
ALTER DATABASE db1 TO DB_LOCK POLARDB_WRITE_NODE 1;Mengganti tingkat isolasi biasanya merupakan operasi yang memakan waktu. Waktu eksekusi bergantung pada dua faktor berikut:
Jumlah objek dalam database. Perpindahan akan lebih lambat jika database berisi banyak objek.
Tekanan DML pada database selama perpindahan. Perpindahan akan lebih lambat jika tekanan DML tinggi.
Ganti titik akhir objek data
Setelah Anda mengubah tingkat isolasi Kluster Multi-master ke tingkat objek data, satu database dapat berisi beberapa jenis objek, seperti TABLE, VIEW, TRIGGER, FUNCTION, PROCEDURE, dan EVENT. Untuk mengganti titik akhir objek-objek ini, gunakan pernyataan berikut:
ALTER obj_type name POLARDB_WRITE_NODE master_id;Nilai yang valid untuk obj_type adalah TABLE, VIEW, TRIGGER, FUNCTION, PROCEDURE, dan EVENT. name adalah nama objek data.
Contoh 1: Ganti titik akhir tabel t1 dalam database db1 ke RW3.
ALTER TABLE db1.t1 POLARDB_WRITE_NODE 3;Contoh 2: Ganti titik akhir VIEW t2 dalam database saat ini ke RW2.
ALTER VIEW t2 POLARDB_WRITE_NODE 2;Contoh 3: Ganti titik akhir fungsi f1 dan fungsi f2 dalam database db2 ke RW1.
ALTER FUNCTION db2.f1, db2.f2 POLARDB_WRITE_NODE 1;Mengganti titik akhir biasanya merupakan operasi yang memakan waktu. Waktu eksekusi bergantung pada faktor-faktor berikut:
Tekanan DML pada objek data selama perpindahan. Perpindahan akan lebih lambat jika tekanan DML tinggi.
Objek dapat saling terkait. Jika objek yang terkait tidak memiliki titik akhir pada node RW yang sama, objek tersebut dapat menjadi tidak valid.
Sebagai contoh, sebuah tampilan bernama VIEW1 bergantung pada tabel bernama t1. Jika titik akhir VIEW1 berada di RW1 tetapi titik akhir t1 berada di RW2, kesalahan akan terjadi saat Anda mencoba mengakses VIEW1 di RW1. Demikian pula, jika objek yang dirujuk oleh FUNCTION, PROCEDURE, atau EVENT tidak memiliki titik akhir yang benar, eksekusinya akan gagal. Jika TRIGGER dan TABLE terkaitnya tidak memiliki titik akhir pada node yang sama, Anda tidak dapat memodifikasi data dalam TABLE tersebut.
Jika kendala kunci asing ada antara tabel t1 dan tabel t2, mengubah titik akhir salah satu tabel secara otomatis akan mengubah titik akhir tabel lainnya.
Tentukan node RW untuk pernyataan SQL
Fitur ini hanya berlaku untuk pernyataan non-kueri data, seperti pernyataan yang mengkueri information_schema atau variabel status. Untuk mengkueri data menggunakan pernyataan seperti SELECT * FROM table1, Anda tidak perlu menentukan node RW. Proksi database secara otomatis memilih node RW yang tepat untuk menjalankan kueri tersebut.
Untuk mengirim pernyataan SQL ke node RW tertentu, Anda dapat menjalankan pernyataan SQL berikut untuk mengunci node RW:
ALTER SESSION POLARDB_WRITE_NODE master_id;Contoh: Kueri nilai variabel innodb_buffer_pool_size pada node RW1.
ALTER SESSION POLARDB_WRITE_NODE 1; # Kirim pernyataan SQL ke node RW1.
SHOW VARIABLES LIKE 'innodb_buffer_pool_size'; # Kueri nilai innodb_buffer_pool_size pada node RW1.Jika Anda tidak menentukan node RW saat menjalankan pernyataan SQL, proksi database akan memilih secara acak node RW untuk menjalankan pernyataan tersebut.
Anda dapat menjalankan perintah berikut untuk membuka kunci node RW yang ditentukan agar dapat menjalankan pernyataan SQL:
RESET SESSION POLARDB_WRITE_NODE;Kueri distribusi database
Anda dapat membuka halaman di PolarDB console untuk melihat distribusi semua database dalam kluster.
Anda dapat menjalankan perintah berikut untuk mengkueri distribusi database pada node RW tertentu:
ALTER SESSION POLARDB_WRITE_NODE master_id; SELECT * FROM INFORMATION_SCHEMA.INNODB_MASTER_GLOBAL_LOCK_INFO WHERE LOCK_MODE = 'SLS_X';Contoh: Kueri distribusi database pada node RW1.
ALTER SESSION POLARDB_WRITE_NODE 1; SELECT * FROM INFORMATION_SCHEMA.INNODB_MASTER_GLOBAL_LOCK_INFO WHERE LOCK_MODE = 'SLS_X';Hasil kueri adalah sebagai berikut:
SELECT * FROM INFORMATION_SCHEMA.INNODB_MASTER_GLOBAL_LOCK_INFO WHERE LOCK_MODE = 'SLS_X'; +------------+---------------------+----------+--------------+-----------+----------+-------------+-------------+---------------------+-----------------+ | table_name | table_id | space_id | s_lock_count | lock_mode | object | current_lsn | hold_thread | hold_start_time | hold_total_time | +------------+---------------------+----------+--------------+-----------+----------+-------------+-------------+---------------------+-----------------+ | test3/f1 | 9149389368458135753 | 0 | 0 | SLS_X | function | 28076635 | 17 | 2024-07-10 21:35:20 | 214 | | test3/e1 | 9149389368458332874 | 0 | 0 | SLS_X | event | 28077248 | 17 | 2024-07-10 21:35:30 | 204 | | test3/v1 | 9149389368457234649 | 0 | 0 | SLS_X | view | 28075972 | 17 | 2024-07-10 21:35:08 | 226 | | sbtest | 2107518311328629409 | 0 | 0 | SLS_X | db | 28034927 | 4294967295 | 2024-07-07 23:04:41 | 254053 | | test | 7190879906290573778 | 0 | 0 | SLS_X | db | 28034927 | 4294967295 | 2024-07-10 11:20:57 | 37077 | | test2 | 3381728963524265351 | 0 | 0 | SLS_X | db | 28034927 | 4294967295 | 2024-07-10 11:13:09 | 37545 | +------------+---------------------+----------+--------------+-----------+----------+-------------+-------------+---------------------+-----------------+ 6 rows in set (0.00 sec)Setiap baris dalam hasil kueri menyediakan informasi tentang database atau objek data, meskipun kolom tersebut bernama table_name. Dalam hasil ini,
sbtest,test, dantest2menggunakan tingkat isolasi database.function test3.f1,event test3.e1, danview test3.v1menggunakan tingkat isolasi objek data. Anda mungkin juga melihat objek bernama mysql/global_ddl_lock dengan tipe objek Table. Ini adalah informasi internal yang dapat Anda abaikan.Anda dapat menjalankan perintah berikut untuk mengkueri distribusi semua database dalam kluster:
CatatanKueri ini hanya dapat dijalankan menggunakan Akun istimewa. Anda tidak dapat menjalankan kueri ini dengan akun yang baru dibuat.
SELECT * FROM INFORMATION_SCHEMA.INNODB_CC_GLOBAL_LOCK_INFO WHERE LOCK_MODE = 'SLS_X';Hasil kueri adalah sebagai berikut:
mysql> SELECT * FROM INFORMATION_SCHEMA.INNODB_CC_GLOBAL_LOCK_INFO WHERE LOCK_MODE = 'SLS_X'; +-----------+------------+---------------------+-----------+-----------+-------------+---------------------+-----------------+ | master_id | table_name | table_id | lock_mode | object | current_lsn | hold_start_time | hold_total_time | +-----------+------------+---------------------+-----------+-----------+-------------+---------------------+-----------------+ | 1 | test3/v1 | 9149389368457234649 | SLS_X | view | 28075972 | 2024-07-10 21:35:08 | 754 | | 2 | test5/t1 | 9149389447232697561 | SLS_X | table | 7256175 | 2024-07-10 21:46:36 | 66 | | 1 | test2 | 3381728963524265351 | SLS_X | db | 28034927 | 2024-07-10 11:13:09 | 38073 | | 2 | test4 | 3381728963524272009 | SLS_X | db | 7255352 | 2024-07-10 21:46:27 | 75 | | 1 | test3/f1 | 9149389368458135753 | SLS_X | function | 28076635 | 2024-07-10 21:35:20 | 742 | | 1 | test3/e1 | 9149389368458332874 | SLS_X | event | 28077248 | 2024-07-10 21:35:30 | 732 | | 1 | test | 7190879906290573778 | SLS_X | db | 28034927 | 2024-07-10 11:20:57 | 37605 | | 2 | test5/p1 | 9149389447233473757 | SLS_X | procedure | 7257051 | 2024-07-10 21:46:45 | 57 | | 1 | sbtest | 2107518311328629409 | SLS_X | db | 28034927 | 2024-07-07 23:04:41 | 254581 | +-----------+------------+---------------------+-----------+-----------+-------------+---------------------+-----------------+ 9 rows in set (0.00 sec)Setiap baris dalam hasil kueri menyediakan informasi tentang database atau objek data, meskipun kolom tersebut bernama table_name. Hasil ini menunjukkan node RW tempat database atau objek data berada. Anda mungkin juga melihat objek bernama mysql/global_ddl_lock dengan tipe objek Table. Ini adalah informasi internal yang dapat Anda abaikan.
Cara mengatur binary logging
Multi-master Cluster (Limitless) Edition sepenuhnya kompatibel dengan binary logging MySQL. Fitur ini mengintegrasikan log operasi dari semua node RW dalam kluster untuk menghasilkan log biner yang terpadu secara global dan terurut secara logis.
Anda dapat mengonfigurasi parameter loose_polar_log_bin untuk mengaktifkan fitur binary logging Multi-master Cluster (Limitless) Edition. Anda juga dapat mengonfigurasi parameter binlog_expire_logs_seconds untuk menetapkan periode retensi log biner untuk Multi-master Cluster (Limitless) Edition. Untuk informasi lebih lanjut, lihat Aktifkan binary logging.
Kluster Multi-master Cluster (Limitless) Edition dapat digunakan sebagai sumber atau tujuan Layanan Transmisi Data (DTS) untuk melakukan sinkronisasi data satu arah atau dua arah.