MariaDB
 sql >> Teknologi Basis Data >  >> RDS >> MariaDB

Menyebarkan Sharding MariaDB dengan Spider menggunakan ClusterControl

MariaDB menawarkan kemampuan sharding multi-host bawaan dengan mesin penyimpanan Spider. Spider mendukung partisi dan transaksi XA dan memungkinkan tabel jarak jauh dari instans MariaDB yang berbeda ditangani seolah-olah mereka berada pada instans yang sama. Meja jarak jauh dapat berupa mesin penyimpanan apa pun. Penautan tabel dicapai dengan membuat koneksi dari server MariaDB lokal ke server MariaDB jarak jauh, dan tautan dibagikan untuk semua tabel yang merupakan bagian dari transaksi yang sama.

Dalam posting blog ini, kami akan memandu Anda melalui penerapan cluster dua pecahan MariaDB menggunakan ClusterControl. Kami akan menyebarkan beberapa server MariaDB (untuk redundansi dan ketersediaan) untuk meng-host tabel yang dipartisi berdasarkan rentang kunci pecahan yang dipilih. Kunci pecahan yang dipilih pada dasarnya adalah kolom yang menyimpan nilai dengan batas bawah dan atas, seperti dalam kasus ini, nilai integer antara 0 hingga 1.000.000, menjadikannya kunci kandidat terbaik untuk menyeimbangkan distribusi data antara dua pecahan. Oleh karena itu, kami akan membagi rentang menjadi dua partisi:

  • 0 - 499999:Shard 1

  • 500000 - 1000000:Shard 2

Diagram berikut mengilustrasikan arsitektur tingkat tinggi kami tentang apa yang akan kami terapkan:

Beberapa penjelasan diagram:

  1. mariadb-gw-1:Instance MariaDB yang menjalankan mesin penyimpanan Spider, bertindak seperti router shard. Kami memberi nama untuk host ini sebagai MariaDB Gateway 1 dan ini akan menjadi server MariaDB utama (aktif) untuk mencapai pecahan. Aplikasi akan terhubung ke host ini seperti koneksi MariaDB standar. Node ini terhubung ke shard melalui HAProxy yang mendengarkan pada 127.0.0.1 port 3307 (shard1) dan 3308 (shard2).

  2. mariadb-gw-2:Instance MariaDB yang menjalankan mesin penyimpanan Spider, bertindak seperti router shard. Kami memberi nama untuk host ini sebagai MariaDB Gateway 2 dan ini akan menjadi server MariaDB (pasif) sekunder untuk mencapai pecahan. Ini akan memiliki pengaturan yang sama seperti mariadb-gw-1. Aplikasi akan terhubung ke host ini hanya jika MariaDB utama tidak aktif. Node ini terhubung ke shard melalui HAProxy yang mendengarkan pada 127.0.0.1 port 3307 (shard1) dan 3308 (shard2).

  3. mariadb-shard-1a:MariaDB master yang berfungsi sebagai node data utama untuk partisi pertama. Server gateway MariaDB hanya boleh menulis ke master shard.

  4. mariadb-shard-1b:Replika MariaDB yang berfungsi sebagai simpul data sekunder untuk partisi pertama. Ini akan mengambil alih peran master jika master shard mati (failover otomatis dikelola oleh ClusterControl).

  5. mariadb-shard-2a:MariaDB master yang berfungsi sebagai node data primer untuk partisi kedua. Server gateway MariaDB hanya menulis ke master shard.

  6. mariadb-shard-2b:Replika MariaDB yang berfungsi sebagai simpul data sekunder untuk partisi kedua. Ini akan mengambil alih peran master jika master shard mati (failover otomatis dikelola oleh ClusterControl).

  7. ClusterControl:Alat penyebaran, pengelolaan, dan pemantauan terpusat untuk pecahan/cluster MariaDB kami.

Menyebarkan Cluster Basis Data menggunakan ClusterControl

