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

Mã hóa MariaDB đầy đủ khi nghỉ ngơi và đang chuyển để bảo vệ dữ liệu tối đa - Phần một

Trong loạt bài blog này, chúng tôi sẽ cung cấp cho bạn hướng dẫn đầy đủ về cách định cấu hình máy chủ MariaDB được mã hóa hoàn toàn để mã hóa lúc nghỉ và khi chuyển tiếp, để đảm bảo bảo vệ tối đa dữ liệu khỏi bị bị đánh cắp vật lý hoặc trong khi chuyển và giao tiếp với các máy chủ khác. Ý tưởng cơ bản là chúng tôi sẽ biến triển khai "đơn giản" của mình thành một bản sao MariaDB được mã hóa hoàn toàn, như được đơn giản hóa trong sơ đồ sau:

Chúng tôi sẽ định cấu hình một số thành phần mã hóa:

  • Mã hóa khi chuyển tiếp, bao gồm:
    • Mã hóa máy khách-máy chủ
    • Mã hóa sao chép
  • Mã hóa ở trạng thái nghỉ, bao gồm:
    • Mã hóa tệp dữ liệu
    • Mã hóa nhật ký nhị phân / chuyển tiếp.

Lưu ý rằng bài đăng trên blog này chỉ đề cập đến mã hóa khi chuyển tiếp. Chúng tôi sẽ đề cập đến mã hóa không hoạt động trong phần thứ hai của loạt blog này.

Hướng dẫn triển khai này giả định rằng chúng ta đã có một máy chủ sao chép MariaDB đang chạy. Nếu chưa có, bạn có thể sử dụng ClusterControl để triển khai bản sao MariaDB mới trong vòng vài phút, với ít hơn 5 lần nhấp. Tất cả các máy chủ đang chạy trên MariaDB 10.4.11 trên hệ thống CentOS 7.

Mã hóa In-Transit

Dữ liệu có thể chịu rủi ro cả khi đang chuyển và ở trạng thái nghỉ và cần được bảo vệ ở cả hai trạng thái. Mã hóa khi chuyển tiếp bảo vệ dữ liệu của bạn nếu liên lạc bị chặn trong khi dữ liệu di chuyển giữa các máy chủ thông qua mạng, từ trang web của bạn và nhà cung cấp đám mây, giữa các dịch vụ hoặc giữa máy khách và máy chủ.

Đối với MySQL / MariaDB, dữ liệu đang chuyển động khi máy khách kết nối với máy chủ cơ sở dữ liệu hoặc khi nút phụ sao chép dữ liệu từ nút chính. MariaDB hỗ trợ các kết nối được mã hóa giữa máy khách và máy chủ bằng giao thức TLS (Bảo mật lớp truyền tải). TLS đôi khi được gọi là SSL (Lớp cổng bảo mật) nhưng MariaDB không thực sự sử dụng giao thức SSL cho các kết nối được mã hóa vì mã hóa của nó yếu. Thêm chi tiết về điều này tại trang tài liệu MariaDB.

Mã hóa Máy khách-Máy chủ

Trong thiết lập này, chúng tôi sẽ sử dụng chứng chỉ tự ký, có nghĩa là chúng tôi không sử dụng các bên ngoài như Google, Comodo hoặc bất kỳ nhà cung cấp Tổ chức phát hành chứng chỉ phổ biến nào ngoài đó để xác minh danh tính của chúng tôi. Trong SSL / TLS, xác minh danh tính là bước đầu tiên phải được thông qua trước khi máy chủ và máy khách trao đổi chứng chỉ và khóa của họ.

MySQL cung cấp một công cụ rất tiện dụng được gọi là mysql_ssl_rsa_setup để xử lý tự động tạo khóa và chứng chỉ. Thật không may, vẫn chưa có công cụ này cho máy chủ MariaDB. Do đó, chúng tôi phải chuẩn bị và tạo các tệp liên quan đến SSL theo cách thủ công cho nhu cầu MariaDB TLS của chúng tôi.

