Tự động hóa cơ sở dữ liệu với con rối:Triển khai MySQL &MariaDB Galera Cluster

Trong bài đăng trên blog trước, chúng tôi đã chỉ cho bạn một số bước cơ bản để triển khai và quản lý một máy chủ MySQL độc lập cũng như thiết lập MySQL Replication bằng cách sử dụng mô-đun MySQL Puppet. Trong lần cài đặt thứ hai này, chúng ta sẽ trình bày các bước tương tự, nhưng bây giờ với thiết lập Galera Cluster.

Cụm Galera với Con rối

Như bạn có thể biết, Galera Cluster có ba nhà cung cấp chính:

MySQL Galera Cluster (Codership)
Percona XtraDB Cluster (Percona)
Cụm MariaDB (được MariaDB nhúng vào Máy chủ MariaDB)

Một thực tế phổ biến với triển khai Galera Cluster là có một lớp bổ sung nằm trên đầu cụm cơ sở dữ liệu cho mục đích cân bằng tải. Tuy nhiên, đó là một quá trình phức tạp và xứng đáng là bài đăng của riêng nó.

Có một số mô-đun Con rối có sẵn trong Lò rèn con rối có thể được sử dụng để triển khai Cụm Galera. Đây là một số trong số chúng ..

con rối / mysql - chỉ MariaDB Galera
fraenki / galera - Percona XtraDB Cluster và MySQL Galera từ Codership
edestecd / mariadb - Chỉ cụm MariaDB
filiadata / percona - Percona XtraDB Cluster

Vì mục tiêu của chúng tôi là cung cấp hiểu biết cơ bản về cách viết tệp kê khai và tự động hóa việc triển khai cho Cụm Galera, chúng tôi sẽ đề cập đến việc triển khai Cụm MariaDB Galera bằng cách sử dụng mô-đun rốilabs / mysql. Đối với các mô-đun khác, bạn luôn có thể xem tài liệu tương ứng của chúng để biết hướng dẫn hoặc mẹo về cách cài đặt.

