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

Chạy một cụm MariaDB Galera mà không cần công cụ điều phối - Quản lý vùng chứa DB:Phần thứ hai

Như chúng ta đã thấy trong phần đầu của blog này, một cụm cơ sở dữ liệu nhất quán mạnh mẽ như Galera không hoạt động tốt với các công cụ điều phối vùng chứa như Kubernetes hoặc Swarm. Chúng tôi đã chỉ cho bạn cách triển khai Galera và định cấu hình quản lý quy trình cho Docker, vì vậy bạn có toàn quyền kiểm soát hành vi. Bài đăng trên blog này là sự tiếp nối của điều đó, chúng tôi sẽ xem xét hoạt động và bảo trì của cụm.

Để tóm tắt một số điểm chính từ phần 1 của blog này, chúng tôi đã triển khai một cụm Galera ba nút, với ProxySQL và Keepalived trên ba máy chủ Docker khác nhau, nơi tất cả các phiên bản MariaDB chạy dưới dạng vùng chứa Docker. Sơ đồ sau minh họa việc triển khai cuối cùng:

Tắt máy có duyên

Để thực hiện tắt MySQL duyên dáng, cách tốt nhất là gửi SIGTERM (tín hiệu 15) đến vùng chứa:

$ docker kill -s 15 {db_container_name}

Nếu bạn muốn tắt cụm, hãy lặp lại lệnh trên trên tất cả các vùng chứa cơ sở dữ liệu, mỗi lần một nút. Ở trên tương tự như thực hiện "systemctl stop mysql" trong dịch vụ systemd cho MariaDB. Sử dụng lệnh "docker stop" là khá rủi ro cho dịch vụ cơ sở dữ liệu vì nó đợi 10 giây hết thời gian và Docker sẽ buộc SIGKILL nếu thời lượng này bị vượt quá (trừ khi bạn sử dụng --timeout phù hợp giá trị).

Nút cuối cùng tắt một cách duyên dáng sẽ có seqno không bằng -1 và safe_to_bootstrap cờ được đặt thành 1 trong / {datadir volume} /grastate.dat của máy chủ Docker, ví dụ trên host2:

$ cat /containers/mariadb2/datadir/grastate.dat
# GALERA saved state
version: 2.1
uuid:    e70b7437-645f-11e8-9f44-5b204e58220b
seqno:   7099
safe_to_bootstrap: 1

Phát hiện nút nâng cao nhất

Nếu cụm không tắt một cách duyên dáng hoặc nút mà bạn đang cố gắng bootstrap không phải là nút cuối cùng rời khỏi cụm, có thể bạn sẽ không thể khởi động một trong các nút Galera và có thể gặp phải lỗi sau :

2016-11-07 01:49:19 5572 [ERROR] WSREP: It may not be safe to bootstrap the cluster from this node.
It was not the last one to leave the cluster and may not contain all the updates.
To force cluster bootstrap with this node, edit the grastate.dat file manually and set safe_to_bootstrap to 1 .

Galera tôn vinh nút có safe_to_bootstrap cờ được đặt thành 1 làm nút tham chiếu đầu tiên. Đây là cách an toàn nhất để tránh mất dữ liệu và đảm bảo đúng nút luôn được khởi động.

Nếu bạn gặp lỗi, chúng tôi phải tìm ra nút nâng cao nhất trước khi chọn nút đầu tiên được khởi động. Tạo vùng chứa tạm thời (với --rm cờ), ánh xạ nó vào cùng một thư mục cấu hình và dữ liệu của vùng chứa cơ sở dữ liệu thực tế với hai cờ lệnh MySQL, --wsrep_recover và --wsrep_cluster_address . Ví dụ:nếu chúng ta muốn biết số đã cam kết cuối cùng của mariadb1, chúng ta cần chạy:

$ docker run --rm --name mariadb-recover \
        --env MYSQL_ROOT_PASSWORD="PM7%[email protected]^1" \
        --volume /containers/mariadb1/datadir:/var/lib/mysql \
        --volume /containers/mariadb1/conf.d:/etc/mysql/conf.d \
        mariadb:10.2.15 \
        --wsrep_recover \
        --wsrep_cluster_address=gcomm://
