This cookbook contains all the stuffs to install and configure and manage a mariadb server on a dpkg/apt compliant system (typically debian), or a rpm/yum compliant system (typically centos)

• mariadb - This cookbook need that you have a valid apt repository installed with the mariadb official packages

• percona-xtrabackup - if you want to use the xtrabckup SST Auth for galera cluster.
• mariadb-backup - if you want to use the mariabackup SST Auth for galera cluster.
• socat - if you want to use the xtrabckup or mariabackup SST Auth for galera cluster.
• rsync - if you want to use the rsync SST Auth for galera cluster.
• debconf-utils - if you use debian platform family.

• debian - this cookbook is fully tested on debian
• ubuntu - this cookbook is fully tested on ubuntu
• centos - this cookbook is fully tested on centos

Since version 2.0.0 of this cookbook, chef 13 support is dropped. New chef 14 is the minimum version tested. If you can't upgrade your chef 13, please user the version 1.5.4 or earlier of this cookbook.

If you are wondering where all the recipes went in v2.0+, or how on earth I use this new cookbook please see upgrading.md for a full description.

It installs the mariadb.org apt or yum repository

• install - (default) Install mariadb.org apt or yum repository

To install '10.3' version:

mariadb_repository 'MariaDB 10.3 Repository' do
  version '10.3'
end

This resource installs mariadb client packages.

• install - (default) Install client packages

To install '10.3' version:

mariadb_client_install 'MariaDB Client install' do
  version '10.3'
end

This resource installs mariadb server packages.

• install - (default) Install server packages
• create - Start the service, change the user root password

To install '10.3' version:

mariadb_server_install 'MariaDB Server install' do
  version '10.3'
end

Mainly use for internal purpose. You can use it to create a new configuration file into configuration dir. You have to define 2 variables section and option. Where section is the configuration section, and option is a hash of key/value. The name of the resource is used as base for the filename.

• add - (default) Install the extra configuration file
• remove - Remove the extra configuration file

This example:

mariadb_configuration 'fake' do
  section 'mysqld'
  option :foo => 'bar'
end

will become the file fake.cnf in the include dir (depend on your platform), which contain:

[mysqld]
foo=bar

In another example, if the value start with a '#', then it's considered as a comment, and the value is printed as is (without the key):

mariadb_configuration 'fake' do
  section 'mysqld'
  option :comment1 => '# Here i am',
    :foo => bar
end

will become the file fake.cnf in the include dir (depend on your platform), which contain:

[mysqld]
# Here i am
foo=bar

• modify - (default) Maintain the configuration file

mariadb_server_configuration 'MariaDB Server Configuration' do
  version '10.3'
  client_host 'localhost'
end

Do all configuration to have a working Galera Cluster

• create - (default) Create & Maintain the configuration file
• remove - Remove the galera configuration file

If you use a chef-server, set an attribute within your cookbook to determine which nodes belong to the cluster. If your cookbook is 'mycookbook' set:

default['mycookbook']['galera']['cluster_name'] = 'my_functionnal_cluster_name'

Then all nodes to add to gcomm will be choosen with a search based on this attribute:

mariadb_galera_configuration 'MariaDB Galera Server Configuration' do
  version '10.3'
  cluster_name 'my_functionnal_cluster_name'
  cluster_search_query "mycookbook_galera_cluster_name:my_functionnal_cluster_name"
end

If you don't want to have a dynamic node galera node management, set manually the gcomm_address with all nodes you want in it:

mariadb_galera_configuration 'MariaDB Galera Server Configuration' do
  version '10.3'
  cluster_name 'my_functionnal_cluster_name'
  gcomm_address 'gcomm://node1.fqdn,node2.fqdn'
end

It's used to manage replication setup on a host. To use it, the node need to have the mysql binary installed (via the mariadb_server_install or mariadb_client_install resource).

• add - to add a new replication setup (become a slave)
• stop - to stop the slave replication
• start - to start the slave replication
• remove - to remove the slave replication configuration

The resource name need to be 'default' if your don't want to use a named connection (multi source replication in MariaDB 10).

mariadb_replication 'default' do
  user 'root'
  password 'fakepass'
  host 'fakehost'
  action :stop
end

will stop the replication on the host fakehost using the user root and password fakepass to connect to.