ClusterControl adalah alat otomatisasi untuk mengelola siklus hidup sistem manajemen basis data sumber terbuka Anda. Kami akan menggunakan ClusterControl sebagai alat terpusat untuk penyebaran cluster, manajemen topologi, dan pemantauan untuk tujuan posting blog ini.

1) Instal ClusterControl.

2) Konfigurasikan SSH tanpa kata sandi dari server ClusterControl ke semua node database. Pada simpul ClusterControl:

(clustercontrol)$ whoami
root
$ ssh-keygen -t rsa
$ ssh-copy-id [email protected]
$ ssh-copy-id [email protected]
$ ssh-copy-id [email protected]
$ ssh-copy-id [email protected]
$ ssh-copy-id [email protected]
$ ssh-copy-id [email protected]

3) Karena kita akan men-deploy 4 set cluster, sebaiknya gunakan alat CLI ClusterControl untuk tugas khusus ini guna mempercepat dan menyederhanakan proses penerapan. Mari kita verifikasi terlebih dahulu apakah kita dapat terhubung dengan kredensial default dengan menjalankan perintah berikut (kredensial default dikonfigurasi secara otomatis di /etc/s9s.conf):

(clustercontrol)$ s9s cluster --list --long
Total: 0

Jika kami tidak mendapatkan kesalahan apa pun dan melihat keluaran serupa seperti di atas, kami siap melakukannya.

4) Perhatikan bahwa langkah 4,5,6 dan 7 dapat dijalankan sekaligus karena ClusterControl mendukung penerapan paralel. Kami akan mulai dengan menerapkan server MariaDB Gateway pertama menggunakan ClusterControl CLI:

(clustercontrol)$ s9s cluster --create \
        --cluster-type=mysqlreplication \
        --nodes="192.168.22.101?master" \
        --vendor=mariadb \
        --provider-version=10.5 \
        --os-user=root \
        --os-key-file=/root/.ssh/id_rsa \
        --db-admin="root" \
        --db-admin-passwd="SuperS3cr3tPassw0rd" \
        --cluster-name="MariaDB Gateway 1"

5) Menerapkan server MariaDB Gateway kedua:

(clustercontrol)$ s9s cluster --create \
        --cluster-type=mysqlreplication \
        --nodes="192.168.22.102?master" \
        --vendor=mariadb \
        --provider-version=10.5 \
        --os-user=root \
        --os-key-file=/root/.ssh/id_rsa \
        --db-admin="root" \
        --db-admin-passwd="SuperS3cr3tPassw0rd" \
        --cluster-name="MariaDB Gateway 2"

6) Terapkan Replikasi MariaDB 2-simpul untuk pecahan pertama:

(clustercontrol)$ s9s cluster --create \
        --cluster-type=mysqlreplication \
        --nodes="192.168.22.111?master;192.168.22.112?slave" \
        --vendor=mariadb \
        --provider-version=10.5 \
        --os-user=root \
        --os-key-file=/root/.ssh/id_rsa \
        --db-admin="root" \
        --db-admin-passwd="SuperS3cr3tPassw0rd" \
        --cluster-name="MariaDB - Shard 1"

7) Menerapkan Replikasi MariaDB 2-simpul untuk pecahan kedua:

(clustercontrol)$ s9s cluster --create \
        --cluster-type=mysqlreplication \
        --nodes="192.168.22.121?master;192.168.22.122?slave" \
        --vendor=mariadb \
        --provider-version=10.5 \
        --os-user=root \
        --os-key-file=/root/.ssh/id_rsa \
        --db-admin="root" \
        --db-admin-passwd="SuperS3cr3tPassw0rd" \
        --cluster-name="MariaDB - Shard 2"

Sementara penerapan sedang berlangsung, kami dapat memantau keluaran tugas dari CLI:

(clustercontrol)$ s9s job --list --show-running
ID CID STATE   OWNER GROUP  CREATED  RDY TITLE
25   0 RUNNING admin admins 07:19:28  45% Create MySQL Replication Cluster
26   0 RUNNING admin admins 07:19:38  45% Create MySQL Replication Cluster
27   0 RUNNING admin admins 07:20:06  30% Create MySQL Replication Cluster
28   0 RUNNING admin admins 07:20:14  30% Create MySQL Replication Cluster

Dan juga dari UI ClusterControl:

Setelah penerapan selesai, Anda akan melihat sesuatu yang terdaftar di cluster database seperti ini di dasbor ClusterControl:

Kluster kami sekarang diterapkan dan menjalankan MariaDB 10.5 terbaru. Selanjutnya, kita perlu mengonfigurasi HAProxy untuk menyediakan satu titik akhir ke pecahan MariaDB.

Konfigurasi HAProxy

HAProxy diperlukan sebagai titik akhir tunggal untuk replikasi master-slave shard. Jika tidak, jika master down, seseorang harus memperbarui daftar server Spider menggunakan pernyataan CREATE OR REPLACE SERVER di server gateway, dan melakukan ALTER TABLE dan meneruskan parameter koneksi baru. Dengan HAProxy, kita dapat mengonfigurasinya untuk mendengarkan di host lokal server gateway dan memantau pecahan MariaDB yang berbeda dengan port yang berbeda. Kami akan mengkonfigurasi HAProxy di kedua server gateway sebagai berikut:

  • 127.0.0.1:3307 -> Shard1 (server backend adalah mariadb-shard-1a dan mariadb-shard- 1b)

  • 127.0.0.1:3308 -> Shard2 (server backend adalah mariadb-shard-2a dan mariadb-shard- 2b)

Jika master shard mati, ClusterControl akan melakukan failover pada slave shard sebagai master baru dan HAProxy akan merutekan ulang koneksi ke master baru yang sesuai. Kita akan menginstal HAProxy pada server gateway (mariadb-gw-1 dan mariadb-gw-2) menggunakan ClusterControl karena secara otomatis akan mengkonfigurasi server backend (setup mysqlchk, hibah pengguna, instalasi xinetd) dengan beberapa trik seperti yang ditunjukkan di bawah ini.

Pertama-tama, pada UI ClusterControl, pilih pecahan pertama, MariaDB - Shard 1 -> Manage -> Load Balancers -> HAProxy -> Deploy HAProxy dan tentukan Server Address sebagai 192.168.22.101 ( mariadb-gw-1), mirip dengan tangkapan layar berikut:

Demikian pula, tetapi yang ini untuk shard 2, buka MariaDB - Shard 2 -> Kelola -> Load Balancers -> HAProxy -> Deploy HAProxy dan tentukan Alamat Server sebagai 192.168.22.102 (mariadb-gw-2). Tunggu hingga penerapan selesai untuk kedua node HAProxy.

Sekarang kita perlu mengonfigurasi layanan HAProxy pada mariadb-gw-1 dan mariadb-gw-2 untuk memuat keseimbangan semua pecahan sekaligus. Menggunakan editor teks (atau ClusterControl UI -> Manage -> Configurations), edit 2 perintah "listen" terakhir dari /etc/haproxy/haproxy.cfg agar terlihat seperti ini:

listen  haproxy_3307_shard1
        bind *:3307
        mode tcp
        timeout client  10800s
        timeout server  10800s
        tcp-check connect port 9200
        tcp-check expect string master\ is\ running
        balance leastconn
        option tcp-check
        default-server port 9200 inter 2s downinter 5s rise 3 fall 2 slowstart 60s maxconn 64 maxqueue 128 weight 100
        server 192.168.22.111 192.168.22.111:3306 check # mariadb-shard-1a-master
        server 192.168.22.112 192.168.22.112:3306 check # mariadb-shard-1b-slave

