MariaDB
 sql >> Cơ Sở Dữ Liệu >  >> RDS >> MariaDB

Triển khai MariaDB Sharding với Spider bằng ClusterControl

MariaDB cung cấp khả năng sharding đa máy chủ được tích hợp sẵn với công cụ lưu trữ Spider. Spider hỗ trợ phân vùng và các giao dịch XA và cho phép các bảng từ xa của các phiên bản MariaDB khác nhau được xử lý như thể chúng trên cùng một phiên bản. Bảng từ xa có thể là của bất kỳ công cụ lưu trữ nào. Liên kết bảng đạt được bằng cách thiết lập kết nối từ máy chủ MariaDB cục bộ đến máy chủ MariaDB từ xa và liên kết được chia sẻ cho tất cả các bảng là một phần của cùng một giao dịch.

Trong bài đăng trên blog này, chúng tôi sẽ hướng dẫn bạn cách triển khai một cụm gồm hai mảnh MariaDB bằng ClusterControl. Chúng tôi sẽ triển khai một số ít máy chủ MariaDB (để dự phòng và khả dụng) để lưu trữ bảng được phân vùng dựa trên phạm vi của khóa phân đoạn đã chọn. Khóa phân đoạn được chọn về cơ bản là một cột lưu trữ các giá trị có giới hạn dưới và trên, như trong trường hợp này là các giá trị nguyên từ 0 đến 1.000.000, làm cho nó trở thành khóa ứng viên tốt nhất để cân bằng phân phối dữ liệu giữa hai phân đoạn. Do đó, chúng tôi sẽ chia phạm vi thành hai phân vùng:

  • 0 - 499999:Phân đoạn 1

  • 500000 - 1000000:Phân đoạn 2

Sơ đồ sau minh họa kiến ​​trúc cấp cao của chúng tôi về những gì chúng tôi sẽ triển khai:

Một số giải thích về sơ đồ:

  1. mariadb-gw-1:Phiên bản MariaDB chạy công cụ lưu trữ Spider, hoạt động giống như một bộ định tuyến phân đoạn. Chúng tôi đặt tên cho máy chủ này là MariaDB Gateway 1 và đây sẽ là máy chủ MariaDB chính (đang hoạt động) để tiếp cận các phân đoạn. Ứng dụng sẽ kết nối với máy chủ này giống như kết nối MariaDB tiêu chuẩn. Nút này kết nối với các phân đoạn thông qua nghe HAProxy trên 127.0.0.1 cổng 3307 (phân đoạn1) và 3308 (phân đoạn 2).

  2. mariadb-gw-2:Phiên bản MariaDB chạy công cụ lưu trữ Spider, hoạt động giống như một bộ định tuyến phân đoạn. Chúng tôi đặt tên cho máy chủ này là MariaDB Gateway 2 và đây sẽ là máy chủ MariaDB thứ cấp (thụ động) để tiếp cận các phân đoạn. Nó sẽ có thiết lập tương tự như mariadb-gw-1. Ứng dụng sẽ chỉ kết nối với máy chủ này nếu MariaDB chính bị lỗi. Nút này kết nối với các phân đoạn thông qua nghe HAProxy trên 127.0.0.1 cổng 3307 (phân đoạn1) và 3308 (phân đoạn 2).

  3. mariadb-shard-1a:MariaDB master đóng vai trò là nút dữ liệu chính cho phân vùng đầu tiên. Máy chủ cổng MariaDB chỉ nên ghi vào phân đoạn chính của phân đoạn.

  4. mariadb-shard-1b:Bản sao MariaDB đóng vai trò là nút dữ liệu phụ cho phân vùng đầu tiên. Nó sẽ đảm nhận vai trò chính trong trường hợp phân đoạn chính của phân đoạn gặp sự cố (chuyển đổi dự phòng tự động được quản lý bởi ClusterControl).

  5. mariadb-shard-2a:MariaDB cái đóng vai trò là nút dữ liệu chính cho phân vùng thứ hai. Máy chủ cổng MariaDB chỉ ghi vào phân đoạn chính.

  6. mariadb-shard-2b:Bản sao MariaDB đóng vai trò là nút dữ liệu phụ cho phân vùng thứ hai. Nó sẽ đảm nhận vai trò chính trong trường hợp phân đoạn chính của phân đoạn gặp sự cố (chuyển đổi dự phòng tự động được quản lý bởi ClusterControl).

  7. ClusterControl:Một công cụ triển khai, quản lý và giám sát tập trung cho các phân đoạn / cụm MariaDB của chúng tôi.

