Chạy một cụm MariaDB Galera mà không có công cụ điều phối vùng chứa:Phần một

Các công cụ điều phối vùng chứa đơn giản hóa việc chạy một hệ thống phân tán, bằng cách triển khai và triển khai lại các vùng chứa và xử lý bất kỳ lỗi nào xảy ra. Người ta có thể cần phải di chuyển các ứng dụng xung quanh, ví dụ:để xử lý các bản cập nhật, mở rộng quy mô hoặc các lỗi máy chủ cơ bản. Mặc dù điều này nghe có vẻ tuyệt vời, nhưng không phải lúc nào nó cũng hoạt động tốt với một cụm cơ sở dữ liệu nhất quán mạnh mẽ như Galera. Bạn không thể chỉ di chuyển các nút cơ sở dữ liệu xung quanh, chúng không phải là các ứng dụng không trạng thái. Ngoài ra, thứ tự mà bạn thực hiện các thao tác trên một cụm có ý nghĩa cao. Ví dụ:khởi động lại một cụm Galera phải bắt đầu từ nút nâng cao nhất, nếu không bạn sẽ mất dữ liệu. Do đó, chúng tôi sẽ hướng dẫn bạn cách chạy Galera Cluster trên Docker mà không cần công cụ điều phối vùng chứa để bạn có toàn quyền kiểm soát.

Trong bài đăng trên blog này, chúng ta sẽ xem xét cách chạy Cụm MariaDB Galera trên vùng chứa Docker bằng cách sử dụng hình ảnh Docker tiêu chuẩn trên nhiều máy chủ Docker mà không cần sự trợ giúp của các công cụ điều phối như Swarm hoặc Kubernetes. Cách tiếp cận này tương tự như chạy một Cụm Galera trên các máy chủ tiêu chuẩn, nhưng việc quản lý quy trình được định cấu hình thông qua Docker.

Trước khi chúng tôi đi sâu hơn vào chi tiết, chúng tôi giả sử bạn đã cài đặt Docker, vô hiệu hóa SElinux / AppArmor và xóa các quy tắc bên trong iptables, firewalld hoặc ufw (tùy theo bạn đang sử dụng). Sau đây là ba máy chủ Docker dành riêng cho cụm cơ sở dữ liệu của chúng tôi:

• host1.local - 192.168.55.161
• host2.local - 192.168.55.162
• host3.local - 192.168.55.163

Kết nối mạng nhiều máy chủ

Trước hết, mạng Docker mặc định được liên kết với máy chủ cục bộ. Docker Swarm giới thiệu một lớp mạng khác được gọi là mạng lớp phủ, mở rộng kết nối mạng vùng chứa cho nhiều máy chủ Docker trong một cụm được gọi là Swarm. Rất lâu trước khi tích hợp này ra đời, đã có nhiều plugin mạng được phát triển để hỗ trợ điều này - Flannel, Calico, Weave là một số trong số đó.

Ở đây, chúng tôi sẽ sử dụng Weave làm plugin mạng Docker cho mạng đa máy chủ. Điều này chủ yếu là do sự đơn giản để cài đặt và chạy nó cũng như hỗ trợ cho trình phân giải DNS (các vùng chứa chạy trong mạng này có thể phân giải tên máy chủ của nhau). Có hai cách để chạy Weave - systemd hoặc thông qua Docker. Chúng tôi sẽ cài đặt nó như một đơn vị systemd, vì vậy nó độc lập với Docker daemon (nếu không, chúng tôi sẽ phải khởi động Docker trước khi Weave được kích hoạt).

1. Tải xuống và cài đặt Weave:

   $ curl -L git.io/weave -o /usr/local/bin/weave
   $ chmod a+x /usr/local/bin/weave

2. Tạo tệp đơn vị systemd cho Weave:

   $ cat > /etc/systemd/system/weave.service << EOF
   [Unit]
   Description=Weave Network
   Documentation=http://docs.weave.works/weave/latest_release/
   Requires=docker.service
   After=docker.service
   [Service]
   EnvironmentFile=-/etc/sysconfig/weave
   ExecStartPre=/usr/local/bin/weave launch --no-restart $PEERS
   ExecStart=/usr/bin/docker attach weave
   ExecStop=/usr/local/bin/weave stop
   [Install]
   WantedBy=multi-user.target
   EOF