2018-06-12  4:46:35 139993094592384 [Note] mysqld (mysqld 10.2.15-MariaDB-10.2.15+maria~jessie) starting as process 1 ...
2018-06-12  4:46:35 139993094592384 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
...
2018-06-12  4:46:35 139993094592384 [Note] Plugin 'FEEDBACK' is disabled.
2018-06-12  4:46:35 139993094592384 [Note] Server socket created on IP: '::'.
2018-06-12  4:46:35 139993094592384 [Note] WSREP: Recovered position: e70b7437-645f-11e8-9f44-5b204e58220b:7099

Dòng cuối cùng là những gì chúng tôi đang tìm kiếm. MariaDB in ra UUID cụm và số thứ tự của giao dịch được cam kết gần đây nhất. Nút có số lượng cao nhất được coi là nút tiên tiến nhất. Vì chúng tôi đã chỉ định --rm , vùng chứa sẽ tự động bị xóa khi thoát. Lặp lại bước trên trên mọi máy chủ Docker bằng cách thay thế --volume đường dẫn đến các ổ chứa cơ sở dữ liệu tương ứng.

Khi bạn đã so sánh giá trị được báo cáo bởi tất cả các vùng chứa cơ sở dữ liệu và quyết định vùng chứa nào là nút cập nhật nhất, hãy thay đổi safe_to_bootstrap gắn cờ cho 1 bên trong / {datadir volume} /grastate.dat theo cách thủ công. Giả sử tất cả các nút đang báo cáo cùng một số thứ tự chính xác, chúng ta chỉ có thể chọn mariadb3 được khởi động bằng cách thay đổi safe_to_bootstrap giá trị thành 1:

$ vim /containers/mariadb3/datadir/grasate.dat
...
safe_to_bootstrap: 1

Lưu tệp và bắt đầu khởi động cụm từ nút đó, như được mô tả trong chương tiếp theo.

Khởi động cụm

Khởi động cụm tương tự như lệnh chạy docker đầu tiên mà chúng tôi đã sử dụng khi khởi động cụm lần đầu tiên. Nếu mariadb1 là nút bootstrap đã chọn, chúng ta có thể chỉ cần chạy lại vùng chứa bootstrap đã tạo:

$ docker start mariadb0 # on host1

Ngược lại, nếu vùng chứa bootstrap không tồn tại trên nút đã chọn, giả sử trên host2, hãy chạy lệnh vùng chứa bootstrap và ánh xạ các khối lượng hiện có của mariadb2. Chúng tôi đang sử dụng mariadb0 làm tên vùng chứa trên host2 để cho biết nó là vùng chứa bootstrap:

$ docker run -d \
        --name mariadb0 \
        --hostname mariadb0.weave.local \
        --net weave \
        --publish "3306" \
        --publish "4444" \
        --publish "4567" \
        --publish "4568" \
        $(weave dns-args) \
        --env MYSQL_ROOT_PASSWORD="PM7%[email protected]^1" \
        --volume /containers/mariadb2/datadir:/var/lib/mysql \
        --volume /containers/mariadb2/conf.d:/etc/mysql/mariadb.conf.d \
        mariadb:10.2.15 \
        --wsrep_cluster_address=gcomm:// \
        --wsrep_sst_auth="root:PM7%[email protected]^1" \
        --wsrep_node_address=mariadb0.weave.local

Bạn có thể nhận thấy rằng lệnh này ngắn hơn một chút so với lệnh bootstrap trước đó được mô tả trong hướng dẫn này. Vì chúng tôi đã tạo người dùng proxysql trong lệnh bootstrap đầu tiên của mình, chúng tôi có thể bỏ qua hai biến môi trường sau:

  • --env MYSQL_USER =proxysql
  • --env MYSQL_PASSWORD =proxysqlpassword

Sau đó, khởi động các vùng chứa MariaDB còn lại, xóa vùng chứa bootstrap và khởi động vùng chứa MariaDB hiện có trên máy chủ lưu trữ bootstrapped. Về cơ bản, thứ tự của các lệnh sẽ là:

$ docker start mariadb1 # on host1
$ docker start mariadb3 # on host3
$ docker stop mariadb0 # on host2
$ docker start mariadb2 # on host2

Tại thời điểm này, cụm được khởi động và đang hoạt động hết công suất.

Kiểm soát tài nguyên