Triển khai Cụm cơ sở dữ liệu bằng ClusterControl

ClusterControl là một công cụ tự động hóa để quản lý vòng đời của hệ thống quản lý cơ sở dữ liệu nguồn mở của bạn. Chúng tôi sẽ sử dụng ClusterControl như một công cụ tập trung để triển khai cụm, quản lý và giám sát cấu trúc liên kết cho mục đích của bài đăng trên blog này.

1) Cài đặt ClusterControl.

2) Định cấu hình SSH không cần mật khẩu từ máy chủ ClusterControl tới tất cả các nút cơ sở dữ liệu. Trên nút 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) Vì chúng ta sẽ triển khai 4 nhóm cụm, bạn nên sử dụng công cụ ClusterControl CLI cho tác vụ cụ thể này để đẩy nhanh và đơn giản hóa quá trình triển khai. Trước tiên, hãy xác minh xem chúng ta có thể kết nối với thông tin đăng nhập mặc định hay không bằng cách chạy lệnh sau (thông tin đăng nhập mặc định được định cấu hình tự động tại /etc/s9s.conf):

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

Nếu chúng tôi không gặp bất kỳ lỗi nào và thấy kết quả tương tự như trên, chúng tôi có thể tiếp tục.

4) Lưu ý rằng các bước 4,5,6 và 7 có thể được thực hiện cùng một lúc vì ClusterControl hỗ trợ triển khai song song. Chúng tôi sẽ bắt đầu bằng cách triển khai máy chủ MariaDB Gateway đầu tiên sử dụng 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) Triển khai máy chủ MariaDB Gateway thứ hai:

(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) Triển khai Bản sao MariaDB 2 nút cho phân đoạn đầu tiên:

(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) Triển khai Bản sao MariaDB 2 nút cho phân đoạn thứ hai:

(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"

Trong khi việc triển khai đang diễn ra, chúng tôi có thể theo dõi kết quả công việc từ 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

Và cả từ giao diện người dùng ClusterControl:

Sau khi triển khai hoàn tất, bạn sẽ thấy thông tin về các cụm cơ sở dữ liệu được liệt kê như thế này trong bảng điều khiển ClusterControl:

Các cụm của chúng tôi hiện đã được triển khai và chạy MariaDB 10.5 mới nhất. Tiếp theo, chúng ta cần định cấu hình HAProxy để cung cấp một điểm cuối duy nhất cho các phân đoạn MariaDB.

Định cấu hình HAProxy

HAProxy cần thiết như một điểm cuối duy nhất để sao chép chủ-tớ của phân đoạn. Ngược lại, nếu máy chủ gặp sự cố, người ta phải cập nhật danh sách máy chủ của Spider bằng cách sử dụng câu lệnh CREATE HOẶC THAY THẾ MÁY CHỦ trong máy chủ cổng và thực hiện ALTER TABLE và chuyển một tham số kết nối mới. Với HAProxy, chúng ta có thể định cấu hình nó để lắng nghe trên máy chủ cục bộ của máy chủ cổng và theo dõi các phân đoạn MariaDB khác nhau với các cổng khác nhau. Chúng tôi sẽ định cấu hình HAProxy trên cả hai máy chủ cổng như sau:

  • 127.0.0.1:3307 -> Shard1 (các máy chủ phụ trợ là mariadb-shard-1a và mariadb-shard- 1b)

  • 127.0.0.1:3308 -> Shard2 (máy chủ phụ trợ là mariadb-shard-2a và mariadb-shard- 2b)

Trong trường hợp cái chính của phân đoạn gặp sự cố, ClusterControl sẽ chuyển đổi dự phòng nô lệ của phân đoạn đó như là cái chính mới và HAProxy sẽ định tuyến lại các kết nối tới cái chính mới tương ứng. Chúng tôi sẽ cài đặt HAProxy trên các máy chủ cổng (mariadb-gw-1 và mariadb-gw-2) bằng cách sử dụng ClusterControl vì nó sẽ tự động cấu hình các máy chủ phụ trợ (thiết lập mysqlchk, tài trợ người dùng, cài đặt xinetd) bằng một số thủ thuật như được hiển thị bên dưới.

Trước hết, trên giao diện người dùng ClusterControl, chọn phân đoạn đầu tiên, MariaDB - Phân đoạn 1 -> Quản lý -> Bộ cân bằng tải -> HAProxy -> Triển khai HAProxy và chỉ định Địa chỉ máy chủ là 192.168.22.101 ( mariadb-gw-1), tương tự như ảnh chụp màn hình sau:

Tương tự, nhưng cái này dành cho phân đoạn 2, hãy chuyển đến MariaDB - Phân đoạn 2 -> Quản lý -> Bộ cân bằng tải -> HAProxy -> Triển khai HAProxy và chỉ định Địa chỉ máy chủ là 192.168.22.102 (mariadb-gw-2). Chờ cho đến khi quá trình triển khai kết thúc cho cả hai nút HAProxy.

Bây giờ chúng ta cần định cấu hình dịch vụ HAProxy trên mariadb-gw-1 và mariadb-gw-2 để cân bằng tải tất cả các phân đoạn cùng một lúc. Sử dụng trình soạn thảo văn bản (hoặc Giao diện người dùng ClusterControl -> Quản lý -> Cấu hình), chỉnh sửa 2 lệnh "nghe" cuối cùng của /etc/haproxy/haproxy.cfg để trông giống như sau:

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

Khởi động lại dịch vụ HAProxy để tải các thay đổi (hoặc sử dụng ClusterControl -> Nodes -> HAProxy -> Restart Node):

$ systemctl restart haproxy

Từ Giao diện người dùng ClusterControl, chúng tôi có thể xác minh rằng chỉ một máy chủ phụ trợ đang hoạt động trên mỗi phân đoạn (được biểu thị bằng các đường màu xanh lục), như được hiển thị bên dưới:

Tại thời điểm này, việc triển khai cụm cơ sở dữ liệu của chúng ta đã hoàn tất. Chúng tôi có thể tiến hành định cấu hình sharding MariaDB bằng cách sử dụng công cụ lưu trữ Spider.

Chuẩn bị Máy chủ Cổng MariaDB

Trên cả hai máy chủ MariaDB Gateway (mariadb-gw-1 và mariadb-gw-2), thực hiện các tác vụ sau:

Cài đặt plugin Spider:

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

Xác minh xem công cụ lưu trữ có được hỗ trợ không:

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

Theo tùy chọn, chúng tôi cũng có thể xác minh xem plugin được tải đúng cách từ cơ sở dữ liệu 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 |
+--------------------------+----------------+---------------+--------------------+

Thêm dòng sau vào phần [mysqld] bên trong tệp cấu hình MariaDB:

plugin-load-add = ha_spider

Tạo "nút dữ liệu" đầu tiên cho phân đoạn đầu tiên có thể truy cập được qua HAProxy 127.0.0.1 trên cổng 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);

Tạo "nút dữ liệu" thứ hai cho phân đoạn thứ hai có thể truy cập được qua HAProxy 127.0.0.1 trên cổng 3308:

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

Bây giờ chúng ta có thể tạo một bảng Spider cần được phân vùng. Trong ví dụ này, chúng ta sẽ tạo một bảng có tên sbtest1 bên trong cơ sở dữ liệu sbtest và được phân vùng bằng giá trị số nguyên trong cột '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"'
);

Lưu ý rằng mệnh đề COMMENT ='srv "ShardX"' của câu lệnh CREATE TABLE là rất quan trọng, nơi chúng tôi chuyển thông tin kết nối về máy chủ từ xa. Giá trị phải giống với tên máy chủ như trong câu lệnh CREATE SERVER. Chúng ta sẽ điền vào bảng này bằng cách sử dụng trình tạo tải Sysbench như được hiển thị thêm bên dưới.

Tạo người dùng cơ sở dữ liệu ứng dụng để truy cập cơ sở dữ liệu và cho phép nó từ máy chủ ứng dụng:

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

Trong ví dụ này, vì đây là mạng nội bộ đáng tin cậy, chúng tôi chỉ sử dụng ký tự đại diện trong câu lệnh để cho phép bất kỳ địa chỉ IP nào trong cùng dải, 192.168.22.0/24.

Bây giờ chúng tôi đã sẵn sàng định cấu hình các nút dữ liệu của mình.