3. Xác định địa chỉ IP hoặc tên máy chủ của các ứng dụng ngang hàng bên trong / etc / sysconfig / Weave:

   $ echo 'PEERS="192.168.55.161 192.168.55.162 192.168.55.163"' > /etc/sysconfig/weave

4. Khởi động và bật Weave khi khởi động:

   $ systemctl start weave
   $ systemctl enable weave

Lặp lại 4 bước trên trên tất cả các máy chủ Docker. Xác minh bằng lệnh sau khi hoàn tất:

$ weave status

Số lượng đồng nghiệp là những gì chúng tôi đang tìm kiếm. Nó phải là 3:

          ...
          Peers: 3 (with 6 established connections)
          ...

Chạy một Cụm Galera

Bây giờ mạng đã sẵn sàng, đã đến lúc kích hoạt các vùng chứa cơ sở dữ liệu của chúng ta và tạo thành một cụm. Các quy tắc cơ bản là:

• Vùng chứa phải được tạo trong --net =Weave để có kết nối nhiều máy chủ.
• Các cảng container cần được xuất bản là 3306, 4444, 4567, 4568.
• Hình ảnh Docker phải hỗ trợ Galera. Nếu bạn muốn sử dụng Oracle MySQL, hãy tải phiên bản Codership. Nếu bạn muốn Percona's, hãy sử dụng hình ảnh này để thay thế. Trong bài đăng trên blog này, chúng tôi đang sử dụng MariaDB.

Lý do chúng tôi chọn MariaDB làm nhà cung cấp cụm Galera là:

• Galera được nhúng vào MariaDB, bắt đầu từ MariaDB 10.1.
• Hình ảnh MariaDB được duy trì bởi nhóm Docker và MariaDB.
• Một trong những hình ảnh Docker phổ biến nhất hiện có.

Khởi động Galera Cluster phải được thực hiện theo trình tự. Đầu tiên, nút cập nhật nhất phải được bắt đầu bằng "wsrep_cluster_address =gcomm://". Sau đó, bắt đầu các nút còn lại với địa chỉ đầy đủ bao gồm tất cả các nút trong cụm, ví dụ:"wsrep_cluster_address =gcomm:// node1, node2, node3". Để thực hiện các bước này bằng cách sử dụng vùng chứa, chúng tôi phải thực hiện thêm một số bước để đảm bảo tất cả các vùng chứa đang chạy đồng nhất. Vì vậy, kế hoạch là:

1. Chúng tôi cần bắt đầu với 4 vùng chứa theo thứ tự này - mariadb0 (bootstrap), mariadb2, mariadb3, mariadb1.
2. Vùng chứa mariadb0 sẽ sử dụng cùng một datadir và configdir với mariadb1.
3. Sử dụng mariadb0 trên host1 cho lần khởi động đầu tiên, sau đó bắt đầu mariadb2 trên host2, mariadb3 trên host3.
4. Xóa mariadb0 trên host1 để nhường chỗ cho mariadb1.
5. Cuối cùng, hãy bắt đầu mariadb1 trên host1.

Vào cuối ngày, bạn sẽ có Cụm Galera ba nút (mariadb1, mariadb2, mariadb3). Vùng chứa đầu tiên (mariadb0) là vùng chứa tạm thời chỉ dành cho mục đích khởi động, sử dụng địa chỉ cụm "gcomm://". Nó chia sẻ cùng một datadir và configdir với mariadb1 và sẽ bị xóa khi cụm được hình thành (mariadb2 và mariadb3 được thiết lập) và các nút được đồng bộ hóa.

Theo mặc định, Galera bị tắt trong MariaDB và cần được bật bằng cờ có tên là wsrep_on (đặt thành BẬT) và wsrep_provider (đặt thành đường dẫn thư viện Galera) cộng với một số tham số liên quan đến Galera. Do đó, chúng tôi cần xác định tệp cấu hình tùy chỉnh cho vùng chứa để định cấu hình Galera một cách chính xác.

Hãy bắt đầu với vùng chứa đầu tiên, mariadb0. Tạo tệp trong /containers/mariadb1/conf.d/my.cnf và thêm các dòng sau:

$ mkdir -p /containers/mariadb1/conf.d
$ cat /containers/mariadb1/conf.d/my.cnf
[mysqld]

default_storage_engine          = InnoDB
binlog_format                   = ROW

innodb_flush_log_at_trx_commit  = 0
innodb_flush_method             = O_DIRECT
innodb_file_per_table           = 1
innodb_autoinc_lock_mode        = 2
innodb_lock_schedule_algorithm  = FCFS # MariaDB >10.1.19 and >10.2.3 only

wsrep_on                        = ON
wsrep_provider                  = /usr/lib/galera/libgalera_smm.so
wsrep_sst_method                = xtrabackup-v2

Vì hình ảnh không đi kèm với MariaDB Backup (là phương pháp SST ưa thích cho MariaDB 10.1 và MariaDB 10.2), chúng tôi sẽ gắn bó với xtrabackup-v2 trong thời gian này.

Để thực hiện bootstrap đầu tiên cho cụm, hãy chạy vùng chứa bootstrap (mariadb0) trên host1 với "datadir" và "conf.d" của mariadb1:

$ 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" \
        --env MYSQL_USER=proxysql \
        --env MYSQL_PASSWORD=proxysqlpassword \
        --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:// \
        --wsrep_sst_auth="root:PM7%[email protected]^1" \
        --wsrep_node_address=mariadb0.weave.local

Các tham số được sử dụng trong lệnh trên là:

• - tên , tạo vùng chứa có tên "mariadb0",
• - tên máy chủ , gán cho vùng chứa một tên máy chủ "mariadb0.weave.local",
• --net , đặt vùng chứa trong mạng dệt để hỗ trợ nhiều máy chủ lưu trữ mạng,
• - xuất bản , hiển thị các cổng 3306, 4444, 4567, 4568 trên container cho máy chủ lưu trữ,
• $ (dệt dns-args) , định cấu hình trình phân giải DNS cho vùng chứa này. Lệnh này có thể được dịch sang Docker run là "--dns =172.17.0.1 --dns-search =Weave.local.",
• --env MYSQL_ROOT_PASSWORD , mật khẩu gốc MySQL,
• --env MYSQL_USER , tạo người dùng "proxysql" để sử dụng sau này với ProxySQL để định tuyến cơ sở dữ liệu,
• --env MYSQL_PASSWORD , mật khẩu người dùng "proxysql",
• --volume / container / mariadb1 / datadir:/ var / lib / mysql , tạo / container / mariadb1 / datadir nếu không tồn tại và ánh xạ nó với / var / lib / mysql (MySQL datadir) của vùng chứa (đối với nút bootstrap, điều này có thể bị bỏ qua),
• --volume /containers/mariadb1/conf.d:/etc/mysql/mariadb.conf.d , gắn kết các tệp trong thư mục /containers/mariadb1/conf.d của máy chủ Docker, vào vùng chứa tại /etc/mysql/mariadb.conf.d.
• mariadb:10.2.15 , sử dụng hình ảnh MariaDB 10.2.15 từ đây,
• --wsrep_cluster_address , Chuỗi kết nối Galera cho cụm. "gcomm://" có nghĩa là bootstrap. Đối với phần còn lại của các vùng chứa, chúng tôi sẽ sử dụng một địa chỉ đầy đủ để thay thế.
• --wsrep_sst_auth , chuỗi xác thực cho người dùng SST. Sử dụng cùng một người dùng với quyền root,
• --wsrep_node_address , tên máy chủ của nút, trong trường hợp này, chúng tôi sẽ sử dụng FQDN do Weave cung cấp.

Vùng chứa bootstrap chứa một số điều quan trọng:

• Tên, tên máy chủ và wsrep_node_address là mariadb0, nhưng nó sử dụng khối lượng của mariadb1.
• Địa chỉ cụm là "gcomm://"
• Có hai tham số --env bổ sung - MYSQL_USER và MYSQL_PASSWORD. Thông số này sẽ tạo thêm người dùng cho mục đích giám sát proxysql của chúng tôi.

Xác minh bằng lệnh sau:

$ docker ps
$ docker logs -f mariadb0

Khi bạn nhìn thấy dòng sau, nó cho biết quá trình bootstrap đã hoàn tất và Galera đang hoạt động:

2018-05-30 23:19:30 139816524539648 [Note] WSREP: Synchronized with group, ready for connections

Tạo thư mục để tải tệp cấu hình tùy chỉnh của chúng tôi trong các máy chủ còn lại:

$ mkdir -p /containers/mariadb2/conf.d # on host2
$ mkdir -p /containers/mariadb3/conf.d # on host3

Sau đó, sao chép my.cnf mà chúng ta đã tạo cho mariadb0 và mariadb1 vào mariadb2 và mariadb3 tương ứng:

$ scp /containers/mariadb1/conf.d/my.cnf /containers/mariadb2/conf.d/ # on host1
$ scp /containers/mariadb1/conf.d/my.cnf /containers/mariadb3/conf.d/ # on host1

Tiếp theo, tạo 2 vùng chứa cơ sở dữ liệu khác (mariadb2 và mariadb3) trên host2 và host3 tương ứng:

$ docker run -d \
        --name ${NAME} \
        --hostname ${NAME}.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/${NAME}/datadir:/var/lib/mysql \
        --volume /containers/${NAME}/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=${NAME}.weave.local

** Thay thế $ {NAME} tương ứng bằng mariadb2 hoặc mariadb3.

Tuy nhiên, có một nhược điểm. Tập lệnh entrypoint kiểm tra dịch vụ mysqld ở chế độ nền sau khi khởi tạo cơ sở dữ liệu bằng cách sử dụng người dùng gốc MySQL mà không cần mật khẩu. Vì Galera tự động thực hiện đồng bộ hóa thông qua SST hoặc IST khi khởi động, mật khẩu người dùng gốc MySQL sẽ thay đổi, sao chép nút khởi động. Do đó, bạn sẽ thấy lỗi sau trong lần khởi động đầu tiên:

018-05-30 23:27:13 140003794790144 [Warning] Access denied for user 'root'@'localhost' (using password: NO)
MySQL init process in progress…
MySQL init process failed.

Mẹo là khởi động lại các vùng chứa bị lỗi một lần nữa, vì lần này, datadir MySQL sẽ được tạo (trong lần chạy đầu tiên) và nó sẽ bỏ qua phần khởi tạo cơ sở dữ liệu:

$ docker start mariadb2 # on host2
$ docker start mariadb3 # on host3

Sau khi bắt đầu, hãy xác minh bằng cách xem dòng sau:

$ docker logs -f mariadb2
…
2018-05-30 23:28:39 139808069601024 [Note] WSREP: Synchronized with group, ready for connections

