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

Puppet là một công cụ quản lý hệ thống mã nguồn mở để tập trung và tự động hóa việc quản lý cấu hình. Các công cụ tự động hóa giúp giảm thiểu các tác vụ thủ công và lặp đi lặp lại, đồng thời có thể tiết kiệm rất nhiều thời gian.

Con rối hoạt động theo mặc định trong mô hình máy chủ / tác nhân. Các đại lý lấy “danh mục” của họ (trạng thái mong muốn cuối cùng) từ tổng thể và áp dụng nó cục bộ. Sau đó, họ báo cáo lại máy chủ. Danh mục được tính toán tùy thuộc vào "dữ kiện" mà máy gửi đến máy chủ, đầu vào của người dùng (tham số) và mô-đun (mã nguồn).

Trong blog này, chúng tôi sẽ hướng dẫn bạn cách triển khai và quản lý các phiên bản MySQL / MariaDB qua Puppet. Có một số công nghệ xung quanh MySQL / MariaDB như sao chép (master-slave, Galera hoặc sao chép nhóm cho MySQL), bộ cân bằng tải nhận biết SQL như ProxySQL và MariaDB MaxScale, các công cụ sao lưu và phục hồi và nhiều công cụ khác mà chúng tôi sẽ đề cập trong phần này loạt blog. Ngoài ra còn có nhiều mô-đun có sẵn trong Puppet Forge được xây dựng và duy trì bởi cộng đồng có thể giúp chúng tôi đơn giản hóa mã và tránh phát minh lại bánh xe. Trong blog này, chúng ta sẽ tập trung vào MySQL Replication.

rốilabs / mysql

Đây là mô-đun Puppet phổ biến nhất cho MySQL và MariaDB (và có lẽ là tốt nhất trên thị trường) ngay bây giờ. Mô-đun này quản lý cả cài đặt và cấu hình MySQL, cũng như mở rộng Puppet để cho phép quản lý các tài nguyên MySQL, chẳng hạn như cơ sở dữ liệu, người dùng và các khoản tài trợ.

Mô-đun được duy trì chính thức bởi nhóm Puppet (thông qua kho lưu trữ Github của rốilabs) và hỗ trợ tất cả các phiên bản chính của Puppet Enterprise 2019.1.x, 2019.0.x, 2018.1.x, Puppet> =5.5.10 <7.0.0 trên RedHat, Ubuntu, Nền tảng Debian, SLES, Scientific, CentOS, OracleLinux. Người dùng có các tùy chọn để cài đặt MySQL, MariaDB và Percona Server bằng cách tùy chỉnh kho lưu trữ gói

Ví dụ sau đây cho thấy cách triển khai máy chủ MySQL. Trên trình điều khiển con rối, hãy cài đặt mô-đun MySQL và tạo tệp kê khai:

(puppet-master)$ puppet module install puppetlabs/mysql
(puppet-master)$ vim /etc/puppetlabs/code/environments/production/manifests/mysql.pp

Thêm các dòng sau:

node "db1.local" {
  class { '::mysql::server':
    root_password => 't5[sb^D[+rt8bBYu',
    remove_default_accounts => true,
    override_options => {
      'mysqld' => {
        'log_error' => '/var/log/mysql.log',
        'innodb_buffer_pool_size' => '512M'
      }
      'mysqld_safe' => {
        'log_error' => '/var/log/mysql.log'
      }
    }
  }
}

Sau đó, trên nút tác nhân con rối, chạy lệnh sau để áp dụng danh mục cấu hình:

(db1.local)$ puppet agent -t

Trong lần chạy đầu tiên, bạn có thể gặp lỗi sau:

Info: Certificate for db1.local has not been signed yet

Chỉ cần chạy lệnh sau trên Puppet master để ký chứng chỉ:

(puppet-master)$ puppetserver ca sign --certname=db1.local
Successfully signed certificate request for db1.local

Thử lại bằng lệnh "đặc vụ rối -t" để bắt đầu lại kết nối với chứng chỉ đã ký.

Định nghĩa trên sẽ cài đặt các gói liên quan đến MySQL tiêu chuẩn có sẵn trong kho lưu trữ phân phối hệ điều hành. Ví dụ:trên Ubuntu 18.04 (Bionic), bạn sẽ cài đặt các gói MySQL 5.7.26:

(db1.local) $ dpkg --list | grep -i mysql
ii  mysql-client-5.7                5.7.26-0ubuntu0.18.04.1           amd64        MySQL database client binaries
ii  mysql-client-core-5.7           5.7.26-0ubuntu0.18.04.1           amd64        MySQL database core client binaries
ii  mysql-common                    5.8+1.0.4                         all          MySQL database common files, e.g. /etc/mysql/my.cnf
ii  mysql-server                    5.7.26-0ubuntu0.18.04.1           all          MySQL database server (metapackage depending on the latest version)
ii  mysql-server-5.7                5.7.26-0ubuntu0.18.04.1           amd64        MySQL database server binaries and system database setup
ii  mysql-server-core-5.7           5.7.26-0ubuntu0.18.04.1           amd64        MySQL database server binaries

Bạn có thể chọn các nhà cung cấp khác như Oracle, Percona hoặc MariaDB với cấu hình bổ sung trên kho lưu trữ (tham khảo phần README để biết thêm chi tiết). Định nghĩa sau sẽ cài đặt các gói MariaDB từ kho lưu trữ apt MariaDB (yêu cầu mô-đun apt Puppet):

$ puppet module install puppetlabs/apt
$ vim /etc/puppetlabs/code/environments/production/manifests/mariadb.pp
# include puppetlabs/apt module
include apt

# apt definition for MariaDB 10.3
apt::source { 'mariadb':
  location => 'http://sgp1.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,
  },
}

# MariaDB configuration
class {'::mysql::server':
  package_name     => 'mariadb-server',
  service_name     => 'mysql',
  root_password    => 't5[sb^D[+rt8bBYu',
  override_options => {
    mysqld => {
      'log-error' => '/var/log/mysql/mariadb.log',
      'pid-file'  => '/var/run/mysqld/mysqld.pid',
    },
    mysqld_safe => {
      'log-error' => '/var/log/mysql/mariadb.log',
    },
  }
}

# Deploy on db2.local
node "db2.local" {
Apt::Source['mariadb'] ->
Class['apt::update'] ->
Class['::mysql::server']
}

Lưu ý về giá trị key-> id, nơi có một cách đặc biệt để truy xuất id 40 ký tự như được hiển thị trong bài viết này:

$ sudo apt-key adv --recv-keys --keyserver hkp://keyserver.ubuntu.com:80 0xF1656F24C74CD1D8
$ apt-key adv --list-public-keys --with-fingerprint --with-colons
uid:-::::1459359915::6DC53DD92B7A8C298D5E54F950371E2B8950D2F2::MariaDB Signing Key <[email protected]>::::::::::0:
sub:-:4096:1:C0F47944DE8F6914:1459359915::::::e::::::23:
fpr:::::::::A6E773A1812E4B8FD94024AAC0F47944DE8F6914:

Trong đó giá trị id ở dòng bắt đầu bằng "fpr", là 'A6E773A1812E4B8FD94024AAC0F47944DE8F6914'.

Sau khi danh mục Con rối được áp dụng, bạn có thể truy cập trực tiếp bảng điều khiển MySQL dưới dạng root mà không cần mật khẩu rõ ràng vì mô-đun tự động định cấu hình và quản lý ~ / .my.cnf. Nếu chúng tôi muốn đặt lại mật khẩu gốc thành một thứ khác, chỉ cần thay đổi giá trị root_password trong định nghĩa Con rối và áp dụng danh mục trên nút tác nhân.

Triển khai bản sao MySQL

Để triển khai thiết lập MySQL Replication, người ta phải tạo ít nhất hai loại cấu hình để tách biệt cấu hình chủ và cấu hình phụ. Bản chính sẽ bị vô hiệu hóa chỉ đọc để cho phép đọc / ghi trong khi các nô lệ sẽ được định cấu hình với bật chỉ đọc. Trong ví dụ này, chúng ta sẽ sử dụng bản sao dựa trên GTID để đơn giản hóa cấu hình (vì cấu hình của tất cả các nút sẽ rất giống nhau). Chúng tôi sẽ muốn bắt đầu liên kết sao chép tới cái chính ngay sau khi máy phụ hoạt động.

Giả sử chúng ta đang có 3 nút sao chép master-slave MySQL:

• db1.local - chính
• db2.local - nô lệ # 1
• db3.local - nô lệ # 2

Để đáp ứng các yêu cầu trên, chúng tôi có thể viết tệp kê khai của mình thành một cái gì đó như sau:

# Puppet manifest for MySQL GTID-based replication MySQL 5.7 on Ubuntu 18.04 (Puppet v6.4.2) 
# /etc/puppetlabs/code/environments/production/manifests/replication.pp

