tel. 883 59 39 89 l mail: kontakt@najlepszerolety.pl l CZYNNE PN-PT 9-17

NajlepszeRolety.PL - rolety - żaluzje - moskitiery

TEL. 883 59 39 89 / UL. MONIUSZKI 54 - MYSŁOWICE

Wieści RSS

Planet MySQL

Planet MySQL - https://planet.mysql.com
  • New Webinar: Multi-Region AWS Aurora vs Continuent Tungsten for MySQL & MariaDB
    We’re pleased to share our webinar “Multi-Region AWS Aurora vs Continuent Tungsten for MySQL & MariaDB”, recorded live on Thursday, April 18th, 2019. Our colleague Matt Lang walks you through a comparison of building a global, multi-region MySQL / MariaDB / Percona cloud back-end using AWS Aurora versus Continuent Tungsten. If you’d like to find out how multi-region AWS Aurora deployments can be improved – then this webinar is for you! We hope you enjoy it!   Recorded: Thursday, April 18th at 10am PST / 1pm EST / 4pm BST / 5pm CEST   Recording: follow this link to watch   Slides: follow this link to view   Agenda: Explore how to deploy a geo-scale MySQL / MariaDB / Percona cloud back-end with the following design criteria: Geographically distributed, low-latency data with a single consolidated view Fast local response times for read traffic Local rapid-failover, automated high availability Ability to deploy masters in multiple regions No changes to application code Complex schema changes while keeping applications available Avoiding provider lock in   Speaker: Matthew Lang Director of Professional Services – Americas at Continuent, has over 25 years of experience in database administration, database programming, and system architecture, including the creation of a database replication product that is still in use today. He has designed highly available, scalable systems that have allowed startups to quickly become enterprise organizations, utilizing a variety of technologies including open source projects, virtualization and cloud.  

  • Percona Live Presents: Vitess – Running Sharded MySQL on Kubernetes
    The topic I’m presenting addresses a growing and unfulfilled need: the ability to run stateful workloads in Kubernetes. Running stateless applications is now considered a solved problem. However, it’s currently not practical to put databases like MySQL in containers, give them to Kubernetes, and expect it to manage their life cycles. Sugu Sougoumarane, CTO of Planetscale and creator of VitessVitess addresses this need by providing all the necessary orchestration and safety, and it has multiple years of mileage to show for it. Storage is the last piece of the puzzle that needs to be solved in Kubernetes, and it’s exciting to see people look towards Vitess to fill this gap. Who’d benefit most from the presentation? Anybody that’s looking to move to Kubernetes and is wondering about what to do about their data is the perfect audience. Needless to say, vitess also addresses problems of scalability. So, those who are looking to scale mysql will also benefit from our talk. Whose presentations are you most looking forward to? I’m looking forward to An Open-Source, Cloud Native Database (CNDB) by David Cohen, of Intel, and others. They are doing something unique by bridging the gap from legacy systems and cloud-based architectures that are coming up today, and using all open source technology. I’ll be presenting my talk Vitess: Running Sharded MySQL on Kubernetes at Percona Live 2019 on Wednesday, May 29 alongside Dan Kozlowski, also of PlanetScale. If you’d like to register for the conference, use the code SEEMESPEAK for a 20% discount on your ticket. Percona Live 2019 takes place in Austin Texas from May 28 – May 30, view the full programme here. The post Percona Live Presents: Vitess – Running Sharded MySQL on Kubernetes appeared first on Percona Community Blog.

  • MySQL-python: Adding caching_sha2_password and TLSv1.2 Support
    Python 2 reaches EOL on 2020-01-01 and one of its commonly used third-party packages is MySQL-python. If you have not yet migrated away from both of these, since MySQL-python does not support Python 3, then you may have come across some issues if you are using more recent versions of MySQL and are enforcing a secured installation. This post will look at two specific issues that you may come across (caching_sha2_password in MySQL 8.0 and TLSv1.2 with MySQL >=5.7.10 when using OpenSSL) that will prevent you from connecting to a MySQL database and buy you a little extra time to migrate code. For CentOS 7, MySQL-python is built against the client library provided by the mysql-devel package, which does not support some of the newer features, such as caching_sha2_password (the new default authentication plugin as of MySQL 8.0.4) and TLSv1.2. This means that you cannot take advantage of these security features and therefore leave yourself with an increased level of vulnerability. So, what can we do about this? Thankfully, it is very simple to resolve, so long as you don’t mind getting your hands dirty! Help! MySQL-python won’t connect to my MySQL 8.0 instance First of all, let’s take a look at the issues that the latest version of MySQL-python (MySQL-python-1.2.5-1.el7.rpm for CentOS 7) has when connecting to a MySQL 8.0 instance. We will use a Docker container to help test this out by installing MySQL-python along with the Percona Server 8.0 client so that we can compare the two. => docker run --rm -it --network host --name rpm-build centos:latest # yum install -y -q MySQL-python warning: /var/cache/yum/x86_64/7/base/packages/MySQL-python-1.2.5-1.el7.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID f4a80eb5: NOKEY Public key for MySQL-python-1.2.5-1.el7.x86_64.rpm is not installed Importing GPG key 0xF4A80EB5: Userid : "CentOS-7 Key (CentOS 7 Official Signing Key) <security@centos.org>" Fingerprint: 6341 ab27 53d7 8a78 a7c2 7bb1 24c6 a8a7 f4a8 0eb5 Package : centos-release-7-6.1810.2.el7.centos.x86_64 (@CentOS) From : /etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7 # yum install -q -y https://repo.percona.com/yum/percona-release-latest.noarch.rpm; percona-release setup ps80 * Enabling the Percona Original repository <*> All done! The percona-release package now contains a percona-release script that can enable additional repositories for our newer products. For example, to enable the Percona Server 8.0 repository use: percona-release setup ps80 Note: To avoid conflicts with older product versions, the percona-release setup command may disable our original repository for some products. For more information, please visit: https://www.percona.com/doc/percona-repo-config/percona-release.html * Disabling all Percona Repositories * Enabling the Percona Server 8.0 repository * Enabling the Percona Tools repository <*> All done! # yum install -q -y percona-server-client warning: /var/cache/yum/x86_64/7/ps-80-release-x86_64/packages/percona-server-shared-8.0.15-5.1.el7.x86_64.rpm: Header V4 RSA/SHA256 Signature, key ID 8507efa5: NOKEY Public key for percona-server-shared-8.0.15-5.1.el7.x86_64.rpm is not installed Importing GPG key 0x8507EFA5: Userid : "Percona MySQL Development Team (Packaging key) <mysql-dev@percona.com>" Fingerprint: 4d1b b29d 63d9 8e42 2b21 13b1 9334 a25f 8507 efa5 Package : percona-release-1.0-11.noarch (installed) From : /etc/pki/rpm-gpg/PERCONA-PACKAGING-KEY Next we will create a client config to save some typing later on and then check that we can connect to the MySQL instance that is already running; if you don’t have MySQL running on your local machine then you can install it in the container. # cat <<EOS > /root/.my.cnf > [client] > user = testme > password = my-secret-pw > host = 127.0.0.1 > protocol = tcp > ssl-mode = REQUIRED > EOS mysql> /* hide passwords */ PAGER sed "s/AS '.*' REQUIRE/AS 'xxx' REQUIRE/" ; PAGER set to 'sed "s/AS '.*' REQUIRE/AS 'xxx' REQUIRE/"' mysql> SHOW CREATE USER CURRENT_USER(); CREATE USER 'testme'@'%' IDENTIFIED WITH 'caching_sha2_password' AS 'xxx' REQUIRE SSL PASSWORD EXPIRE DEFAULT ACCOUNT UNLOCK PASSWORD HISTORY DEFAULT PASSWORD REUSE INTERVAL DEFAULT mysql> SELECT @@version, @@version_comment, ssl_version, ssl_cipher, user FROM sys.session_ssl_status INNER JOIN sys.processlist ON thread_id = thd_id AND conn_id = CONNECTION_ID(); 8.0.12-1 Percona Server (GPL), Release '1', Revision 'b072566' TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 testme@localhost All looks good here, so now we will check that MySQLdb can also connect: # /usr/bin/python -c "import MySQLdb; dbc=MySQLdb.connect(read_default_file='~/.my.cnf').cursor(); dbc.execute('select @@version, @@version_comment, ssl_version, ssl_cipher, user from sys.session_ssl_status inner join sys.processlist on thread_id = thd_id and conn_id = connection_id()'); print dbc.fetchall()" Traceback (most recent call last): File "", line 1, in File "/usr/lib64/python2.7/site-packages/MySQLdb/__init__.py", line 81, in Connect return Connection(*args, **kwargs) File "/usr/lib64/python2.7/site-packages/MySQLdb/connections.py", line 193, in __init__ super(Connection, self).__init__(*args, **kwargs2) _mysql_exceptions.OperationalError: (2059, "Authentication plugin 'caching_sha2_password' cannot be loaded: /usr/lib64/mysql/plugin/caching_sha2_password.so: cannot open shared object file: No such file or directory") Changing the user’s authentication plugin We have hit the first issue, because MySQL 8.0 introduced the caching_sha2_password plugin and made it the default authentication plugin, so we can’t connect at all. However, we can gain access by changing the grants for the user to use the old default plugin and then test again. mysql> ALTER USER 'testme'@'%' IDENTIFIED WITH mysql_native_password BY "my-secret-pw"; # /usr/bin/python -c "import MySQLdb; dbc=MySQLdb.connect(read_default_file='~/.my.cnf').cursor(); dbc.execute('select @@version, @@version_comment, ssl_version, ssl_cipher, user from sys.session_ssl_status inner join sys.processlist on thread_id = thd_id and conn_id = connection_id()'); print dbc.fetchall()" Traceback (most recent call last): File "", line 1, in File "/usr/lib64/python2.7/site-packages/MySQLdb/__init__.py", line 81, in Connect return Connection(*args, **kwargs) File "/usr/lib64/python2.7/site-packages/MySQLdb/connections.py", line 193, in __init__ super(Connection, self).__init__(*args, **kwargs2) _mysql_exceptions.OperationalError: (1045, "Access denied for user 'testme'@'localhost' (using password: YES)") Configuring SSL options We still can’t connect, so what can be wrong? Well, we haven’t added any SSL details to the config other than specifying that we need to use SSL, so we will add the necessary options and make sure that we can connect. # cat <<EOS >> /root/.my.cnf > ssl-ca = /root/certs/ca.pem > ssl-cert = /root/certs/client-cert.pem > ssl-key = /root/certs/client-key.pem > EOS # mysql -Bse "select 1" 1 # /usr/bin/python -c "import MySQLdb; dbc=MySQLdb.connect(read_default_file='~/.my.cnf').cursor(); dbc.execute('select @@version, @@version_comment, ssl_version, ssl_cipher, user from sys.session_ssl_status inner join sys.processlist on thread_id = thd_id and conn_id = connection_id()'); print dbc.fetchall()" (('8.0.12-1', "Percona Server (GPL), Release '1', Revision 'b072566'", 'TLSv1', 'ECDHE-RSA-AES256-SHA', 'testme@localhost'),) Forcing TLSv1.2 or later to further secure connections That looks much better now, but if you look closely then you will notice that the MySQLdb connection is using TLSv1, which will make your security team either sad, angry or perhaps both as the connection can be downgraded! We want to secure the installation and keep data over the wire safe from prying eyes, so we will remove TLSv1 and also TLSv1.1 from the list of versions accepted by MySQL and leave only TLSv1.2 (TLSv1.3 is not supported with our current MySQL 8.0 and OpenSSL versions). Any guesses what will happen now? mysql> SET PERSIST_ONLY tls_version = "TLSv1.2"; RESTART; # /usr/bin/python -c "import MySQLdb; dbc=MySQLdb.connect(read_default_file='~/.my.cnf').cursor(); dbc.execute('select @@version, @@version_comment, ssl_version, ssl_cipher, user from sys.session_ssl_status inner join sys.processlist on thread_id = thd_id and conn_id = connection_id()'); print dbc.fetchall()" Traceback (most recent call last): File "", line 1, in File "/usr/lib64/python2.7/site-packages/MySQLdb/__init__.py", line 81, in Connect return Connection(*args, **kwargs) File "/usr/lib64/python2.7/site-packages/MySQLdb/connections.py", line 193, in __init__ super(Connection, self).__init__(*args, **kwargs2) _mysql_exceptions.OperationalError: (2026, 'SSL connection error: error:00000001:lib(0):func(0):reason(1)') MySQLdb can no longer connect to MySQL, sadly with a rather cryptic message! However, as we made the change that triggered this we don’t need to decipher it and can now start looking to add TLSv1.2 support to MySQLdb, so roll up your sleeves! Solution: Build a new RPM In order to build a new RPM we will need to do a little extra work in the container first of all, but it doesn’t take long and is pretty simple to do. We are going to install the necessary packages to create a basic build environment and then rebuild the MySQL-python RPM from its current source RPM. ## Download packages # yum install -q -y rpm-build yum-utils gnupg2 rsync deltarpm gcc Package yum-utils-1.1.31-50.el7.noarch already installed and latest version Package gnupg2-2.0.22-5.el7_5.x86_64 already installed and latest version Delta RPMs disabled because /usr/bin/applydeltarpm not installed. ## Create build directory tree # install -d /usr/local/builds/rpmbuild/{BUILD,RPMS,SOURCES,SPECS,SRPMS} ## Configure the RPM macro # echo "%_topdir /usr/local/builds/rpmbuild" > ~/.rpmmacros ## Switch to a temporary directory to ease cleanup # cd "$(mktemp -d)"; pwd /tmp/tmp.xqxdBeLkXs ## Download the source RPM # yumdownloader --source -q MySQL-python Enabling updates-source repository Enabling base-source repository Enabling extras-source repository ## Extract the source RPM # rpm2cpio "$(ls -1 MySQL-python*src.rpm)" | cpio -idmv MySQL-python-1.2.5.zip MySQL-python-no-openssl.patch MySQL-python.spec 234 blocks We are now ready to start making some changes to the source code and build specifications, but first of all we need to take note of another change that occurred in MySQL 8.0. Older code will reference my_config.h, which has since been removed and is no longer required for building; the fix for this will be shown below. ## Adjust the spec file to use percona-server-devel and allow a build number # sed -i "s/mysql-devel/percona-server-devel/g; s/Release: 1/Release: %{buildno}/" MySQL-python.spec ## Store the ZIP filename and extract # SRC_ZIP="$(ls -1 MySQL-python*.zip)"; unzip "${SRC_ZIP}" ## Store the source directory and remove the include of my_config.h # SRC_DIR=$(find . -maxdepth 1 -type d -name "MySQL-python*"); sed -i 's/#include "my_config.h"/#define NO_MY_CONFIG/' "${SRC_DIR}/_mysql.c" ## View our _mysql.c change # fgrep -m1 -B3 -A1 -n NO_MY_CONFIG "${SRC_DIR}/_mysql.c" 41-#if defined(MS_WINDOWS) 42-#include 43-#else 44:#define NO_MY_CONFIG 45-#endif ## Update the source # zip -uv "${SRC_ZIP}" "${SRC_DIR}/_mysql.c" updating: MySQL-python-1.2.5/_mysql.c (in=84707) (out=17314) (deflated 80%) total bytes=330794, compressed=99180 -> 70% savings Now that we have adjusted the source code and specification we can start work on the new package so that we can once again connect to MySQL. ## Sync the source to the build tree # rsync -ac ./ /usr/local/builds/rpmbuild/SOURCES/ ## Copy the new specification file to the build tree # cp -a MySQL-python.spec /usr/local/builds/rpmbuild/SPECS/ ## Build a new source RPM with our updates # rpmbuild --define "buildno 2" -bs /usr/local/builds/rpmbuild/SPECS/MySQL-python.spec Wrote: /usr/local/builds/rpmbuild/SRPMS/MySQL-python-1.2.5-2.el7.src.rpm ## Use the new source RPM to install any missing dependencies # yum-builddep -q -y /usr/local/builds/rpmbuild/SRPMS/MySQL-python-1.2.5-2.el7.src.rpm &>>debug.log ## Build a new RPM # rpmbuild --define "buildno 2" --rebuild /usr/local/builds/rpmbuild/SRPMS/MySQL-python-1.2.5-2.el7.src.rpm &>>debug.log # tail -n1 debug.log + exit 0 All went well and so we can now install the new package and see if it worked. ## Install the local RPM # yum localinstall -q -y /usr/local/builds/rpmbuild/RPMS/x86_64/MySQL-python-1.2.5-2.el7.x86_64.rpm ## Check to see which libmysqlclient is used # ldd /usr/lib64/python2.7/site-packages/_mysql.so | fgrep libmysqlclient libmysqlclient.so.21 => /usr/lib64/mysql/libmysqlclient.so.21 (0x00007f61660be000) ## Test the connection # /usr/bin/python -c "import MySQLdb; dbc=MySQLdb.connect(read_default_file='~/.my.cnf').cursor(); dbc.execute('select @@version, @@version_comment, ssl_version, ssl_cipher, user from sys.session_ssl_status inner join sys.processlist on thread_id = thd_id and conn_id = connection_id()'); print dbc.fetchall()" (('8.0.12-1', "Percona Server (GPL), Release '1', Revision 'b072566'", 'TLSv1.2', 'ECDHE-RSA-AES128-GCM-SHA256', 'testme@localhost'),) Almost there… now force user authentication with the caching_sha2_password plugin Hurrah! We can once again connect to the database and this time we are using TLSv1.2 and have thus increased our security. There is one thing left to do now though. Earlier on we needed to change the authentication plugin, so we will now change it back for extra security and see if all is still well. mysql> ALTER USER 'testme'@'%' IDENTIFIED WITH caching_sha2_password BY "my-secret-pw"; # /usr/bin/python -c "import MySQLdb; dbc=MySQLdb.connect(read_default_file='~/.my.cnf').cursor(); dbc.execute('select @@version, @@version_comment, ssl_version, ssl_cipher, user from sys.session_ssl_status inner join sys.processlist on thread_id = thd_id and conn_id = connection_id()'); print dbc.fetchall()" (('8.0.12-1', "Percona Server (GPL), Release '1', Revision 'b072566'", 'TLSv1.2', 'ECDHE-RSA-AES128-GCM-SHA256', 'testme@localhost'),) Mission successful! Hopefully, if you are finding yourself in need of a little extra time migrating away from MySQLdb then this will help. —Image modified from photo by David Clode on Unsplash

  • Galera Cluster with new Galera Replication library 3.26 and MySQL 5.6.43, MySQL 5.7.25 Generally Available (GA)
    Codership is pleased to announce a new Generally Available (GA) release of Galera Cluster for MySQL 5.6 and 5.7, consisting of MySQL-wsrep 5.6.43 and MySQL-wsrep 5.7.25 with a new Galera Replication library 3.26 (release notes, download), implementing wsrep API version 25. This release incorporates all changes to MySQL 5.6.43 (release notes, download) and 5.7.25 respectively (release notes, download). The Galera Replication library compared to to the previous 3.25 release has a few new features and enhancements: GCache page store fixes around an early release of the GCache page, a check for duplicate UUIDs to prevent a node joining with a similar UUID, and improvements to the internal handling of IPv6 addresses. From a compilation standpoint, dynamic symbol dispatch was disabled in libgalera_smm.so to avoid symbol conflicts during dynamic loading. MySQL 5.6.43 with Galera Replication library 3.26 is an updated rebase, with a few notes: on Ubuntu 16.04 Xenial, note that the server cannot be bootstrapped with systemd and must rely on the SysV init scripts. However normal server operations will work with systemd. On Debian 9 (Stretch), the service command cannot be used to start the server. MySQL 5.7.25 with Galera Replication library 3.26 is an updated rebase, with additional packages added for openSUSE Leap 15 and Ubuntu 18.04 LTS (Bionic Beaver). Similarly to the 5.6.43 release, the service command cannot be used to start the server on Debian 9 (Stretch). It should be noted that if you are trying to perform a State Snapshot Transfer (SST) between a MySQL 5.6 and MySQL 5.7 node, this operation is not supported. It should be worth noting that InnoDB tablespaces that are outside the data directory (typically /var/lib/mysql) are not supported as they may not be copied over during an SST operation. You can get the latest release of Galera Cluster from http://www.galeracluster.com. There are package repositories for Debian, Ubuntu, CentOS, RHEL, OpenSUSE and SLES. The latest versions are also available via the FreeBSD Ports Collection.

  • Jinja2 for better Ansible
    Jinja2 is a modern and designer-friendly templating language for Python frameworks. It is fast, reliable and widely used for dynamic file generation based on its parameter. In this blog, I like to share how and where jinja2 template language used in Ansible and how we can create better Ansible playbook. How it works The Jinja variables and expressions indicated using the default delimiters as follows: {% … %} for control statements (conditions) {{ … }} for expressions (variables) {# … #} for comments (describe the task) Here’s an example Jinja expressions: - hosts: 127.0.0.1 vars_files: - vars.yml tasks: - name: Checking the IP address debug: msg: "IP address {{ ip }}" - name: Checking OS name debug: msg: "OS NAME {{ os_name }}" Variable definitions are needed for Jinja to resolve expressions. In the above example, definitions are required for ip and os_name. In Ansible, more then 21 places we can declare or define variable or value to the variable, below we have shared three important places: Role defaults d Passing a YAML or JSON file with the –vars-file option Environment variables Variable files (vars_file or vars) Pass the path to a file containing variable definitions using the –vars-file option. The file path must be one of the following: Absolute file path Relative to the project path Relative to the ansible folder When –vars-file is passed, Ansible Container checks if the path is an absolute path to a file. If not, it checks for the file relative to the project path, which is the current working directory. If the file is still not found, it looks for the file relative to the ansible folder within the project path. Variable files can also be specified using the vars_files directive under settings in container.yml. For example: - hosts: 127.0.0.1 vars_files: - vars.yml tasks: ... This templating will helpful for many automation. It can be used to create a dynamic configuration for MySQL, Nagios depend upon the resources. Example: MySQL innodb_buffer_pool have to be 70% of total RAM for better performance. So it’s easy to make it from ansible variables like, mysql_innodb_buffer_pool_size: "{{ (ansible_memtotal_mb * 0.7) | int }}M" Breakdown: ansible_memtotal_mb will be retrieved from the setup module. Basically, it will return the system stats and assigned it to respected variables. Command to get complete stats about the system. To get stats about the local system: ansible --connection=local 127.0.0.1 -m setup To get stats about the remote system from the inventory file: ansible -i inventory_file group_name -m setup This can be disabled by adding the “gather_facts: no” in the respected host. Sample: - hosts: all gather_facts: no Auto generated variable definitions using the ansible stats (system resources). Based on the condition it will revert the values for the respected variables. Below is the sample yaml file which has the syntax and the variables. mysql_conf.yml: --- # MySQL connection settings. mysql_port: "3306" mysql_data_dir: "/var/lib/mysql" mysql_pid_file: "{{ mysql_data_dir }}/mysqld.pid" mysql_socket: "{{ mysql_data_dir }}/mysql.sock" # Slow query log settings. mysql_slow_query_log_enabled: yes mysql_slow_query_time: "2" mysql_slow_query_log_file: "{{ mysql_data_dir }}/mysql-slow.log" # Based on resources mysql_max_connections: "{{ (ansible_memtotal_mb // 12) | int }}" # Set .._buffer_pool_size up to 70% of RAM but beware of setting too high. mysql_innodb_buffer_pool_size: "{{ (ansible_memtotal_mb * 0.7) | int }}M" # Set .._log_file_size to 25% of buffer pool size. mysql_innodb_log_file_size: '{{ ((mysql_innodb_buffer_pool_size | string | replace("M", "") | int) * 0.25) | int }}M' When we have the variable definition ready we need to apply it for generating the configuration file with required fields. mysql_conf.j2: (template) # {{ ansible_managed }} [client] port = {{ mysql_port }} socket = {{ mysql_socket }} [mysqld] port = {{ mysql_port }} datadir = {{ mysql_data_dir }} socket = {{ mysql_socket }} pid-file = {{ mysql_pid_file }} # Slow query log configuration. {% if mysql_slow_query_log_enabled %} slow_query_log = 1 slow_query_log_file = {{ mysql_slow_query_log_file }} long_query_time = {{ mysql_slow_query_time }} {% endif %} # InnoDB settings. innodb_buffer_pool_size = {{ mysql_innodb_buffer_pool_size }} innodb_log_file_size = {{ mysql_innodb_log_file_size }} # Setting max connections {% if mysql_max_connections | int > 3000 %} max_connections = 3000 thread_cache_size = {{ (3000 * 0.15) | int }} {% elif mysql_max_connections | int < 150 %} max_connections = 150 thread_cache_size = {{ (150 * 0.15) | int }} {% else %} max_connections = {{ mysql_max_connections }} thread_cache_size = {{ (mysql_max_connections | int * 0.15) | int }} {% endif %} Above will have the condition mapping along with the variable precedence. If the condition matches it will return the values with respect to the resource or it will keep the default value. Playbook: - hosts: 127.0.0.1 vars_files: - mysql_conf.yml tasks: - name: Creating my.cnf with respected resources template: src: mysql_conf.j2 dest: my.cnf Command to generate my.cnf using the template: ansible-playbook playbook.yml Output: Mydbops-MacBook-Air:jinja dhanasekar$ ansible-playbook playbook.yml PLAY [127.0.0.1] ********************************************** TASK [Gathering Facts] **************************************** ok: [127.0.0.1] TASK [Creating my.cnf with respected resources] *************** changed: [127.0.0.1] PLAY RECAP **************************************************** 127.0.0.1                  : ok=2    changed=1    unreachable=0    failed=0 my.cnf: (OUTPUT) # Ansible managed [client] port = 3306 socket = /var/lib/mysql/mysql.sock [mysqld] port = 3306 datadir = /var/lib/mysql socket = /var/lib/mysql/mysql.sock pid-file = /var/lib/mysql/mysqld.pid # Slow query log configuration. slow_query_log = 1 slow_query_log_file = /var/lib/mysql/mysql-slow.log long_query_time = 2 # InnoDB settings. innodb_buffer_pool_size = 5734M innodb_log_file_size = 1433M # Setting max connections max_connections = 682 thread_cache_size = 102 The above cnf was generated using the template. I hope it will give you a better idea about templating using Jinja2. Key takeaways: Easy to debug. Line numbers of exceptions directly point to the correct line in the template even with the column number. Configurable syntax with respected the yaml files.