Bộ nhớ là một tài nguyên rất quan trọng trong MySQL. Đây là nơi lưu trữ các bộ đệm và bộ nhớ đệm, và điều quan trọng đối với MySQL là giảm tác động của việc đánh đĩa quá thường xuyên. Mặt khác, hoán đổi có hại cho hiệu suất của MySQL. Theo mặc định, sẽ không có ràng buộc tài nguyên nào đối với các vùng chứa đang chạy. Vùng chứa sử dụng nhiều tài nguyên nhất định mà hạt nhân của máy chủ sẽ cho phép. Một điều quan trọng khác là giới hạn bộ mô tả tệp. Bạn có thể tăng giới hạn của bộ mô tả tệp đang mở hoặc "nofile" lên một cái gì đó cao hơn để phục vụ cho số lượng tệp mà máy chủ MySQL có thể mở đồng thời. Đặt giá trị này thành giá trị cao sẽ không ảnh hưởng gì.

Để giới hạn phân bổ bộ nhớ và tăng giới hạn bộ mô tả tệp cho vùng chứa cơ sở dữ liệu của chúng tôi, người ta sẽ thêm --memory , --memory-swap và --ulimit tham số vào lệnh "docker run":

$ docker kill -s 15 mariadb1
$ docker rm -f mariadb1
$ docker run -d \
        --name mariadb1 \
        --hostname mariadb1.weave.local \
        --net weave \
        --publish "3306:3306" \
        --publish "4444" \
        --publish "4567" \
        --publish "4568" \
        $(weave dns-args) \
        --memory 16g \
        --memory-swap 16g \
        --ulimit nofile:16000:16000 \
        --env MYSQL_ROOT_PASSWORD="PM7%[email protected]^1" \
        --volume /containers/mariadb1/datadir:/var/lib/mysql \
        --volume /containers/mariadb1/conf.d:/etc/mysql/mariadb.conf.d \
        mariadb:10.2.15 \
        --wsrep_cluster_address=gcomm://mariadb0.weave.local,mariadb1.weave.local,mariadb2.weave.local,mariadb3.weave.local \
        --wsrep_sst_auth="root:PM7%[email protected]^1" \
        --wsrep_node_address=mariadb1.weave.local

Hãy lưu ý rằng nếu - hoán đổi bộ nhớ được đặt thành cùng một giá trị với --memory và --memory được đặt thành số nguyên dương, vùng chứa sẽ không có quyền truy cập để hoán đổi. Nếu --memory-swap không được đặt, hoán đổi vùng chứa sẽ mặc định thành --memory nhân với 2. If --memory và --memory-swap được đặt thành cùng một giá trị, điều này sẽ ngăn các vùng chứa sử dụng bất kỳ hoán đổi nào. Điều này là do - hoán đổi bộ nhớ là lượng bộ nhớ kết hợp và bộ nhớ hoán đổi có thể được sử dụng, trong khi - bộ nhớ chỉ là dung lượng bộ nhớ vật lý có thể được sử dụng.

Một số tài nguyên vùng chứa như bộ nhớ và CPU có thể được điều khiển động thông qua lệnh "cập nhật docker", như được minh họa trong ví dụ sau để nâng cấp bộ nhớ của vùng chứa mariadb1 lên 32G ngay lập tức:

$ docker update \
    --memory 32g \
    --memory-swap 32g \
    mariadb1

Đừng quên điều chỉnh my.cnf cho phù hợp với thông số kỹ thuật mới. Quản lý cấu hình được giải thích trong phần tiếp theo.

Quản lý cấu hình

Hầu hết các tham số cấu hình MySQL / MariaDB có thể được thay đổi trong thời gian chạy, có nghĩa là bạn không cần phải khởi động lại để áp dụng các thay đổi. Kiểm tra trang tài liệu MariaDB để biết chi tiết. Tham số được liệt kê với "Động:Có" có nghĩa là biến được tải ngay sau khi thay đổi mà không cần khởi động lại máy chủ MariaDB. Nếu không, hãy đặt các thông số bên trong tệp cấu hình tùy chỉnh trong máy chủ lưu trữ Docker. Ví dụ:trên mariadb3, hãy thực hiện các thay đổi đối với tệp sau:

$ vim /containers/mariadb3/conf.d/my.cnf

Và sau đó khởi động lại vùng chứa cơ sở dữ liệu để áp dụng thay đổi:

$ docker restart mariadb3