# node's configuration
class mysql {
  class {'::mysql::server':
    root_password           => '[email protected]#',
    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',
        'server-id'               => $mysql_server_id,
        'read_only'               => $mysql_read_only,
        'gtid-mode'               => 'ON',
        'enforce_gtid_consistency'=> 'ON',
        'log-slave-updates'       => 'ON',
        'sync_binlog'             => 1,
        'log-bin'                 => '/var/log/mysql-bin',
        'read_only'               => 'OFF',
        'binlog-format'           => 'ROW',
        'log-error'               => '/var/log/mysql/error.log',
        'report_host'             => ${fqdn},
        'innodb_buffer_pool_size' => '512M'
      },
      'mysqld_safe' => {
        'log-error'               => '/var/log/mysql/error.log'
      }
    }
  }
  
  # create slave user
  mysql_user { "${slave_user}@192.168.0.%":
      ensure        => 'present',
      password_hash => mysql_password("${slave_password}")
  }

  # grant privileges for slave user
  mysql_grant { "${slave_user}@192.168.0.%/*.*":
      ensure        => 'present',
      privileges    => ['REPLICATION SLAVE'],
      table         => '*.*',
      user          => "${slave_user}@192.168.0.%"
  }

  # /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';
  }

  # executes change master only if $master_host is defined
  if $master_host {
    exec { 'change master':
      path    => '/usr/bin:/usr/sbin:/bin',
      command => "mysql --defaults-extra-file=/root/.my.cnf -e \"CHANGE MASTER TO MASTER_HOST = '$master_host', MASTER_USER = '$slave_user', MASTER_PASSWORD = '$slave_password', MASTER_AUTO_POSITION = 1; START SLAVE;\"",
      unless  => "mysql --defaults-extra-file=/root/.my.cnf -e 'SHOW SLAVE STATUS\G' | grep 'Slave_SQL_Running: Yes'"
    }
  }
}

## node assignment

# global vars
$master_host = undef
$slave_user = 'slave'
$slave_password = 'Replicas123'

# master
node "db1.local" {
  $mysql_server_id = '1'
  $mysql_read_only = 'OFF'
  include mysql
}

# slave1
node "db2.local" {
  $mysql_server_id = '2'
  $mysql_read_only = 'ON'
  $master_host = 'db1.local'
  include mysql
}

# slave2
node "db3.local" {
  $mysql_server_id = '3'
  $mysql_read_only = 'ON'
  $master_host = 'db1.local'
  include mysql
}

Buộc đại lý áp dụng danh mục:

(all-mysql-nodes)$ puppet agent -t

Trên trang cái (db1.local), chúng tôi có thể xác minh tất cả các nô lệ được kết nối:

mysql> SHOW SLAVE HOSTS;
+-----------+-----------+------+-----------+--------------------------------------+
| Server_id | Host      | Port | Master_id | Slave_UUID                           |
+-----------+-----------+------+-----------+--------------------------------------+
|         3 | db3.local | 3306 |         1 | 2d0b14b6-8174-11e9-8bac-0273c38be33b |
|         2 | db2.local | 3306 |         1 | a9dfa4c7-8172-11e9-8000-0273c38be33b |
+-----------+-----------+------+-----------+--------------------------------------+

Chú ý thêm đến phần "execute {'change master':", trong đó nó có nghĩa là một lệnh MySQL sẽ được thực thi để bắt đầu liên kết sao chép nếu điều kiện được đáp ứng. Tất cả các tài nguyên "thực thi" được thực thi bởi Puppet phải là idmpotent, có nghĩa là hoạt động sẽ có cùng tác dụng cho dù bạn chạy nó một lần hay 10.001 lần. Có một số thuộc tính điều kiện bạn có thể sử dụng như "trừ khi", "onlyif" và "tạo" để bảo vệ trạng thái chính xác và ngăn Con rối gây rối với thiết lập của bạn. Bạn có thể xóa / nhận xét phần đó nếu bạn muốn bắt đầu liên kết sao chép theo cách thủ công.

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

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

Như bạn có thể thấy trong tệp kê khai ví dụ ở trên, chúng tôi đã xác định hai tài nguyên MySQL - mysql_user và mysql_grant - để tạo người dùng và cấp đặc quyền cho người dùng tương ứng. Chúng ta cũng có thể sử dụng lớp mysql ::db để đảm bảo một cơ sở dữ liệu với người dùng được liên kết và các đặc quyền có sẵ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']
  } 

