This page contains links to Ansible modules and roles that can be used to automate MariaDB deployment and configuration. The list is not meant to be exhaustive. Use it as a starting point, but then please do your own research.
At the time of writing, there are no MariaDB-specific modules in Ansible Galaxy. MySQL modules can be used. Trying to use MySQL-specific features may result in errors or unexpected behavior. However, the same applies when trying to use a feature not supported by the MySQL version in use.
Currently, the MySQL collection in Ansible Galaxy contains at least the following modules:
: manages MySQL databases.
: gathers information about a MySQL server.
: runs SQL queries against MySQL.
: configures and operates asynchronous replication.
: creates, modifies and deletes MySQL users.
: manages MySQL configuration.
Note that some modules only exist as shortcuts, and it is possible to use mysql_query instead. However, it is important to notice that mysql_query is not idempotent. Ansible does not understand MySQL queries, therefore it cannot check whether a query needs to be run or not.
To install this collection locally:
MariaDB Corporation maintains a on GitHub.
Let's see some other modules that are useful to manage MariaDB servers.
Modules like and allow one to run system commands.
To deploy on Windows, and can be used.
Among other things, it is possible to use one of these modules to run MariaDB queries:
The main disadvantage with these modules is that they are not idempotent, because they're meant to run arbitrary system commands that Ansible can't understand. They are still useful in a variety of cases:
To run queries, because mysql_query is also not idempotent.
In cases when other modules do not allow us to use the exact arguments we need to use, we can achieve our goals by writing shell commands ourselves.
To run custom scripts that implement non-trivial logic. Implementing complex logic in Ansible tasks is possible, but it can be tricky and inefficient.
To call . There may be specific roles for some of the most common tools, but most of the times using them is an unnecessary complication.
An important part of configuration management is copying to remote servers.
The allows us to copy files to target hosts. This is convenient for static files that we want to copy exactly as they are. An example task:
As you can see, the local name and the name on remote host don't need to match. This is convenient, because it makes it easy to use different configuration files with different servers. By default, files to copy are located in a files subdirectory in the role.
However, typically the content of a configuration file should vary based on the target host, the group and various variables. To do this, we can use the module, which compiles and copies templates written in .
A simple template task:
Again, the local and the remote names don't have to match. By default, Jinja templates are located in a templates subdirectory in the role, and by convention they have the .j2 extension. This is because Ansible uses Jinja version 2 for templating, at the time writing.
A simple template example:
The following modules are also often used for database servers:
, or . Package is package manager-agnostic. Use them to install, uninstall and upgrade packages.
, useful to create the system user and group that run MariaDB binary.
can be used to make sure that MariaDB directories (like the data directory) exist and have proper permissions. It can also be used to upload static files.
allows to create configuration files (like
Specific roles exist for MariaDB in Ansible Galaxy. Using them for MariaDB is generally preferable, to be sure to avoid and to probably be able to use some MariaDB specific . However, using MySQL or Percona Server roles is also possible. This probably makes sense for users who also administer MySQL and Percona Server instances.
To find roles that suits you, check . Most roles are also available on GitHub.
You can also search roles using the tool:
(video)
Content initially contributed by .
This page is licensed: CC BY-SA / Gnu FDL
my.cnfservice is useful after installing MariaDB as a service, to start it, restart it or stop it.
ansible-galaxy collection install community.mysql- name: Make the server read-only
# become root to log into MariaDB with UNIX_SOCKET plugin
become: yes
shell: $( which mysql ) -e "SET GLOBAL read_only = 1;"- name: Copy my.cnf
copy:
src: ./files/my.cnf.1
dest: /etc/mysql/my.cnf- name: Compile and copy my.cnf
copy:
src: ./templates/my.cnf.j2
dest: /etc/mysql/my.cnf## WARNING: DO NOT EDIT THIS FILE MANUALLY !!
## IF YOU DO, THIS FILE WILL BE OVERWRITTEN BY ANSIBLE
[mysqld]
innodb_buffer_pool_size = {{ innodb_buffer_pool_size }}
<div data-gb-custom-block data-tag="if" data-0='true' data-1='true' data-2='true' data-3='true'>
connect_work_size = {{ connect_work_size }}
</div>ansible-galaxy search mariadb