Tại thời điểm này, có 3 container đang chạy là mariadb0, mariadb2 và mariadb3. Hãy lưu ý rằng mariadb0 được bắt đầu bằng lệnh bootstrap (gcomm://), có nghĩa là nếu vùng chứa được Docker tự động khởi động lại trong tương lai, nó có thể trở nên rời rạc với thành phần chính. Do đó, chúng ta cần xóa vùng chứa này và thay thế nó bằng mariadb1, sử dụng cùng một chuỗi kết nối Galera với phần còn lại và sử dụng cùng một datadir và configdir với mariadb0.

Đầu tiên, dừng mariadb0 bằng cách gửi SIGTERM (để đảm bảo nút sẽ tắt một cách duyên dáng):

$ docker kill -s 15 mariadb0

Sau đó, bắt đầu mariadb1 trên host1 bằng lệnh tương tự như mariadb2 hoặc mariadb3:

$ docker run -d \
        --name mariadb1 \
        --hostname mariadb1.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/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

Lần này, bạn không cần thực hiện thủ thuật khởi động lại vì MySQL datadir đã tồn tại (được tạo bởi mariadb0). Khi vùng chứa được khởi động, hãy xác minh kích thước cụm là 3, trạng thái phải ở trạng thái Chính và trạng thái cục bộ được đồng bộ hóa:

$ docker exec -it mariadb3 mysql -uroot "-pPM7%[email protected]^1" -e 'select variable_name, variable_value from information_schema.global_status where variable_name in ("wsrep_cluster_size", "wsrep_local_state_comment", "wsrep_cluster_status", "wsrep_incoming_addresses")'
+---------------------------+-------------------------------------------------------------------------------+
| variable_name             | variable_value                                                                |
+---------------------------+-------------------------------------------------------------------------------+
| WSREP_CLUSTER_SIZE        | 3                                                                             |
| WSREP_CLUSTER_STATUS      | Primary                                                                       |
| WSREP_INCOMING_ADDRESSES  | mariadb1.weave.local:3306,mariadb3.weave.local:3306,mariadb2.weave.local:3306 |
| WSREP_LOCAL_STATE_COMMENT | Synced                                                                        |
+---------------------------+-------------------------------------------------------------------------------+

Tại thời điểm này, kiến ​​trúc của chúng tôi trông giống như sau:

Mặc dù lệnh chạy khá dài nhưng nó mô tả tốt các đặc điểm của vùng chứa. Có lẽ bạn nên gói lệnh trong một tập lệnh để đơn giản hóa các bước thực thi hoặc sử dụng tệp soạn thảo thay thế.

Định tuyến cơ sở dữ liệu với ProxySQL

Bây giờ chúng ta có ba vùng chứa cơ sở dữ liệu đang chạy. Cách duy nhất để truy cập vào cụm bây giờ là truy cập vào cổng MySQL đã xuất bản của máy chủ Docker, là 3306 (ánh xạ tới 3306 vào vùng chứa). Vì vậy, điều gì sẽ xảy ra nếu một trong các vùng chứa cơ sở dữ liệu bị lỗi? Bạn phải chuyển đổi dự phòng theo cách thủ công kết nối của máy khách sang nút có sẵn tiếp theo. Tùy thuộc vào trình kết nối ứng dụng, bạn cũng có thể chỉ định danh sách các nút và để trình kết nối thực hiện chuyển đổi dự phòng và định tuyến truy vấn cho bạn (Trình kết nối / J, PHP mysqlnd). Nếu không, sẽ là một ý tưởng hay nếu hợp nhất các tài nguyên cơ sở dữ liệu thành một tài nguyên duy nhất, có thể được gọi là một dịch vụ.

Đây là lúc ProxySQL xuất hiện trong bức tranh. ProxySQL có thể hoạt động như bộ định tuyến truy vấn, cân bằng tải các kết nối cơ sở dữ liệu tương tự như những gì "Dịch vụ" trong thế giới Swarm hoặc Kubernetes có thể làm. Chúng tôi đã xây dựng hình ảnh ProxySQL Docker cho mục đích này và sẽ duy trì hình ảnh cho mọi phiên bản mới với nỗ lực cao nhất của chúng tôi.

Trước khi chạy vùng chứa ProxySQL, chúng ta phải chuẩn bị tệp cấu hình. Sau đây là những gì chúng tôi đã cấu hình cho proxysql1. Chúng tôi tạo tệp cấu hình tùy chỉnh trong /containers/proxysql1/proxysql.cnf trên host1:

$ cat /containers/proxysql1/proxysql.cnf
datadir="/var/lib/proxysql"
admin_variables=
{
        admin_credentials="admin:admin"
        mysql_ifaces="0.0.0.0:6032"
        refresh_interval=2000
}
mysql_variables=
{
        threads=4
        max_connections=2048
        default_query_delay=0
        default_query_timeout=36000000
        have_compress=true
        poll_timeout=2000
        interfaces="0.0.0.0:6033;/tmp/proxysql.sock"
        default_schema="information_schema"
        stacksize=1048576
        server_version="5.1.30"
        connect_timeout_server=10000
        monitor_history=60000
        monitor_connect_interval=200000
        monitor_ping_interval=200000
        ping_interval_server=10000
        ping_timeout_server=200
        commands_stats=true
        sessions_sort=true
        monitor_username="proxysql"
        monitor_password="proxysqlpassword"
}
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="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 }
)
mysql_users =
(
        { username = "sbtest" , password = "password" , default_hostgroup = 10 , active = 1 }
)
mysql_query_rules =
(
        {
                rule_id=100
                active=1
                match_pattern="^SELECT .* FOR UPDATE"
                destination_hostgroup=10
                apply=1
        },
        {
                rule_id=200
                active=1
                match_pattern="^SELECT .*"
                destination_hostgroup=20
                apply=1
        },
        {
                rule_id=300
                active=1
                match_pattern=".*"
                destination_hostgroup=10
                apply=1
        }
)
scheduler =
(
        {
                id = 1
                filename = "/usr/share/proxysql/tools/proxysql_galera_checker.sh"
                active = 1
                interval_ms = 2000
                arg1 = "10"
                arg2 = "20"
                arg3 = "1"
                arg4 = "1"
                arg5 = "/var/lib/proxysql/proxysql_galera_checker.log"
        }
)