Trong Galera Cluster, thứ tự khi bắt đầu nút là rất quan trọng. Để bắt đầu đúng một cụm mới, một nút phải được thiết lập làm nút tham chiếu. Nút này sẽ được bắt đầu bằng một chuỗi kết nối máy chủ trống (gcomm://) để khởi tạo cụm. Quá trình này được gọi là bootstrapping.

Sau khi bắt đầu, nút sẽ trở thành một thành phần chính và các nút còn lại có thể được khởi động bằng lệnh start mysql tiêu chuẩn ( systemctl start mysql hoặc dịch vụ mysql start ) theo sau là chuỗi kết nối máy chủ đầy đủ (gcomm:// db1, db2, db3). Bootstrapping chỉ được yêu cầu nếu không có thành phần chính nào được lưu giữ bởi bất kỳ nút nào khác trong cụm (kiểm tra với wsrep_cluster_status trạng thái).

Quá trình khởi động cụm phải được người dùng thực hiện một cách rõ ràng. Bản thân tệp kê khai KHÔNG được khởi động cụm (khởi động nút bất kỳ) ở lần chạy đầu tiên để tránh mọi rủi ro mất dữ liệu. Hãy nhớ rằng, tệp kê khai Con rối phải được viết sao cho phù hợp nhất có thể. Tệp kê khai phải an toàn để được thực thi nhiều lần mà không ảnh hưởng đến các phiên bản MySQL đã chạy. Điều này có nghĩa là chúng tôi phải tập trung chủ yếu vào cấu hình kho lưu trữ, cài đặt gói, cấu hình chạy trước và cấu hình người dùng SST.

Các tùy chọn cấu hình sau là bắt buộc đối với Galera:

wsrep_on :Cờ để bật API sao chép tập viết cho Cụm Galera (chỉ MariaDB).
wsrep_cluster_name :Tên cụm. Phải giống hệt nhau trên tất cả các nút thuộc cùng một cụm.
wsrep_cluster_address :Chuỗi kết nối giao tiếp Galera, tiền tố bằng gcomm:// và theo sau là danh sách nút, được phân tách bằng dấu phẩy. Danh sách nút trống có nghĩa là khởi tạo cụm.
wsrep_provider :Đường dẫn nơi có thư viện Galera. Đường dẫn có thể khác nhau tùy thuộc vào hệ điều hành.
bind_address :MySQL phải có thể truy cập bên ngoài nên giá trị '0.0.0.0' là bắt buộc.
wsrep_sst_method :Đối với MariaDB, phương thức SST được ưu tiên là mariabackup.
wsrep_sst_auth :Người dùng và mật khẩu MySQL (cách nhau bằng dấu hai chấm) để thực hiện chuyển ảnh chụp nhanh. Thông thường, chúng tôi chỉ định người dùng có khả năng tạo bản sao lưu đầy đủ.
wsrep_node_address :Địa chỉ IP để giao tiếp và sao chép Galera. Sử dụng trình xác thực con rối để chọn địa chỉ IP chính xác.
wsrep_node_name :tên máy chủ của FQDN. Sử dụng trình xác thực con rối để chọn tên máy chủ chính xác.

Đối với triển khai dựa trên Debian, tập lệnh sau cài đặt sẽ cố gắng khởi động máy chủ MariaDB tự động. Nếu chúng tôi đã định cấu hình wsrep_on =ON (cờ để bật Galera) với địa chỉ đầy đủ trong wsrep_cluster_address biến, máy chủ sẽ bị lỗi trong khi cài đặt. Điều này là do nó không có thành phần chính để kết nối.

Để bắt đầu một cụm trong Galera đúng cách, nút đầu tiên (được gọi là nút bootstrap) phải được định cấu hình với một chuỗi kết nối trống (wsrep_cluster_address =gcomm://) để bắt đầu nút làm thành phần chính. Bạn cũng có thể chạy tập lệnh bootstrap được cung cấp, được gọi là galera_new_cluster, về cơ bản thực hiện một điều tương tự trong nhưng nền tảng.

Triển khai Cụm Galera (MariaDB)

Việc triển khai Galera Cluster yêu cầu cấu hình bổ sung trên nguồn APT để cài đặt kho lưu trữ phiên bản MariaDB ưa thích.

Lưu ý rằng bản sao Galera được nhúng bên trong Máy chủ MariaDB và không yêu cầu cài đặt thêm gói nào. Điều đó đang được nói, cần có thêm một cờ để kích hoạt Galera bằng cách sử dụng wsrep_on =ON. Nếu không có cờ này, MariaDB sẽ hoạt động như một máy chủ độc lập.

Trong môi trường dựa trên Debian của chúng tôi, tùy chọn wsrep_on chỉ có thể hiển thị trong tệp kê khai sau khi triển khai đầu tiên hoàn thành (như được trình bày thêm trong các bước triển khai). Điều này là để đảm bảo khởi động đầu tiên, ban đầu hoạt động như một máy chủ độc lập để Puppet cung cấp cho nút trước khi nó hoàn toàn sẵn sàng trở thành một nút Galera.

Hãy bắt đầu bằng cách chuẩn bị nội dung tệp kê khai như bên dưới (sửa đổi phần biến toàn cục nếu cần):

# Puppet manifest for Galera Cluster MariaDB 10.3 on Ubuntu 18.04 (Puppet v6.4.2) 
# /etc/puppetlabs/code/environments/production/manifests/galera.pp

# global vars
$sst_user         = 'sstuser'
$sst_password     = 'S3cr333t$'
$backup_dir       = '/home/backup/mysql'
$mysql_cluster_address = 'gcomm://192.168.0.161,192.168.0.162,192.168.0.163'


# node definition
node "db1.local", "db2.local", "db3.local" {
  Apt::Source['mariadb'] ~>
  Class['apt::update'] ->
  Class['mysql::server'] ->
  Class['mysql::backup::xtrabackup']
}

# apt module must be installed first: 'puppet module install puppetlabs-apt'
include apt

# custom repository definition
apt::source { 'mariadb':
  location => 'http://sfo1.mirrors.digitalocean.com/mariadb/repo/10.3/ubuntu',
  release  => $::lsbdistcodename,
  repos    => 'main',
  key      => {
    id     => 'A6E773A1812E4B8FD94024AAC0F47944DE8F6914',
    server => 'hkp://keyserver.ubuntu.com:80',
  },
  include  => {
    src    => false,
    deb    => true,
  },
}

# Galera configuration
class {'mysql::server':
  package_name            => 'mariadb-server',
  root_password           => '[email protected]#',
  service_name            => 'mysql',
  create_root_my_cnf      => true,
  remove_default_accounts => true,
  manage_config_file      => true,
  override_options        => {
    'mysqld' => {
      'datadir'                 => '/var/lib/mysql',
      'bind_address'            => '0.0.0.0',
      'binlog-format'           => 'ROW',
      'default-storage-engine'  => 'InnoDB',
      'wsrep_provider'          => '/usr/lib/galera/libgalera_smm.so',
      'wsrep_provider_options'  => 'gcache.size=1G',
      'wsrep_cluster_name'      => 'galera_cluster',
      'wsrep_cluster_address'   => $mysql_cluster_address,
      'log-error'               => '/var/log/mysql/error.log',
      'wsrep_node_address'      => $facts['networking']['interfaces']['enp0s8']['ip'],
      'wsrep_node_name'         => $hostname,
      'innodb_buffer_pool_size' => '512M',
      'wsrep_sst_method'        => 'mariabackup',
      'wsrep_sst_auth'          => "${sst_user}:${sst_password}"
    },
    'mysqld_safe' => {
      'log-error'               => '/var/log/mysql/error.log'
    }
  }
}

# force creation of backup dir if not exist
exec { "mkdir -p ${backup_dir}" :
  path   => ['/bin','/usr/bin'],
  unless => "test -d ${backup_dir}"
}

# create SST and backup user
class { 'mysql::backup::xtrabackup' :
  xtrabackup_package_name => 'mariadb-backup',
  backupuser              => "${sst_user}",
  backuppassword          => "${sst_password}",
  backupmethod            => 'mariabackup',
  backupdir               => "${backup_dir}"
}

# /etc/hosts definition
host {
  'db1.local': ip => '192.168.0.161';
  'db2.local': ip => '192.169.0.162';
  'db3.local': ip => '192.168.0.163';
}

Một chút giải thích là cần thiết vào thời điểm này. 'wsrep_node_address' phải được trỏ đến cùng một địa chỉ IP với địa chỉ đã được khai báo trong wsrep_cluster_address. Trong môi trường này, các máy chủ của chúng tôi có hai giao diện mạng và chúng tôi muốn sử dụng giao diện thứ hai (được gọi là enp0s8) cho giao tiếp Galera (nơi mạng 192.168.0.0/24 được kết nối với). Đó là lý do tại sao chúng tôi sử dụng Puppet facter để lấy thông tin từ nút và áp dụng nó vào tùy chọn cấu hình. Phần còn lại khá dễ hiểu.

Trên mọi nút MariaDB, hãy chạy lệnh sau để áp dụng danh mục với tư cách là người dùng gốc:

$ puppet agent -t

Danh mục sẽ được áp dụng cho mỗi nút để cài đặt và chuẩn bị. Sau khi hoàn tất, chúng tôi phải thêm dòng sau vào tệp kê khai của mình trong phần "override_options => mysqld":

      'wsrep_on'                 => 'ON',

Ở trên sẽ đáp ứng yêu cầu Galera cho MariaDB. Sau đó, áp dụng danh mục trên mỗi nút MariaDB một lần nữa:

$ puppet agent -t

Sau khi hoàn tất, chúng tôi đã sẵn sàng khởi động cụm của mình. Vì đây là một cụm mới, chúng ta có thể chọn bất kỳ nút nào để làm nút tham chiếu a.k.a nút bootstrap. Hãy chọn db1.local (192.168.0.161) và chạy lệnh sau:

$ galera_new_cluster #db1

Khi nút đầu tiên được khởi động, chúng ta có thể bắt đầu nút còn lại bằng lệnh bắt đầu tiêu chuẩn (mỗi lần một nút):

$ systemctl restart mariadb #db2 and db3

Sau khi bắt đầu, hãy xem qua nhật ký lỗi MySQL tại /var/log/mysql/error.log và đảm bảo nhật ký kết thúc bằng dòng sau:

2019-06-10  4:11:10 2 [Note] WSREP: Synchronized with group, ready for connections

Ở trên cho chúng ta biết rằng các nút được đồng bộ hóa với nhóm. Sau đó, chúng tôi có thể xác minh trạng thái bằng cách sử dụng lệnh sau:

$ mysql -uroot -e 'show status like "wsrep%"'

Đảm bảo trên tất cả các nút, wsrep_cluster_size , wsrep_cluster_status và wsrep_local_state_comment lần lượt là 3, "Chính" và "Đã đồng bộ hóa".

Quản lý MySQL

Mô-đun này có thể được sử dụng để thực hiện một số tác vụ quản lý MySQL ...

tùy chọn cấu hình (sửa đổi, áp dụng, cấu hình tùy chỉnh)
tài nguyên cơ sở dữ liệu (cơ sở dữ liệu, người dùng, tài trợ)
sao lưu (tạo, lên lịch, người dùng sao lưu, bộ nhớ)
khôi phục đơn giản (chỉ với mysqldump)
cài đặt / kích hoạt plugin

Kiểm soát dịch vụ

Cách an toàn nhất khi cấp phép Galera Cluster với Puppet là xử lý tất cả các hoạt động kiểm soát dịch vụ theo cách thủ công (không để Puppet xử lý). Đối với khởi động lại cuộn theo cụm đơn giản, lệnh dịch vụ tiêu chuẩn sẽ thực hiện. Chạy lệnh sau từng nút một.

$ systemctl restart mariadb # Systemd
$ service mariadb restart # SysVinit

Tuy nhiên, trong trường hợp phân vùng mạng xảy ra và không có thành phần chính nào khả dụng (kiểm tra với wsrep_cluster_status ), nút cập nhật nhất phải được khởi động để đưa cụm hoạt động trở lại mà không bị mất dữ liệu. Bạn có thể làm theo các bước như trong phần triển khai trên. Để tìm hiểu thêm về quy trình khởi động với kịch bản ví dụ, chúng tôi đã trình bày chi tiết vấn đề này trong bài đăng blog này, Cách khởi động MySQL hoặc MariaDB Galera Cluster.

Tài nguyên cơ sở dữ liệu

Sử dụng lớp mysql ::db để đảm bảo có một cơ sở dữ liệu với người dùng được liên kết và các đặc quyền, ví dụ:

  # make sure the database and user exist with proper grant
  mysql::db { 'mynewdb':
    user          => 'mynewuser',
    password      => 'passw0rd',
    host          => '192.168.0.%',
    grant         => ['SELECT', 'UPDATE']
  }

Định nghĩa trên có thể được gán cho bất kỳ nút nào vì mọi nút trong Cụm Galera đều là nút chính.

Sao lưu và khôi phục

Vì chúng tôi đã tạo người dùng SST bằng cách sử dụng lớp xtrabackup, Puppet sẽ định cấu hình tất cả các điều kiện tiên quyết cho công việc sao lưu - tạo người dùng sao lưu, chuẩn bị đường dẫn đích, gán quyền sở hữu và quyền, thiết lập công việc cron và thiết lập các tùy chọn lệnh sao lưu để sử dụng trong tập lệnh sao lưu được cung cấp. Mỗi nút sẽ được định cấu hình với hai công việc sao lưu (một công việc đầy đủ hàng tuần và một công việc khác cho gia tăng hàng ngày) mặc định là 11:05 chiều như bạn có thể biết từ đầu ra crontab:

$ crontab -l
# Puppet Name: xtrabackup-weekly
5 23 * * 0 /usr/local/sbin/xtrabackup.sh --target-dir=/home/backup/mysql --backup
# Puppet Name: xtrabackup-daily
5 23 * * 1-6 /usr/local/sbin/xtrabackup.sh --incremental-basedir=/home/backup/mysql --target-dir=/home/backup/mysql/`date +%F_%H-%M-%S` --backup

Nếu bạn muốn lên lịch mysqldump thay thế, hãy sử dụng lớp mysql ::server ::backup để chuẩn bị tài nguyên sao lưu. Giả sử chúng ta có khai báo sau trong tệp kê khai của mình:

  # Prepare the backup script, /usr/local/sbin/mysqlbackup.sh
  class { 'mysql::server::backup':
    backupuser     => 'backup',
    backuppassword => 'passw0rd',
    backupdir      => '/home/backup',
    backupdirowner => 'mysql',
    backupdirgroup => 'mysql',
    backupdirmode  => '755',
    backuprotate   => 15,
    time           => ['23','30'],   #backup starts at 11:30PM everyday
    include_routines  => true,
    include_triggers  => true,
    ignore_events     => false,
    maxallowedpacket  => '64M'
  }

Phần trên yêu cầu Puppet định cấu hình tập lệnh sao lưu tại /usr/local/sbin/mysqlbackup.sh và lên lịch vào lúc 11:30 tối hàng ngày. Nếu bạn muốn sao lưu ngay lập tức, chỉ cần gọi:

$ mysqlbackup.sh

Để khôi phục, mô-đun chỉ hỗ trợ khôi phục với phương pháp sao lưu mysqldump, bằng cách nhập trực tiếp tệp SQL vào cơ sở dữ liệu bằng cách sử dụng lớp mysql ::db, ví dụ:

mysql::db { 'mydb':
  user     => 'myuser',
  password => 'mypass',
  host     => 'localhost',
  grant    => ['ALL PRIVILEGES'],
  sql      => '/home/backup/mysql/mydb/backup.gz',
  import_cat_cmd => 'zcat',
  import_timeout => 900
}

Tệp SQL sẽ chỉ được tải một lần và không phải trong mọi lần chạy, trừ khi dùng cưỡng chế_sql => true.

Quản lý cấu hình

Trong ví dụ này, chúng tôi đã sử dụng management_config_file => true với override_options để cấu trúc các dòng cấu hình của chúng tôi mà sau này sẽ được Puppet đẩy ra. Bất kỳ sửa đổi nào đối với tệp kê khai sẽ chỉ phản ánh nội dung của tệp cấu hình MySQL đích. Mô-đun này sẽ không tải cấu hình vào thời gian chạy hoặc khởi động lại dịch vụ MySQL sau khi đẩy các thay đổi vào tệp cấu hình. Sysadmin có trách nhiệm khởi động lại dịch vụ để kích hoạt các thay đổi.

Để thêm cấu hình MySQL tùy chỉnh, chúng ta có thể đặt các tệp bổ sung vào "includeir", mặc định là /etc/mysql/conf.d. Điều này cho phép chúng tôi ghi đè cài đặt hoặc thêm những cài đặt bổ sung, điều này rất hữu ích nếu bạn không sử dụng override_options trong lớp máy chủ mysql ::. Việc sử dụng mẫu Con rối rất được khuyến khích ở đây. Đặt tệp cấu hình tùy chỉnh trong thư mục mẫu mô-đun (mặc định thành, / etc / rốilabs / mã / môi trường / sản xuất / mô-đun / mysql / mẫu) và sau đó thêm các dòng sau vào tệp kê khai:

# Loads /etc/puppetlabs/code/environments/production/modules/mysql/templates/my-custom-config.cnf.erb into /etc/mysql/conf.d/my-custom-config.cnf

file { '/etc/mysql/conf.d/my-custom-config.cnf':
  ensure  => file,
  content => template('mysql/my-custom-config.cnf.erb')
}

Somenines DevOps Guide to Management DatabaseTìm hiểu về những điều bạn cần biết để tự động hóa và quản lý cơ sở dữ liệu nguồn mở của mìnhTải xuống miễn phí

Puppet so với ClusterControl

Bạn có biết rằng bạn cũng có thể tự động hóa việc triển khai MySQL hoặc MariaDB Galera bằng cách sử dụng ClusterControl không? Bạn có thể sử dụng mô-đun ClusterControl Puppet để cài đặt hoặc đơn giản bằng cách tải xuống từ trang web của chúng tôi.

Khi so sánh với ClusterControl, bạn có thể mong đợi những điểm khác biệt sau:

Một chút kiến thức cơ bản để hiểu cú pháp, định dạng, cấu trúc của Con rối trước khi bạn có thể viết tệp kê khai.
Bản kê khai phải được kiểm tra thường xuyên. Rất phổ biến, bạn sẽ gặp lỗi biên dịch trên mã, đặc biệt nếu danh mục được áp dụng lần đầu tiên.
Con rối giả định các mã là không có giá trị. Điều kiện thử nghiệm / kiểm tra / xác minh thuộc trách nhiệm của tác giả để tránh gây rối cho hệ thống đang chạy.
Con rối yêu cầu một tác nhân trên nút được quản lý.
Tính không tương thích ngược. Một số mô-đun cũ sẽ không chạy chính xác trên phiên bản mới.
Giám sát cơ sở dữ liệu / máy chủ phải được thiết lập riêng.

Trình hướng dẫn triển khai của ClusterControl hướng dẫn quy trình triển khai:

Ngoài ra, bạn có thể sử dụng giao diện dòng lệnh ClusterControl có tên "s9s" để đạt được kết quả tương tự. Lệnh sau tạo Cụm Percona XtraDB ba nút (được cung cấp không có mật khẩu cho tất cả các nút đã được định cấu hình trước):

$ s9s cluster --create \
  --cluster-type=galera \
  --nodes='192.168.0.21;192.168.0.22;192.168.0.23' \
  --vendor=percona \
  --cluster-name='Percona XtraDB Cluster 5.7' \
  --provider-version=5.7 \
  --db-admin='root' \
  --db-admin-passwd='$ecR3t^word' \
  --log

Các tài nguyên liên quan Mô-đun con rối cho ClusterControl - Thêm quản lý và giám sát vào các cụm cơ sở dữ liệu hiện tại của bạn Cách tự động triển khai MySQL Galera Cluster bằng s9s CLI và Tự động hóa cơ sở dữ liệu Chef với Puppet:Triển khai MySQL &MariaDB Replication

Ngoài ra, ClusterControl hỗ trợ triển khai bộ cân bằng tải cho Galera Cluster - HAproxy, ProxySQL và MariaDB MaxScale - cùng với địa chỉ IP ảo (do Keepalived cung cấp) để loại bỏ bất kỳ điểm lỗi nào đối với dịch vụ cơ sở dữ liệu của bạn.

Sau khi triển khai, các nút / cụm có thể được theo dõi và quản lý hoàn toàn bởi ClusterControl, bao gồm phát hiện lỗi tự động, khôi phục tự động, quản lý sao lưu, quản lý bộ cân bằng tải, đính kèm nô lệ không đồng bộ, quản lý cấu hình, v.v. Tất cả những thứ này được gói lại với nhau trong một sản phẩm. Trung bình, cụm cơ sở dữ liệu của bạn sẽ hoạt động trong vòng 30 phút. Những gì nó cần chỉ là SSH không mật khẩu cho các nút đích.

Bạn cũng có thể nhập một Cụm Galera đã chạy, được triển khai bởi Puppet (hoặc bất kỳ phương tiện nào khác) vào ClusterControl để tăng cường cụm của bạn với tất cả các tính năng thú vị đi kèm với nó. Phiên bản cộng đồng (miễn phí vĩnh viễn!) Cung cấp triển khai và giám sát.

Trong tập tiếp theo, chúng tôi sẽ hướng dẫn bạn cách triển khai bộ cân bằng tải MySQL bằng Puppet. Hãy theo dõi!