Lưu ý rằng trong sao chép MySQL, tất cả các lần ghi chỉ được thực hiện trên bản chính. Vì vậy, hãy đảm bảo rằng tài nguyên trên được gán cho cái chính. Nếu không, giao dịch sai có thể xảy ra.

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

Thông thường, chỉ cần một máy chủ lưu trữ sao lưu cho toàn bộ cụm (trừ khi bạn sao chép một tập hợp con dữ liệu). Chúng ta có thể sử dụng lớp mysql ::server ::backup để chuẩn bị các 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',
    optional_args     => ['--set-gtid-purged=OFF'] #extra argument if GTID is enabled
  }

Puppet sẽ định cấu hình tất cả các điều kiện tiên quyết trước khi chạy bản 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 tại / usr / local /sbin/mysqlbackup.sh. Sau đó, người dùng tùy thuộc vào việc chạy hoặc lên lịch tập lệnh. Để tạo một bản sao lưu ngay lập tức, chỉ cần gọi:

$ mysqlbackup.sh

Nếu chúng ta trích xuất lệnh mysqldump thực tế dựa trên phần trên, thì nó sẽ trông như thế nào:

$ mysqldump --defaults-extra-file=/tmp/backup.NYg0TR --opt --flush-logs --single-transaction --events --set-gtid-purged=OFF --all-databases

Đối với những người muốn sử dụng các công cụ sao lưu khác như Percona Xtrabackup, MariaDB Backup (chỉ MariaDB) hoặc MySQL Enterprise Backup, mô-đun cung cấp các lớp riêng sau:

• mysql ::backup ::xtrabackup (Percona Xtrabackup và MariaDB Backup)
• mysql ::backup ::mysqlbackup (MySQL Enterprise Backup)

Khai báo mẫu với Percona Xtrabackup:

  class { 'mysql::backup::xtrabackup':
    xtrabackup_package_name => 'percona-xtrabackup',
    backupuser     => 'xtrabackup',
    backuppassword => 'passw0rd',
    backupdir      => '/home/xtrabackup',
    backupdirowner => 'mysql',
    backupdirgroup => 'mysql',
    backupdirmode  => '755',
    backupcompress => true,
    backuprotate   => 15,
    include_routines  => true,
    time              => ['23','30'], #backup starts at 11:30PM
    include_triggers  => true,
    maxallowedpacket  => '64M',
    incremental_backups => true
  }

Ở trên sẽ lên lịch cho hai bản sao lưu, một bản sao lưu đầy đủ vào lúc 11:30 tối Chủ nhật hàng tuần và một bản sao lưu gia tăng vào cùng một thời điểm trừ Chủ nhật, như được hiển thị bằng kết quả công việc cron sau khi áp dụng tệp kê khai ở trên:

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

Để biết thêm chi tiết và các tùy chọn có sẵn cho lớp này (và các lớp khác), hãy xem tham khảo tùy chọn tại đây.

Đối với khía cạnh 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.

Tùy chọn 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')
}

Để triển khai các tham số cụ thể của phiên bản, hãy sử dụng chỉ thị phiên bản, ví dụ [mysqld-5.5]. Điều này cho phép một cấu hình cho các phiên bản MySQL khác nhau.

Puppet so với ClusterControl

Bạn có biết rằng bạn cũng có thể tự động triển khai bản sao MySQL hoặc MariaDB 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 một cụm sao chép MySQL 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=mysqlreplication \
      --nodes=192.168.0.41?master;192.168.0.42?slave;192.168.0.43?slave;192.168.0.44?master; \
  --vendor=oracle \
  --cluster-name='MySQL Replication 8.0' \
  --provider-version=8.0 \
  --db-admin='root' \
  --db-admin-passwd='$ecR3t^word' \
  --log

Các thiết lập sao chép MySQL / MariaDB sau được hỗ trợ:

• Sao chép master-slave (dựa trên tệp / vị trí)
• Sao chép master-slave với GTID (MySQL / Percona)
• Sao chép master-slave với MariaDB GTID
• Sao chép tổng thể - chính chủ (bán đồng bộ / không đồng bộ)
• Sao chép chuỗi Master-slave (bán đồng bộ / không đồng bộ)

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, chuyển đổi dự phòng chính, xúc tiến nô lệ, khôi phục tự động, quản lý sao lưu, 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. Phiên bản cộng đồng (miễn phí mãi mãi!) Cung cấp triển khai và giám sát. 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.

Trong phần tiếp theo, chúng tôi sẽ hướng dẫn bạn cách triển khai Galera Cluster bằng cách sử dụng cùng một mô-đun Con rối. Hãy theo dõi!