Xác minh vùng chứa bắt đầu quá trình bằng cách xem nhật ký của docker. Thực hiện thao tác này trên một nút tại một thời điểm nếu bạn muốn thực hiện các thay đổi trên toàn cụm.

Sao lưu

Việc tạo một bản sao lưu hợp lý khá đơn giản vì hình ảnh MariaDB cũng đi kèm với tệp nhị phân mysqldump. Bạn chỉ cần sử dụng lệnh "docker executive" để chạy mysqldump và gửi đầu ra tới một tệp liên quan đến đường dẫn máy chủ. Lệnh sau thực hiện sao lưu mysqldump trên mariadb2 và lưu nó vào / backup / mariadb2 bên trong host2:

$ docker exec -it mariadb2 mysqldump -uroot -p --single-transaction > /backups/mariadb2/dump.sql

Sao lưu nhị phân như Percona Xtrabackup hoặc MariaDB Backup yêu cầu quá trình truy cập trực tiếp vào thư mục dữ liệu MariaDB. Bạn phải cài đặt công cụ này bên trong vùng chứa hoặc thông qua máy chủ lưu trữ máy hoặc sử dụng hình ảnh chuyên dụng cho mục đích này như hình ảnh "perconalab / percona-xtrabackup" để tạo bản sao lưu và lưu trữ bên trong / tmp / backup trên máy chủ Docker:

$ docker run --rm -it \
    -v /containers/mariadb2/datadir:/var/lib/mysql \
    -v /tmp/backup:/xtrabackup_backupfiles \
    perconalab/percona-xtrabackup \
    --backup --host=mariadb2 --user=root --password=mypassword

Bạn cũng có thể dừng vùng chứa bằng innodb_fast_shutdown đặt thành 0 và sao chép qua khối lượng dữ liệu sang một vị trí khác trong máy chủ vật lý:

$ docker exec -it mariadb2 mysql -uroot -p -e 'SET GLOBAL innodb_fast_shutdown = 0'
$ docker kill -s 15 mariadb2
$ cp -Rf /containers/mariadb2/datadir /backups/mariadb2/datadir_copied
$ docker start mariadb2

Khôi phục

Việc khôi phục lại khá đơn giản đối với mysqldump. Bạn có thể chỉ cần chuyển hướng stdin vào vùng chứa từ máy chủ vật lý:

$ docker exec -it mariadb2 mysql -uroot -p < /backups/mariadb2/dump.sql

Bạn cũng có thể sử dụng từ xa dòng lệnh máy khách mysql tiêu chuẩn với tên máy chủ và giá trị cổng thích hợp thay vì sử dụng lệnh "docker thi hành" này:

$ mysql -uroot -p -h127.0.0.1 -P3306 < /backups/mariadb2/dump.sql

Đối với Percona Xtrabackup và MariaDB Backup, chúng ta phải chuẩn bị sao lưu trước. Thao tác này sẽ chuyển tiếp bản sao lưu đến thời điểm sao lưu hoàn tất. Giả sử các tệp Xtrabackup của chúng tôi được đặt trong / tmp / backup của máy chủ lưu trữ Docker, để chuẩn bị cho nó, chỉ cần:

$ docker run --rm -it \
    -v mysql-datadir:/var/lib/mysql \
    -v /tmp/backup:/xtrabackup_backupfiles \
    perconalab/percona-xtrabackup \
    --prepare --target-dir /xtrabackup_backupfiles

Sau đó, bản sao lưu đã chuẩn bị theo / tmp / backup của máy chủ Docker có thể được sử dụng làm datadir MariaDB cho một vùng chứa hoặc cụm mới. Giả sử chúng tôi chỉ muốn xác minh khôi phục trên một vùng chứa MariaDB độc lập, chúng tôi sẽ chạy:

$ docker run -d \
    --name mariadb-restored \
    --env MYSQL_ROOT_PASSWORD="PM7%[email protected]^1" \
    -v /tmp/backup:/var/lib/mysql \
    mariadb:10.2.15

Nếu bạn đã thực hiện sao lưu bằng cách sử dụng phương pháp dừng và sao chép, bạn có thể chỉ cần sao chép dữ liệu và sử dụng thư mục đã sao chép dưới dạng một bản đồ khối lượng tới dữ liệu MariaDB để chạy trên một vùng chứa khác. Giả sử bản sao lưu đã được sao chép qua / backups / mariadb2 / datadir_copied, chúng ta có thể chạy một vùng chứa mới bằng cách chạy:

$ mkdir -p /containers/mariadb-restored/datadir
$ cp -Rf /backups/mariadb2/datadir_copied /containers/mariadb-restored/datadir
$ docker run -d \
    --name mariadb-restored \
    --env MYSQL_ROOT_PASSWORD="PM7%[email protected]^1" \
    -v /containers/mariadb-restored/datadir:/var/lib/mysql \
    mariadb:10.2.15

MYSQL_ROOT_PASSWORD phải khớp với mật khẩu gốc thực tế cho bản sao lưu cụ thể đó.

Somenines MySQL trên Docker:Cách chứa cơ sở dữ liệu của bạn Khám phá tất cả những gì bạn cần hiểu khi cân nhắc chạy dịch vụ MySQL trên ảo hóa vùng chứa DockerTải xuống Whitepaper

Nâng cấp phiên bản cơ sở dữ liệu

Có hai loại nâng cấp - nâng cấp tại chỗ hoặc nâng cấp hợp lý.

Nâng cấp tại chỗ bao gồm việc tắt máy chủ MariaDB, thay thế các tệp nhị phân cũ bằng các tệp nhị phân mới và sau đó khởi động máy chủ trên thư mục dữ liệu cũ. Sau khi bắt đầu, bạn phải chạy mysql_upgrade script để kiểm tra và nâng cấp tất cả các bảng hệ thống và cũng để kiểm tra các bảng người dùng.

Nâng cấp hợp lý liên quan đến việc xuất SQL từ phiên bản hiện tại bằng tiện ích sao lưu hợp lý như mysqldump, chạy vùng chứa mới với mã nhị phân phiên bản nâng cấp, sau đó áp dụng SQL cho phiên bản MySQL / MariaDB mới. Nó tương tự như cách tiếp cận sao lưu và khôi phục được mô tả trong phần trước.

Tuy nhiên, đó là một cách tốt để luôn sao lưu cơ sở dữ liệu của bạn trước khi thực hiện bất kỳ hoạt động phá hoại nào. Các bước sau là bắt buộc khi nâng cấp từ hình ảnh hiện tại, MariaDB 10.1.33 lên một phiên bản chính khác, MariaDB 10.2.15 trên mariadb3 nằm trên host3:

  1. Sao lưu cơ sở dữ liệu. Sao lưu vật lý hay logic không quan trọng nhưng nên sử dụng cách sau sử dụng mysqldump.

  2. Tải xuống hình ảnh mới nhất mà chúng tôi muốn nâng cấp lên:

    $ docker pull mariadb:10.2.15

  3. Đặt innodb_fast_shutdown thành 0 cho vùng chứa cơ sở dữ liệu của chúng tôi:

    $ docker exec -it mariadb3 mysql -uroot -p -e 'SET GLOBAL innodb_fast_shutdown = 0'

  4. Tắt vùng chứa cơ sở dữ liệu một cách duyên dáng:

    $ docker kill --signal=TERM mariadb3

  5. Tạo một vùng chứa mới với hình ảnh mới cho vùng chứa cơ sở dữ liệu của chúng tôi. Giữ nguyên phần còn lại của các thông số ngoại trừ việc sử dụng tên vùng chứa mới (nếu không nó sẽ xung đột):

    $ docker run -d \
        --name mariadb3-new \
        --hostname mariadb3.weave.local \
        --net weave \
        --publish "3306:3306" \
        --publish "4444" \
        --publish "4567" \
        --publish "4568" \
        $(weave dns-args) \
        --env MYSQL_ROOT_PASSWORD="PM7%[email protected]^1" \
        --volume /containers/mariadb3/datadir:/var/lib/mysql \
        --volume /containers/mariadb3/conf.d:/etc/mysql/mariadb.conf.d \
        mariadb:10.2.15 \
        --wsrep_cluster_address=gcomm://mariadb0.weave.local,mariadb1.weave.local,mariadb2.weave.local,mariadb3.weave.local \
        --wsrep_sst_auth="root:PM7%[email protected]^1" \
        --wsrep_node_address=mariadb3.weave.local

  6. Chạy tập lệnh mysql_upgrade:

    $ docker exec -it mariadb3-new mysql_upgrade -uroot -p

  7. Nếu không có lỗi nào xảy ra, hãy xóa vùng chứa cũ, mariadb3 (vùng chứa mới là mariadb3-new):

    $ docker rm -f mariadb3

  8. Nếu không, nếu giữa quá trình nâng cấp không thành công, chúng tôi có thể quay lại vùng chứa trước đó:

    $ docker stop mariadb3-new