Chuẩn bị Máy chủ Mảnh MariaDB

Trên cả hai máy chủ chính MariaDB Shard (mariadb-shard-1a và mariadb-shard-2a), thực hiện các tác vụ sau:

1) Tạo cơ sở dữ liệu đích:

MariaDB> CREATE SCHEMA sbtest;

2) Tạo người dùng 'spider' và cho phép kết nối từ các máy chủ cổng (mariadb-gw-1 và mariadb-gw2). Người dùng này phải có tất cả các đặc quyền trên bảng đã phân đoạn và cả cơ sở dữ liệu hệ thống 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.%';

Trong ví dụ này, vì đây là mạng nội bộ đáng tin cậy, chúng tôi chỉ sử dụng ký tự đại diện trong câu lệnh để cho phép bất kỳ địa chỉ IP nào trong cùng dải, 192.168.22.0/24.

3) Tạo bảng sẽ nhận dữ liệu từ các máy chủ cổng của chúng tôi thông qua công cụ lưu trữ Spider. Bảng "bộ thu" này có thể nằm trên bất kỳ công cụ lưu trữ nào được hỗ trợ bởi MariaDB. Trong ví dụ này, chúng tôi sử dụng công cụ lưu trữ 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;

Vậy là xong. Đừng quên lặp lại các bước trên phân đoạn khác.

Thử nghiệm

Để kiểm tra việc sử dụng Sysbench để tạo một số khối lượng công việc cơ sở dữ liệu, trên máy chủ ứng dụng, chúng ta phải cài đặt Sysbench trước:

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

Tạo một số khối lượng công việc thử nghiệm và gửi chúng đến máy chủ cổng đầu tiên, 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

Bạn có thể lặp lại kiểm tra trên trên mariadb-gw-2 (192.168.11.102) và các kết nối cơ sở dữ liệu phải được chuyển đến đúng phân đoạn tương ứng.

Khi nhìn vào phân đoạn đầu tiên (mariadb-shard-1a hoặc mariadb-shard-1b), chúng ta có thể biết rằng phân vùng này chỉ chứa các hàng có khóa phân đoạn (cột k) nhỏ hơn 500000:

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

Trên một phân đoạn khác (mariadb-shard-2a hoặc mariadb-shard-2b), nó chứa dữ liệu từ 500000 đến 999999 như mong đợi:

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

Trong khi đối với máy chủ MariaDB Gateway (mariadb-gw-1 hoặc mariadb-gw-2), chúng ta có thể thấy tất cả các hàng tương tự như nếu bảng tồn tại bên trong phiên bản MariaDB này:

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

Để kiểm tra khía cạnh tính khả dụng cao, khi một phân đoạn chính không khả dụng, chẳng hạn như khi phân đoạn chính (mariadb-shard-2a) của phân đoạn 2 gặp sự cố, ClusterControl sẽ tự động thực hiện quảng cáo phụ trên nô lệ (mariadb-shard-2b) để trở thành chủ nhân. Trong khoảng thời gian này, bạn có thể gặp lỗi này:

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

Và mặc dù không có sẵn, bạn sẽ gặp lỗi tiếp theo sau:

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

Theo phép đo của chúng tôi, quá trình chuyển đổi dự phòng mất khoảng 23 giây sau khi bắt đầu chuyển đổi dự phòng và khi bản chính mới được thăng cấp, bạn sẽ có thể ghi vào bảng từ máy chủ cổng như bình thường.

Kết luận

Thiết lập trên là bằng chứng về nguyên tắc về cách ClusterControl có thể được sử dụng để triển khai thiết lập phân đoạn MariaDB. Nó cũng có thể cải thiện tính khả dụng dịch vụ của thiết lập MariaDB sharding với tính năng khôi phục nút và cụm tự động, cộng với tất cả các tính năng giám sát và quản lý theo tiêu chuẩn ngành để hỗ trợ cơ sở hạ tầng cơ sở dữ liệu tổng thể của bạn.


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

  1. 2 cách trả lại mã ASCII cho một ký tự đã cho trong MariaDB

  2. Cách REGEXP_REPLACE () hoạt động trong MariaDB

  3. Cách RIGHT () hoạt động trong MariaDB

  4. Trừ một tháng cho một ngày trong MariaDB

  5. Cách NOT RLIKE hoạt động trong MariaDB