Cấu hình trên sẽ:

• định cấu hình hai nhóm máy chủ, nhóm một người viết và nhiều người viết, như được định nghĩa trong phần "mysql_servers",
• gửi các lần đọc tới tất cả các nút Galera (nhóm máy chủ 20) trong khi các hoạt động ghi sẽ chuyển đến một máy chủ Galera duy nhất (nhóm máy chủ 10),
• lên lịch cho proxysql_galera_checker.sh,
• sử dụng monitor_username và monitor_password làm thông tin đăng nhập giám sát được tạo khi chúng tôi khởi động cụm lần đầu tiên (mariadb0).

Sao chép tệp cấu hình vào host2, để dự phòng ProxySQL:

$ mkdir -p /containers/proxysql2/ # on host2
$ scp /containers/proxysql1/proxysql.cnf /container/proxysql2/ # on host1

Sau đó, chạy các vùng chứa ProxySQL trên host1 và host2 tương ứng:

$ docker run -d \
        --name=${NAME} \
        --publish 6033 \
        --publish 6032 \
        --restart always \
        --net=weave \
        $(weave dns-args) \
        --hostname ${NAME}.weave.local \
        -v /containers/${NAME}/proxysql.cnf:/etc/proxysql.cnf \
        -v /containers/${NAME}/data:/var/lib/proxysql \
        severalnines/proxysql

** Thay thế $ {NAME} tương ứng bằng proxysql1 hoặc proxysql2.

Chúng tôi đã chỉ định --restart =always để làm cho nó luôn khả dụng bất kể trạng thái thoát, cũng như tự động khởi động khi Docker daemon khởi động. Điều này sẽ đảm bảo các vùng chứa ProxySQL hoạt động giống như một daemon.

Xác minh trạng thái máy chủ MySQL được giám sát bởi cả hai phiên bản ProxySQL (dự kiến ​​sẽ có OFFLINE_SOFT cho nhóm máy chủ một người viết):

$ docker exec -it proxysql1 mysql -uadmin -padmin -h127.0.0.1 -P6032 -e 'select hostgroup_id,hostname,status from mysql_servers'
+--------------+----------------------+--------------+
| hostgroup_id | hostname             | status       |
+--------------+----------------------+--------------+
| 10           | mariadb1.weave.local | ONLINE       |
| 10           | mariadb2.weave.local | OFFLINE_SOFT |
| 10           | mariadb3.weave.local | OFFLINE_SOFT |
| 20           | mariadb1.weave.local | ONLINE       |
| 20           | mariadb2.weave.local | ONLINE       |
| 20           | mariadb3.weave.local | ONLINE       |
+--------------+----------------------+--------------+

Tại thời điểm này, kiến ​​trúc của chúng tôi trông giống như sau:

Tất cả các kết nối đến từ 6033 (từ mạng của host1, host2 hoặc vùng chứa) sẽ được cân bằng tải vào các vùng chứa cơ sở dữ liệu phụ trợ bằng ProxySQL. Nếu bạn muốn truy cập một máy chủ cơ sở dữ liệu riêng lẻ, hãy sử dụng cổng 3306 của máy chủ vật lý. Không có địa chỉ IP ảo làm điểm cuối duy nhất được định cấu hình cho dịch vụ ProxySQL, nhưng chúng tôi có thể có địa chỉ đó bằng cách sử dụng Keepalived, được giải thích trong phần tiếp theo.

Địa chỉ IP ảo với Keepalived

Vì chúng tôi đã định cấu hình các vùng chứa ProxySQL để chạy trên host1 và host2, nên chúng tôi sẽ sử dụng các vùng chứa Keepalived để liên kết các máy chủ này với nhau và cung cấp địa chỉ IP ảo thông qua mạng máy chủ. Điều này cho phép một điểm cuối duy nhất cho các ứng dụng hoặc máy khách kết nối với lớp cân bằng tải được hỗ trợ bởi ProxySQL.