Sau đây là danh sách các tệp mà chúng tôi sẽ tạo bằng công cụ OpenSSL:

  • Phím CA - Khóa riêng RSA ở định dạng PEM. Phải được giữ bí mật.
  • Chứng chỉ CA - Chứng chỉ X.509 ở định dạng PEM. Chứa khóa công khai và siêu dữ liệu chứng chỉ.
  • Máy chủ CSR - Yêu cầu đăng kí chứng chỉ. Tên Thông dụng (CN) khi điền vào biểu mẫu rất quan trọng, ví dụ:CN =mariadb-server
  • Khóa máy chủ - Khóa riêng RSA. Phải được giữ bí mật.
  • Chứng chỉ máy chủ - Chứng chỉ X.509 được ký bởi khóa CA. Chứa khóa công khai và siêu dữ liệu chứng chỉ.
  • CSR của khách hàng - Yêu cầu đăng kí chứng chỉ. Phải sử dụng Tên chung (CN) khác với CSR của máy chủ, ví dụ:CN =client1
  • Khóa ứng dụng - Khóa riêng RSA. Phải được giữ bí mật.
  • Chứng chỉ khách hàng - Chứng chỉ X.509 được ký bởi khóa CA. Chứa khóa công khai và siêu dữ liệu chứng chỉ.

Trước hết, hãy tạo một thư mục để lưu trữ chứng chỉ và khóa của chúng tôi để mã hóa khi chuyển tiếp:

$ mkdir -p /etc/mysql/transit/
$ cd /etc/mysql/transit/

Chỉ để bạn hiểu lý do tại sao chúng tôi đặt tên thư mục như đã đề cập là vì trong phần tiếp theo của loạt bài blog này, chúng tôi sẽ tạo một thư mục khác để mã hóa at-rest tại / etc / mysql / rest.

Tổ chức phát hành chứng chỉ

Tạo tệp khóa cho Tổ chức phát hành chứng chỉ (CA) của riêng chúng tôi:

$ openssl genrsa 2048 > ca-key.pem
Generating RSA private key, 2048 bit long modulus
.......................+++
...............................................................................................................................................................................................................................................+++
e is 65537 (0x10001)

Tạo chứng chỉ cho Tổ chức phát hành chứng chỉ (CA) của riêng chúng tôi dựa trên ca-key.pem được tạo trước đó với thời hạn 3650 ngày:

$ openssl req -new -x509 -nodes -days 3650 -key ca-key.pem -out ca.pem
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [XX]:SE
State or Province Name (full name) []:Stockholm
Locality Name (eg, city) [Default City]:Stockholm
Organization Name (eg, company) [Default Company Ltd]:Severalnines
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server's hostname) []:CA
Email Address []:[email protected]

Bây giờ chúng ta sẽ có ca-key.pem và ca.pem trong thư mục làm việc này.

Khóa và Chứng chỉ cho Máy chủ

Tiếp theo, tạo khóa riêng tư cho máy chủ MariaDB:

$ openssl genrsa 2048 > server-key.pem
Generating RSA private key, 2048 bit long modulus
.............................................................................................................+++
..................................................................................................................+++
e is 65537 (0x10001)

Chứng chỉ đáng tin cậy phải là chứng chỉ do Tổ chức phát hành chứng chỉ ký, theo đó ở đây, chúng tôi sẽ sử dụng CA của chính mình vì chúng tôi tin tưởng các máy chủ trong mạng. Trước khi có thể tạo chứng chỉ đã ký, chúng tôi cần tạo chứng chỉ yêu cầu được gọi là Yêu cầu ký chứng chỉ (CSR).

Tạo CSR cho máy chủ MariaDB. Chúng tôi sẽ gọi chứng chỉ là server-req.pem. Đây không phải là chứng chỉ mà chúng tôi sẽ sử dụng cho máy chủ MariaDB. Chứng chỉ cuối cùng là chứng chỉ sẽ được ký bằng khóa cá nhân CA của chính chúng tôi (như được hiển thị trong bước tiếp theo):