When you add a replication configuration, you have to define at least 4 values master_host, master_user, master_password and master_use_gtid. And if you don't want the GTID support, you have to define also master_log_file and master_log_pos

mariadb_replication 'usefull_conn_name' do
  master_host 'server1'
  master_user 'slave_user'
  master_password 'slave_password'
  master_use_gtid 'current_pos'
  action :add
end

By default, resource doesn't change master if slave is running. If you want to let resource change slave settings for replication channel while slave is running use change_master_while_running property. When it's set to true slave settings will be changed if either one of master_host, master_port, master_user, master_password and master_use_gtid was changed.

Changes of only master_log_file and/or master_log_pos don't affect server if slave is already configured.

Manage databases and execute SQL queries on them. It works by establishing a control connection to the MariaDB server using the mysql2 chef gem (automatically installed). It has 3 actions:

• create - to create a named database
• drop - to drop a named database
• query - to execute a SQL query

The full syntax of all of the properties that are available to the mariadb_database resource is:

mariadb_database 'name' do
  # Credentials for the control connection
  user                       String # defaults to 'root'
  host                       String # defaults to 'localhost'
  port                       String # defaults to node['mariadb']['mysqld']['port']
  password                   String # defaults to node['mariadb']['server_root_password'] 
  # The database to be managed
  database_name              String # defaults to 'name' if not specified
  encoding                   String # defaults to 'utf8'
  collation                  String # defaults to 'utf8_general_ci'
  sql                        String, Proc # the SQL query to execute 
  action                     Symbol # defaults to :create if not specified
end

When host has the value localhost, it will try to connect using the Unix socket defined in node['mariadb']['client']['socket'], or TCP/IP if no socket is defined.

# Create a database
mariadb_database 'wordpress-cust01' do
  host '127.0.0.1'
  user 'root'
  password node['wordpress-cust01']['mysql']['initial_root_password']
  action :create
end
 
# Drop a database
mariadb_database 'baz' do
  action :drop
end
 
# Query a database
mariadb_database 'flush the privileges' do
  sql 'flush privileges'
  action :query
end

The query action will NOT select a database before running the query, nor return the actual results from the SQL query.

Manage users and grant them privileges on database objects. It works by establishing a control connection to the MariaDB server using the mysql2 chef gem (automatically installed). It has 4 actions:

• create - to create a user
• drop - to drop a user
• grant - to grant privileges to a user
• revoke - to revoke privileges from a user

The full syntax of all of the properties that are available to the mariadb_user resource is:

mariadb_user 'name' do
  # Credentials for the control connection
  ctrl_user                  String # defaults to 'root'
  ctrl_host                  String # defaults to 'localhost'
  ctrl_port                  String # defaults to node['mariadb']['mysqld']['port']
  ctrl_password              String # defaults to node['mariadb']['server_root_password'] 
  # The user to be managed
  username                   String # defaults to 'name'
  host                       String # defaults to 'localhost'
  password                   String, HashedPassword
  # The privileges to be granted/revoked
  privileges                 Array # defaults to [:all]
  database_name              String # to grant/revoke privileges on a database 
  table                      String # to grant/revoke privileges on a particular database table
  grant_option               true|false # defaults to false 
  require_ssl                true|false # defaults to false
  require_x509               true|false # defaults to false 
  action                     Symbol # defaults to :create if not specified
end

# Create an user but grant no privileges
mariadb_user 'disenfranchised' do
  password 'super_secret'
  action :create
end
 
# Create an user using a hashed password string instead of plain text one
mariadb_user 'disenfranchised' do
  password hashed_password('md5eacdbf8d9847a76978bd515fae200a2a')
  action :create
end

# Drop a user
mariadb_user 'foo_user' do
  action :drop
end

# Grant SELECT, UPDATE, and INSERT privileges to all tables in foo db from all hosts
mariadb_user 'foo_user' do
  password 'super_secret'
  database_name 'foo'
  host '%'
  privileges [:select,:update,:insert]
  action :grant
end

1. Fork the repository on Github
2. Create a named feature branch (like add_component_x)
3. Write your change
4. Write tests for your change (if applicable)
5. Run the tests, ensuring they all pass
6. Submit a Pull Request using Github

Authors: Nicolas Blanc [email protected]