Như thường lệ, hãy tạo tệp cấu hình tùy chỉnh cho dịch vụ Keepalived của chúng tôi. Đây là nội dung của /containers/keepalived1/keepalived.conf:

vrrp_instance VI_DOCKER {
   interface ens33               # interface to monitor
   state MASTER
   virtual_router_id 52          # Assign one ID for this route
   priority 101
   unicast_src_ip 192.168.55.161
   unicast_peer {
      192.168.55.162
   }
   virtual_ipaddress {
      192.168.55.160             # the virtual IP
}

Sao chép tệp cấu hình vào host2 cho phiên bản thứ hai:

$ mkdir -p /containers/keepalived2/ # on host2
$ scp /containers/keepalived1/keepalived.conf /container/keepalived2/ # on host1

Thay đổi mức độ ưu tiên từ 101 thành 100 bên trong tệp cấu hình đã sao chép trên host2:

$ sed -i 's/101/100/g' /containers/keepalived2/keepalived.conf

** Phiên bản có mức độ ưu tiên cao hơn sẽ giữ địa chỉ IP ảo (trong trường hợp này là máy chủ 1), cho đến khi giao tiếp VRRP bị gián đoạn (trong trường hợp máy chủ 1 bị hỏng).

Sau đó, chạy lệnh sau trên host1 và host2 tương ứng:

$ docker run -d \
        --name=${NAME} \
        --cap-add=NET_ADMIN \
        --net=host \
        --restart=always \
        --volume /containers/${NAME}/keepalived.conf:/usr/local/etc/keepalived/keepalived.conf \ osixia/keepalived:1.4.4

** Thay thế $ {NAME} bằng keepalived1 và keepalived2.

Lệnh run yêu cầu Docker:

• - tên , tạo vùng chứa với
• --cap-add =NET_ADMIN , thêm các tính năng của Linux cho phạm vi quản trị mạng
• --net =host , gắn vùng chứa vào mạng máy chủ. Điều này sẽ cung cấp địa chỉ IP ảo trên giao diện máy chủ, ens33
• --restart =always , luôn giữ cho vùng chứa hoạt động,
• --volume =/ container / $ {NAME} /keepalived.conf:/usr/local/etc/keepalived/keepalived.conf , ánh xạ tệp cấu hình tùy chỉnh để sử dụng vùng chứa.

Sau khi cả hai vùng chứa được khởi động, hãy xác minh sự tồn tại của địa chỉ IP ảo bằng cách xem giao diện mạng vật lý của nút MASTER:

$ ip a | grep ens33
2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    inet 192.168.55.161/24 brd 192.168.55.255 scope global ens33
    inet 192.168.55.160/32 scope global ens33

Máy khách và ứng dụng bây giờ có thể sử dụng địa chỉ IP ảo, 192.168.55.160 để truy cập dịch vụ cơ sở dữ liệu. Địa chỉ IP ảo này tồn tại trên host1 tại thời điểm này. Nếu host1 gặp sự cố, keepalived2 sẽ tiếp quản địa chỉ IP và đưa nó lên host2. Hãy lưu ý rằng cấu hình cho keepalived này không giám sát các vùng chứa ProxySQL. Nó chỉ giám sát quảng cáo VRRP của các đồng nghiệp được Keepalived.

Tại thời điểm này, kiến ​​trúc của chúng tôi trông giống như sau:

Tóm tắt

Vì vậy, bây giờ chúng ta có Cụm MariaDB Galera được hỗ trợ bởi dịch vụ ProxySQL rất sẵn có, tất cả đều chạy trên vùng chứa Docker.

Trong phần hai, chúng ta sẽ xem xét cách quản lý thiết lập này. Chúng ta sẽ xem xét cách thực hiện các hoạt động như tắt máy, khởi động hệ thống, phát hiện nút nâng cao nhất, chuyển đổi dự phòng, khôi phục, tăng / giảm quy mô, nâng cấp, sao lưu, v.v. Chúng tôi cũng sẽ thảo luận về những ưu và nhược điểm của việc thiết lập này cho dịch vụ cơ sở dữ liệu nhóm của chúng tôi.

Chúc bạn xếp hàng vui vẻ!