listen  haproxy_3308_shard2
        bind *:3308
        mode tcp
        timeout client  10800s
        timeout server  10800s
        tcp-check connect port 9200
        tcp-check expect string master\ is\ running
        balance leastconn
        option tcp-check
        default-server port 9200 inter 2s downinter 5s rise 3 fall 2 slowstart 60s maxconn 64 maxqueue 128 weight 100
        server 192.168.22.121 192.168.22.121:3306 check # mariadb-shard-2a-master
        server 192.168.22.122 192.168.22.122:3306 check # mariadb-shard-2b-slave

Mulai ulang layanan HAProxy untuk memuat perubahan (atau gunakan ClusterControl -> Nodes -> HAProxy -> Restart Node):

$ systemctl restart haproxy

Dari UI ClusterControl, kami dapat memverifikasi bahwa hanya satu server backend yang aktif per shard (ditunjukkan dengan garis hijau), seperti yang ditunjukkan di bawah ini:

Pada titik ini, penyebaran cluster database kami sekarang selesai. Kita dapat melanjutkan untuk mengonfigurasi sharding MariaDB menggunakan mesin penyimpanan Spider.

Menyiapkan Server Gateway MariaDB

Di kedua server MariaDB Gateway (mariadb-gw-1 dan mariadb-gw-2), lakukan tugas berikut:

Instal plugin Spider:

MariaDB> INSTALL PLUGIN spider SONAME 'ha_spider.so';

Verifikasi apakah mesin penyimpanan didukung:

MariaDB> SELECT engine,support FROM information_schema.engines WHERE engine = 'spider';
+--------+---------+
| engine | support |
+--------+---------+
| SPIDER | YES     |
+--------+---------+

Secara opsional, kami juga dapat memverifikasi apakah plugin dimuat dengan benar dari database information_schema:

MariaDB> SELECT PLUGIN_NAME,PLUGIN_VERSION,PLUGIN_STATUS,PLUGIN_TYPE FROM information_schema.plugins WHERE plugin_name LIKE 'SPIDER%';
+--------------------------+----------------+---------------+--------------------+
| PLUGIN_NAME              | PLUGIN_VERSION | PLUGIN_STATUS | PLUGIN_TYPE        |
+--------------------------+----------------+---------------+--------------------+
| SPIDER                   | 3.3            | ACTIVE        | STORAGE ENGINE     |
| SPIDER_ALLOC_MEM         | 1.0            | ACTIVE        | INFORMATION SCHEMA |
| SPIDER_WRAPPER_PROTOCOLS | 1.0            | ACTIVE        | INFORMATION SCHEMA |
+--------------------------+----------------+---------------+--------------------+

Tambahkan baris berikut di bawah bagian [mysqld] di dalam file konfigurasi MariaDB:

plugin-load-add = ha_spider

Buat "node data" pertama untuk pecahan pertama yang harus dapat diakses melalui HAProxy 127.0.0.1 pada port 3307:

MariaDB> CREATE OR REPLACE SERVER Shard1 
FOREIGN DATA WRAPPER mysql
OPTIONS (
   HOST '127.0.0.1',
   DATABASE 'sbtest',
   USER 'spider',
   PASSWORD 'SpiderP455',
   PORT 3307);

Buat "node data" kedua untuk pecahan kedua yang harus dapat diakses melalui HAProxy 127.0.0.1 pada port 3308:

CREATE OR REPLACE SERVER Shard2 
FOREIGN DATA WRAPPER mysql
OPTIONS (
   HOST '127.0.0.1',
   DATABASE 'sbtest',
   USER 'spider',
   PASSWORD 'SpiderP455',
   PORT 3308);

Sekarang kita dapat membuat tabel Spider yang perlu dipartisi. Dalam contoh ini, kita akan membuat tabel bernama sbtest1 di dalam database sbtest, dan dipartisi dengan nilai integer di kolom 'k':