$ docker start mariadb3

Nâng cấp phiên bản chính có thể được thực hiện tương tự như nâng cấp phiên bản nhỏ, ngoại trừ bạn phải lưu ý rằng MySQL / MariaDB chỉ hỗ trợ nâng cấp lớn từ phiên bản trước. Nếu bạn đang sử dụng MariaDB 10.0 và muốn nâng cấp lên 10.2, trước tiên bạn phải nâng cấp lên MariaDB 10.1, sau đó là bước nâng cấp khác lên MariaDB 10.2.

Lưu ý về các thay đổi cấu hình đang được áp dụng và không được dùng nữa giữa các phiên bản chính.

Chuyển đổi dự phòng

Trong Galera, tất cả các nút đều là nút chính và giữ vai trò như nhau. Với ProxySQL trong hình, các kết nối đi qua cổng này sẽ tự động bị lỗi miễn là có một thành phần chính đang chạy cho Galera Cluster (nghĩa là, phần lớn các nút đã hoạt động). Ứng dụng sẽ không nhận thấy bất kỳ sự khác biệt nào nếu một nút cơ sở dữ liệu gặp trục trặc vì ProxySQL sẽ chỉ chuyển hướng các kết nối đến các nút có sẵn khác.

Nếu ứng dụng kết nối trực tiếp với ProxySQL bỏ qua MariaDB, chuyển đổi dự phòng phải được thực hiện ở phía ứng dụng bằng cách trỏ đến nút có sẵn tiếp theo, miễn là nút cơ sở dữ liệu đáp ứng các điều kiện sau:

  • Trạng thái wsrep_local_state_comment được Đồng bộ hóa (Trạng thái "Đã hủy bỏ / Nhà tài trợ" cũng có thể xảy ra, chỉ khi wsrep_sst_method là xtrabackup, xtrabackup-v2 hoặc mariabackup).
  • Trạng thái wsrep_cluster_status là chính.

Trong Galera, một nút khả dụng không có nghĩa là nó hoạt động tốt cho đến khi trạng thái trên được xác minh.

Mở rộng quy mô

Để mở rộng quy mô, chúng tôi có thể tạo một vùng chứa mới trong cùng một mạng và sử dụng cùng một tệp cấu hình tùy chỉnh cho vùng chứa hiện có trên máy chủ cụ thể đó. Ví dụ:giả sử chúng ta muốn thêm vùng chứa MariaDB thứ tư trên host3, chúng ta có thể sử dụng cùng một tệp cấu hình được gắn kết cho mariadb3, như được minh họa trong sơ đồ sau:

Chạy lệnh sau trên host3 để mở rộng quy mô:

$ docker run -d \
        --name mariadb4 \
        --hostname mariadb4.weave.local \
        --net weave \
        --publish "3306:3307" \
        --publish "4444" \
        --publish "4567" \
        --publish "4568" \
        $(weave dns-args) \
        --env MYSQL_ROOT_PASSWORD="PM7%[email protected]^1" \
        --volume /containers/mariadb4/datadir:/var/lib/mysql \
        --volume /containers/mariadb3/conf.d:/etc/mysql/mariadb.conf.d \
        mariadb:10.2.15 \
        --wsrep_cluster_address=gcomm://mariadb1.weave.local,mariadb2.weave.local,mariadb3.weave.local,mariadb4.weave.local \
        --wsrep_sst_auth="root:PM7%[email protected]^1" \
        --wsrep_node_address=mariadb4.weave.local

Khi vùng chứa được tạo, nó sẽ tham gia vào cụm và thực hiện SST. Nó có thể được truy cập trên cổng 3307 bên ngoài hoặc bên ngoài mạng Weave, hoặc cổng 3306 trong máy chủ hoặc trong mạng Weave. Không cần thiết phải đưa mariadb0.weave.local vào địa chỉ cụm nữa. Khi cụm được thu nhỏ, chúng tôi cần thêm vùng chứa MariaDB mới vào bộ cân bằng tải ProxySQL thông qua bảng điều khiển dành cho quản trị viên:

$ docker exec -it proxysql1 mysql -uadmin -padmin -P6032
mysql> INSERT INTO mysql_servers(hostgroup_id,hostname,port) VALUES (10,'mariadb4.weave.local',3306);
mysql> INSERT INTO mysql_servers(hostgroup_id,hostname,port) VALUES (20,'mariadb4.weave.local',3306);
mysql> LOAD MYSQL SERVERS TO RUNTIME;
mysql> SAVE MYSQL SERVERS TO DISK;

Lặp lại các lệnh trên trên phiên bản ProxySQL thứ hai.

Cuối cùng đối với bước cuối cùng, (bạn có thể bỏ qua phần này nếu bạn đã chạy câu lệnh "SAVE .. TO DISK" trong ProxySQL), hãy thêm dòng sau vào proxysql.cnf để làm cho nó liên tục trong quá trình khởi động lại vùng chứa trên host1 và host2:

$ vim /containers/proxysql1/proxysql.cnf # host1
$ vim /containers/proxysql2/proxysql.cnf # host2

Và nối các dòng liên quan mariadb4 dưới chỉ thị mysql_server:

mysql_servers =
(
        { address="mariadb1.weave.local" , port=3306 , hostgroup=10, max_connections=100 },
        { address="mariadb2.weave.local" , port=3306 , hostgroup=10, max_connections=100 },
        { address="mariadb3.weave.local" , port=3306 , hostgroup=10, max_connections=100 },
        { address="mariadb4.weave.local" , port=3306 , hostgroup=10, max_connections=100 },
        { address="mariadb1.weave.local" , port=3306 , hostgroup=20, max_connections=100 },
        { address="mariadb2.weave.local" , port=3306 , hostgroup=20, max_connections=100 },
        { address="mariadb3.weave.local" , port=3306 , hostgroup=20, max_connections=100 },
        { address="mariadb4.weave.local" , port=3306 , hostgroup=20, max_connections=100 }
)

Lưu tệp và chúng ta sẽ làm tốt trong lần khởi động lại vùng chứa tiếp theo.

Thu nhỏ quy mô

Để giảm tỷ lệ, chỉ cần tắt vùng chứa một cách duyên dáng. Lệnh tốt nhất sẽ là:

$ docker kill -s 15 mariadb4
$ docker rm -f mariadb4

Hãy nhớ rằng, nếu nút cơ sở dữ liệu rời khỏi cụm một cách vô duyên, nó không phải là một phần của việc thu nhỏ và sẽ ảnh hưởng đến việc tính toán túc số.

Để xóa vùng chứa khỏi ProxySQL, hãy chạy các lệnh sau trên cả hai vùng chứa ProxySQL. Ví dụ:trên proxysql1:

$ docker exec -it proxysql1 mysql -uadmin -padmin -P6032
mysql> DELETE FROM mysql_servers WHERE hostname="mariadb4.weave.local";
mysql> LOAD MYSQL SERVERS TO RUNTIME;
mysql> SAVE MYSQL SERVERS TO DISK;

Sau đó, bạn có thể xóa mục nhập tương ứng bên trong proxysql.cnf hoặc chỉ để như vậy. Dù sao thì nó cũng sẽ được phát hiện là NGOẠI TUYẾN từ quan điểm của ProxySQL.

Tóm tắt

Với Docker, mọi thứ sẽ khác một chút so với cách xử lý thông thường trên máy chủ MySQL hoặc MariaDB. Xử lý các dịch vụ trạng thái như Galera Cluster không dễ dàng như các ứng dụng không trạng thái và yêu cầu kiểm tra và lập kế hoạch phù hợp.

Trong blog tiếp theo của chúng tôi về chủ đề này, chúng tôi sẽ đánh giá những ưu và nhược điểm của việc chạy Galera Cluster trên Docker mà không cần bất kỳ công cụ điều phối nào.


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

  1. MariaDB TX là gì? Cách quản lý MariaDB MySQL Fork mới!

  2. Cách KHÔNG THÍCH hoạt động trong MariaDB

  3. Cài đặt ngoại tuyến cụm MariaDB cho CentOS

  4. Cách thiết lập sao chép không đồng bộ giữa các cụm MariaDB Galera

  5. Cách HOUR () hoạt động trong MariaDB