$ openssl req -new -key server-key.pem -out server-req.pem
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [XX]:SE
State or Province Name (full name) []:Stockholm
Locality Name (eg, city) [Default City]:Stockholm
Organization Name (eg, company) [Default Company Ltd]:Severalnines
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server's hostname) []:MariaDBServer
Email Address []:[email protected]

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

Lưu ý về Tên chung mà chúng tôi đã chỉ định "MariaDBServer". Đây có thể là bất kỳ tên nào nhưng giá trị không được giống với chứng chỉ ứng dụng khách. Thông thường, nếu các ứng dụng kết nối với máy chủ MariaDB qua FQDN hoặc tên máy chủ (bỏ qua tên-giải quyết =TẮT), bạn có thể muốn chỉ định FQDN của máy chủ MariaDB làm Tên chung.

Sau đó, chúng tôi có thể tạo chứng chỉ X.509 cuối cùng (server-cert.pem) và ký CSR (server-req.pem) bằng chứng chỉ của CA (ca.pem) và khóa riêng của CA (ca -key.pem):

$ openssl x509 -req -in server-req.pem -CA ca.pem -CAkey ca-key.pem -CAcreateserial -out server-cert.pem -days 3650 -sha256
Signature ok
subject=/C=SE/ST=Stockholm/L=Stockholm/O=Severalnines/CN=MariaDBServer/[email protected]
Getting CA Private Key

Tại thời điểm này, đây là những gì chúng ta có bây giờ:

$ ls -1 /etc/mysql/transite
ca-key.pem
ca.pem
server-cert.pem
server-key.pem
server-req.pem

Chúng tôi chỉ cần chứng chỉ CA (ca.pem), chứng chỉ đã ký của máy chủ (server-cert.pem) và khóa riêng của máy chủ (server-key.pem) cho máy chủ MariaDB. CSR (server-req.pem) không còn bắt buộc.

Khóa và Chứng chỉ cho Khách hàng

Tiếp theo, chúng ta cần tạo tệp khóa và chứng chỉ cho ứng dụng khách MariaDB. Máy chủ MariaDB sẽ chỉ chấp nhận kết nối từ xa từ máy khách có các tệp chứng chỉ này.

Bắt đầu bằng cách tạo khóa 2048 bit cho ứng dụng khách:

$ openssl genrsa 2048 > client-key.pem
Generating RSA private key, 2048 bit long modulus
.............................................................................................................+++
..................................................................................................................+++
e is 65537 (0x10001)

Tạo CSR cho ứng dụng khách được gọi là client-req.pem:

$ openssl req -new -key client-key.pem -out client-req.pem
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [XX]:SE
State or Province Name (full name) []:Stockholm
Locality Name (eg, city) [Default City]:Stockholm
Organization Name (eg, company) [Default Company Ltd]:Severalnines
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server's hostname) []:Client1
Email Address []:[email protected]

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

Hãy chú ý đến Tên chung mà chúng tôi chỉ định "Client1". Chỉ định bất kỳ tên nào đại diện cho khách hàng. Giá trị này phải khác với Tên chung của máy chủ. Để sử dụng nâng cao, bạn có thể sử dụng Tên chung này để cho phép một số người dùng có chứng chỉ khớp với giá trị này, ví dụ:

MariaDB> GRANT SELECT ON schema1.* TO 'client1'@'192.168.0.93' IDENTIFIED BY 's' REQUIRE SUBJECT '/CN=Client2';

Sau đó, chúng tôi có thể tạo chứng chỉ X.509 cuối cùng (client-cert.pem) và ký CSR (client-req.pem) bằng chứng chỉ của CA (ca.pem) và khóa riêng của CA (ca -key.pem):

$ openssl x509 -req -in client-req.pem -CA ca.pem -CAkey ca-key.pem -CAcreateserial -out client-cert.pem -days 3650 -sha256
Signature ok
subject=/C=SE/ST=Stockholm/L=Stockholm/O=Severalnines/CN=Client1/[email protected]
Getting CA Private Key

Tất cả các chứng chỉ mà chúng tôi cần để thiết lập mã hóa chuyển tiếp đều được tạo. Xác minh rằng cả hai chứng chỉ đều được CA ký chính xác:

$ openssl verify -CAfile ca.pem server-cert.pem client-cert.pem
server-cert.pem: OK
client-cert.pem: OK

Định cấu hình SSL cho MariaDB

Tạo một thư mục mới trên mọi nô lệ:

(slave1)$ mkdir -p /etc/mysql/transit/
(slave2)$ mkdir -p /etc/mysql/transit/

Sao chép các tệp mã hóa vào tất cả các nô lệ:

$ scp -r /etc/mysql/transit/* [email protected]:/etc/mysql/transit/
$ scp -r /etc/mysql/transit/* [email protected]:/etc/mysql/transit/

Đảm bảo rằng chủ sở hữu của thư mục chứng nhận thành người dùng "mysql" và thay đổi quyền của tất cả các tệp chính để nó sẽ không thể đọc được trên toàn cầu:

$ cd /etc/mysql/transit
$ chown -R mysql:mysql *
$ chmod 600 client-key.pem server-key.pem ca-key.pem

Đây là những gì bạn sẽ thấy khi liệt kê các tệp trong thư mục "chuyển tiếp":

$ ls -al /etc/mysql/transit
total 32
drwxr-xr-x. 2 root  root 172 Dec 14 04:42 .
drwxr-xr-x. 3 root  root 24 Dec 14 04:18 ..
-rw-------. 1 mysql mysql 1675 Dec 14 04:19 ca-key.pem
-rw-r--r--. 1 mysql mysql 1383 Dec 14 04:22 ca.pem
-rw-r--r--. 1 mysql mysql 1383 Dec 14 04:42 client-cert.pem
-rw-------. 1 mysql mysql 1675 Dec 14 04:42 client-key.pem
-rw-r--r--. 1 mysql mysql 1399 Dec 14 04:42 client-req.pem
-rw-r--r--. 1 mysql mysql 1391 Dec 14 04:34 server-cert.pem
-rw-------. 1 mysql mysql 1679 Dec 14 04:28 server-key.pem
-rw-r--r--. 1 mysql mysql 1415 Dec 14 04:31 server-req.pem

Tiếp theo, chúng tôi sẽ kích hoạt kết nối SSL cho MariaDB. Trên mọi máy chủ MariaDB (chính và các máy chủ), hãy chỉnh sửa tệp cấu hình và thêm các dòng sau trong phần [mysqld]:

ssl-ca=/etc/mysql/transit/ca.pem
ssl-cert=/etc/mysql/transit/server-cert.pem
ssl-key=/etc/mysql/transit/server-key.pem

Khởi động lại máy chủ MariaDB từng nút một, bắt đầu từ các nô lệ và cuối cùng là trên chính:

(slave1)$ systemctl restart mariadb
(slave2)$ systemctl restart mariadb
(master)$ systemctl restart mariadb

Sau khi khởi động lại, MariaDB hiện có khả năng chấp nhận các kết nối thuần túy bằng cách kết nối với nó mà không có bất kỳ tham số nào liên quan đến SSL hoặc với các kết nối được mã hóa, khi bạn chỉ định tham số liên quan đến SSL trong chuỗi kết nối.

Đối với người dùng ClusterControl, bạn có thể bật mã hóa máy khách-máy chủ chỉ bằng một cú nhấp chuột. Chỉ cần vào ClusterControl -> Security -> SSL Encryption -> Enable -> Create Certificate -> Certificate Expiration -> Enable SSL:

ClusterControl sẽ tạo các khóa cần thiết, chứng chỉ X.509 và chứng chỉ CA và thiết lập mã hóa SSL cho các kết nối máy khách-máy chủ cho tất cả các nút trong cụm. Đối với sao chép MySQL / MariaDB, các tệp SSL sẽ được đặt trong / etc / ssl / replication / cluster_X, trong đó X là ID cụm trên mọi nút cơ sở dữ liệu. Các chứng chỉ giống nhau sẽ được sử dụng trên tất cả các nút và những chứng chỉ hiện có có thể bị ghi đè. Các nút phải được khởi động lại riêng lẻ sau khi công việc này hoàn thành. Chúng tôi khuyên bạn trước tiên nên khởi động lại nô lệ sao chép và xác minh rằng cài đặt SSL hoạt động.

Để khởi động lại mọi nút, hãy đi tới ClusterControl -> Nodes -> Node Actions -> Restart Node. Khởi động lại từng nút một, bắt đầu với các nô lệ. Nút cuối cùng phải là nút chính với cờ dừng buộc được bật:

Bạn có thể biết liệu một nút có thể xử lý mã hóa máy khách-máy chủ hay không bằng cách nhìn vào biểu tượng ổ khóa màu xanh lục ngay bên cạnh nút cơ sở dữ liệu trong lưới Tổng quan:

Tại thời điểm này, cụm của chúng ta hiện đã sẵn sàng chấp nhận kết nối SSL từ MySQL người dùng.

Kết nối qua Kết nối được Mã hóa

Máy khách MariaDB yêu cầu tất cả các tệp SSL liên quan đến máy khách mà chúng tôi đã tạo bên trong máy chủ. Sao chép chứng chỉ ứng dụng khách, chứng chỉ CA và khóa ứng dụng đã tạo vào máy chủ khách hàng:

$ cd /etc/mysql/transit
$ scp client-cert.pem client-key.pem ca.pem [email protected]:~

** ClusterControl tạo tệp SSL ứng dụng khách trong / etc / ssl / replication / cluster_X / trên mọi nút cơ sở dữ liệu, trong đó X là ID cụm.

Tạo người dùng cơ sở dữ liệu yêu cầu SSL trên cái chính:

MariaDB> CREATE SCHEMA sbtest;
MariaDB> CREATE USER [email protected]'%' IDENTIFIED BY 'mysecr3t' REQUIRE SSL;
MariaDB> GRANT ALL PRIVILEGES ON sbtest.* to [email protected]'%';

Từ máy khách, kết nối với máy chủ MariaDB với các tham số liên quan đến SSL. Chúng tôi có thể xác minh trạng thái kết nối bằng cách sử dụng câu lệnh "STATUS":

(client)$ mysql -usbtest -p -h192.168.0.91 -P3306 --ssl-cert client-cert.pem --ssl-key client-key.pem --ssl-ca ca.pem -e 'status'
...
Current user: [email protected]
SSL: Cipher in use is DHE-RSA-AES256-GCM-SHA384
...

Hãy chú ý đến dòng SSL nơi mật mã được sử dụng để mã hóa. Điều này có nghĩa là máy khách được kết nối thành công với máy chủ MariaDB thông qua kết nối được mã hóa.

Tại thời điểm này, chúng tôi đã mã hóa kết nối máy khách-máy chủ với máy chủ MariaDB, như được biểu thị bằng mũi tên hai đầu màu xanh lục trong sơ đồ sau:

Trong phần tiếp theo, chúng ta sẽ mã hóa các kết nối sao chép giữa các nút.

Mã hóa Sao chép

Thiết lập các kết nối được mã hóa để nhân rộng tương tự như làm như vậy đối với các kết nối máy khách / máy chủ. Chúng tôi có thể sử dụng cùng một chứng chỉ ứng dụng khách, khóa và chứng chỉ CA để cho phép người dùng sao chép truy cập vào máy chủ chính thông qua kênh mã hóa. Điều này sẽ gián tiếp cho phép mã hóa giữa các nút khi luồng IO phụ kéo các sự kiện sao chép từ chính.

Hãy cấu hình điều này trên một nô lệ tại một thời điểm. Đối với nô lệ đầu tiên, 192.168.0.92, hãy thêm dòng sau trong phần [client] bên trong tệp cấu hình MariaDB:

[client]
ssl-ca=/etc/mysql/transit/ca.pem
ssl-cert=/etc/mysql/transit/client-cert.pem
ssl-key=/etc/mysql/transit/client-key.pem

Dừng chuỗi sao chép trên máy chủ:

(slave)MariaDB> STOP SLAVE;

Trên trang cái, hãy thay đổi người dùng sao chép hiện có để buộc người dùng đó kết nối bằng SSL:

(master)MariaDB> ALTER USER [email protected] REQUIRE SSL;

Trên máy chủ, kiểm tra kết nối với máy chủ, 192.168.0.91 thông qua dòng lệnh mysql với cờ --ssl:

(slave)MariaDB> mysql -urpl_user -p -h192.168.0.91 -P 3306 --ssl -e 'status'
...
Current user: [email protected]
SSL: Cipher in use is DHE-RSA-AES256-GCM-SHA384
...

Đảm bảo rằng bạn có thể kết nối với máy chủ chính mà không gặp lỗi. Sau đó, trên máy chủ, chỉ định câu lệnh CHANGE MASTER với các tham số SSL như bên dưới:

(slave)MariaDB> CHANGE MASTER TO MASTER_SSL = 1, MASTER_SSL_CA = '/etc/mysql/transit/ca.pem', MASTER_SSL_CERT = '/etc/mysql/transit/client-cert.pem', MASTER_SSL_KEY = '/etc/mysql/transit/client-key.pem';

Bắt đầu sao chép nô lệ:

(slave)MariaDB> START SLAVE;

Xác minh rằng bản sao đang chạy ổn với các thông số SSL liên quan:

MariaDB> SHOW SLAVE STATUS\G
...
              Slave_IO_Running: Yes
             Slave_SQL_Running: Yes
            Master_SSL_Allowed: Yes
            Master_SSL_CA_File: /etc/mysql/transit/ca.pem
               Master_SSL_Cert: /etc/mysql/transit/client-cert.pem
                Master_SSL_Key: /etc/mysql/transit/client-key.pem
...

Nô lệ hiện đang sao chép từ chính một cách an toàn thông qua mã hóa TLS.

Lặp lại tất cả các bước trên trên nô lệ còn lại, 192.168.0.93. Sự khác biệt duy nhất là câu lệnh người dùng thay thế sẽ được thực thi trên máy chủ mà chúng ta phải thay đổi thành máy chủ tương ứng của nó:

(master)MariaDB> ALTER USER [email protected] REQUIRE SSL;

Tại thời điểm này, chúng tôi đã hoàn thành mã hóa khi chuyển tiếp như được minh họa bằng các đường màu xanh lục từ chủ đến nô lệ trong sơ đồ sau:

Bạn có thể xác minh kết nối mã hóa bằng cách xem đầu ra tcpdump cho giao diện eth1 trên nô lệ. Sau đây là một ví dụ về sao chép tiêu chuẩn mà không cần mã hóa:

(plain-slave)$ tcpdump -i eth1 -s 0 -l -w - 'src port 3306 or dst port 3306' | strings
tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes
H"-'
binlog.000008Ulw
binlog.000008Ulw
sbtest
sbtest
create table t1 (id INT AUTO_INCREMENT PRIMARY KEY, data VARCHAR(255))
binlog.000008
sbtest
BEGIN3
sbtest
test data3
Ok*Z
binlog.000008*Z

^C11 packets captured
11 packets received by filter
0 packets dropped by kernel

Chúng ta có thể thấy rõ ràng văn bản được đọc bởi nô lệ từ chủ nhân. Trong khi sử dụng kết nối được mã hóa, bạn sẽ thấy các ký tự vô nghĩa như bên dưới:

(encrypted-slave)$ tcpdump -i eth1 -s 0 -l -w - 'src port 3306 or dst port 3306' | strings
tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes
:|f^yb#
O5~_
@#PFh
k)]O
jtk3c
@NjN9_a
!\[email protected]
NrF
?7&Y

^C6 packets captured
6 packets received by filter
0 packets dropped by kernel

Kết luận

Trong phần tiếp theo của loạt bài blog này, chúng ta sẽ xem xét việc hoàn thành thiết lập được mã hóa hoàn toàn với mã hóa MariaDB at-rest. Hãy theo dõi!


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Hàm MIN () trong MariaDB

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

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

  4. Giới thiệu Giám sát cơ sở dữ liệu dựa trên tác nhân với ClusterControl 1.7

  5. Cách hoạt động của WEEK () trong MariaDB