MariaDB> CREATE SCHEMA sbtest;
MariaDB> CREATE TABLE sbtest.sbtest1 (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `k` int(11) NOT NULL DEFAULT '0',
  `c` char(120) NOT NULL DEFAULT '',
  `pad` char(60) NOT NULL DEFAULT '',
  PRIMARY KEY (`id`, `k`)
)
  ENGINE=Spider
  COMMENT 'wrapper "mysql", table "sbtest1"'
  PARTITION BY RANGE (k) (
    PARTITION shard1 VALUES LESS THAN (499999) COMMENT = 'srv "Shard1"',
    PARTITION shard2 VALUES LESS THAN MAXVALUE COMMENT = 'srv "Shard2"'
);

Perhatikan bahwa klausa COMMENT ='srv "ShardX"' dari pernyataan CREATE TABLE sangat penting, tempat kami meneruskan informasi koneksi tentang server jauh. Nilai harus sama dengan nama server seperti pada pernyataan CREATE SERVER. Kami akan mengisi tabel ini menggunakan generator beban Sysbench seperti yang ditunjukkan di bawah ini.

Buat pengguna database aplikasi untuk mengakses database, dan izinkan dari server aplikasi:

MariaDB> CREATE USER [email protected]'192.168.22.%' IDENTIFIED BY 'passw0rd';
MariaDB> GRANT ALL PRIVILEGES ON sbtest.* TO [email protected]'192.168.22.%';

Dalam contoh ini, karena ini adalah jaringan internal tepercaya, kami hanya menggunakan karakter pengganti dalam pernyataan untuk mengizinkan alamat IP apa pun dalam rentang yang sama, 192.168.22.0/24.

Kami sekarang siap untuk mengonfigurasi node data kami.

Menyiapkan Server Shard MariaDB

Di kedua server master MariaDB Shard (mariadb-shard-1a dan mariadb-shard-2a), lakukan tugas berikut:

1) Buat database tujuan:

MariaDB> CREATE SCHEMA sbtest;

2) Buat pengguna 'spider' dan izinkan koneksi dari server gateway (mariadb-gw-1 dan mariadb-gw2). Pengguna ini harus memiliki semua hak istimewa pada tabel sharding dan juga database sistem MySQL :

MariaDB> CREATE USER 'spider'@'192.168.22.%' IDENTIFIED BY 'SpiderP455';
MariaDB> GRANT ALL PRIVILEGES ON sbtest.* TO [email protected]'192.168.22.%';
MariaDB> GRANT ALL ON mysql.* TO [email protected]'192.168.22.%';

Dalam contoh ini, karena ini adalah jaringan internal tepercaya, kami hanya menggunakan karakter pengganti dalam pernyataan untuk mengizinkan alamat IP apa pun dalam rentang yang sama, 192.168.22.0/24.

3) Buat tabel yang akan menerima data dari server gateway kami melalui mesin penyimpanan Spider. Tabel "penerima" ini dapat berada di mesin penyimpanan apa pun yang didukung oleh MariaDB. Dalam contoh ini, kami menggunakan mesin penyimpanan InnoDB:

MariaDB> CREATE TABLE sbtest.sbtest1 (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `k` int(11) NOT NULL DEFAULT '0',
  `c` char(120) NOT NULL DEFAULT '',
  `pad` char(60) NOT NULL DEFAULT '',
  PRIMARY KEY (`id`, `k`)
) ENGINE = INNODB;

Itu dia. Jangan lupa untuk mengulangi langkah-langkah di pecahan lainnya.

Pengujian

Untuk menguji menggunakan Sysbench untuk menghasilkan beberapa beban kerja database, pada server aplikasi, kita harus menginstal Sysbench terlebih dahulu:

$ yum install -y https://repo.percona.com/yum/percona-release-latest.noarch.rpm
$ yum install -y sysbench

Buat beberapa beban kerja pengujian dan kirimkan ke server gateway pertama, mariadb-gw-1 (192.168.11.101):

$ sysbench \
/usr/share/sysbench/oltp_insert.lua \
--report-interval=2 \
--threads=4 \
--rate=20 \
--time=9999 \
--db-driver=mysql \
--mysql-host=192.168.11.101 \
--mysql-port=3306 \
--mysql-user=sbtest \
--mysql-db=sbtest \
--mysql-password=passw0rd \
--tables=1 \
--table-size=1000000 \
run

Anda dapat mengulangi pengujian di atas pada mariadb-gw-2 (192.168.11.102) dan koneksi database harus diarahkan ke shard kanan yang sesuai.

Saat melihat pecahan pertama (mariadb-shard-1a atau mariadb-shard-1b), kita dapat mengetahui bahwa partisi ini hanya menampung baris dengan kunci pecahan (kolom k) lebih kecil dari 500000:

MariaDB [sbtest]> SELECT MIN(k),MAX(k) FROM sbtest1;
+--------+--------+
| min(k) | max(k) |
+--------+--------+
| 200175 | 499963 |
+--------+--------+

Pada pecahan lain (mariadb-shard-2a atau mariadb-shard-2b), ia menyimpan data dari 500000 hingga 999999 seperti yang diharapkan:

MariaDB [sbtest]> SELECT MIN(k),MAX(k) FROM sbtest1;
+--------+--------+
| min(k) | max(k) |
+--------+--------+
| 500067 | 999948 |
+--------+--------+

Sedangkan untuk server MariaDB Gateway (mariadb-gw-1 atau mariadb-gw-2), kita dapat melihat semua baris yang mirip dengan jika tabel ada di dalam instance MariaDB ini:

MariaDB [sbtest]> SELECT MIN(k),MAX(k) FROM sbtest1;
+--------+--------+
| min(k) | max(k) |
+--------+--------+
| 200175 | 999948 |
+--------+--------+

Untuk menguji pada aspek ketersediaan tinggi, ketika master shard tidak tersedia, misalnya ketika master (mariadb-shard-2a) dari shard 2 turun, ClusterControl akan secara otomatis melakukan promosi budak pada budak (mariadb-shard-2b) untuk menjadi master. Selama periode ini, Anda mungkin dapat melihat kesalahan ini:

ERROR 1429 (HY000) at line 1: Unable to connect to foreign data source: Shard2

Dan sementara tidak tersedia, Anda akan mendapatkan kesalahan berikut:

ERROR 1158 (08S01) at line 1: Got an error reading communication packets

Dalam pengukuran kami, failover memakan waktu sekitar 23 detik setelah failover dimulai dan setelah master baru dipromosikan, Anda seharusnya dapat menulis ke dalam tabel dari server gateway seperti biasa.

Kesimpulan

Pengaturan di atas adalah bukti prinsip tentang bagaimana ClusterControl dapat digunakan untuk menerapkan pengaturan sharded MariaDB. Ini juga dapat meningkatkan ketersediaan layanan penyiapan sharding MariaDB dengan fitur pemulihan node dan cluster otomatis, ditambah semua fitur manajemen dan pemantauan standar industri untuk mendukung infrastruktur database Anda secara keseluruhan.


  1. Database
    2.   
  2. Mysql
    3.   
  3. Oracle
    4.   
  4. Sqlserver
    5.   
  5. PostgreSQL
    6.   
  6. Access
    7.   
  7. SQLite
    8.   
  8. MariaDB

  1. Bagaimana SEKARANG () Bekerja di MariaDB

  2. 20 Tips:Siapkan Database Anda untuk Black Friday &Cyber ​​Monday

  3. Apa itu MariaDB Enterprise dan Bagaimana Cara Mengelolanya dengan ClusterControl?

  4. Panduan untuk Otomatisasi Basis Data dengan Kontrol Cluster Somenines

  5. Menjalankan MariaDB di Hybrid Cloud Setup