Planet MySQL

Next week in Brussels: Parallel Replication at the MySQL Pre-FOSDEM Day

FOSDEM is next weekend and I am talking about Parallel Replication on Friday, February 2nd at the MySQL Pre-FOSDEM Day (there might be tickets left in case of cancellation, attendance if free of charge).  During this talk, I will show benchmark results of MySQL 8.0 parallel replication on Booking.com real production environments.  I thought I could share a few things before the talk so here it

Percona XtraDB Cluster 5.7.20-29.24 Is Now Available

Percona announces the release of Percona XtraDB Cluster 5.7.20-29.24 (PXC) on January 26, 2018. Binaries are available from the downloads section or our software repositories.

NOTE: Due to new package dependency,
Ubuntu/Debian users should use apt-get dist-upgrade, apt upgrade, or apt-get install percona-xtradb-cluster-57 to upgrade.

Percona XtraDB Cluster 5.7.20-29.24 is now the current release, based on the following:

All Percona software is open source and free.

New Features
  • Percona XtraDB Cluster now supports Ubuntu 17.10 Artful Aardvark.
  • PXC-737: freezing gcache purge was implemented to facilitate node joining through IST, avoiding time-consuming SST process.
  • PXC-822: a usability improvement was made to error messages, the name of the configuration variable which caused the timeout was added to the message.
  • PXC-866: a new variable wsrep_last_applied, in addition towsrep_last_committed one, was introduced to clearly separate last committed and last applied transaction numbers.
  • PXC-868: on the Joiner, during SST, tmpdir variable under [sst] section can be used to specify temporary SST files storage different from the default datadir/.sst one.
Fixed Bugs
  • PXC-889: fixed an issue where a node with an invalid value for wsrep_provider  was allowed to start up and operate in standalone mode, which could lead to data inconsistency. The node will now abort in this case. Bug fixed #1728774.
  • PXC-806:  fixed an abort caused by an early read of the query_id, ensuring valid ids are assigned to subsequent transactions.
  • PXC-850:  ensured that a node, because of data inconsistency, isolates itself before leaving the cluster, thus allowing pending nodes to re-evaluate the quorum. Bug fixed #1704404.
  • PXC-867: wsrep_sst_rsync script was overwriting wsrep_debug configuration setting making it not to be taken into account.
  • PXC-873: fixed formatting issue in the error message appearing when SST is not possible due to a timeout. Bug fixed #17200094
  • PXC-874: PXC acting as async slave reported unhandled transaction errors, namely “Rolling back unfinished transaction”.
  • PXC-875: Fixed an issue where toggling wsrep_provider off and on failed to reset some internal variables and resulted in PXC logging an “Unsupported protocol downgrade” warning. Bug fixed #1379204.
  • PXC-877: fixed PXC hang caused by an internal deadlock.
  • PXC-878: thread failed to mark exit from the InnoDB server concurrency and therefore never got un-register in InnoDB concurrency system.
  • PXC-879: fixed a bug where a LOAD DATA commands used with GTIDs was executed on one node, but the other nodes would receive less rows than the first one. Bug fixed #1741818.
  • PXC-880: insert to table without primary key was possible with insertable view if pxc_strict_mode variable was set to ENFORCING . Bug fixed #1722493.
  • PXC-883: Fixed ROLLBACK TO SAVEPOINT incorrect operation on slaves by avoiding useless wsrep plugin register for a savepoint rollback. Bug fixed #1700593.
  • PXC-885: fixed IST hang when keyring_file_data is set. Bug fixed #1728688.
  • PXC-887: gcache .page files were unnecessarily created due to an error in projecting gcache free size when configured to recover on restart.
  • PXC-895: fixed transaction loss after recovery by avoiding interruption of the binlog recovery based on wsrep saved position. Bug fixed #1734113.
  • PXC-897: fixed empty gtid_executed variable after recovering the position of a node with --wsrep_recover.
  • PXC-906: fixed certification failure in the case of a node restarting at the same time when frequent TRUNCATE TABLE commands and DML writes occur simultaneously on other nodes. Bug fixed #1737731.
  • PXC-909: qpress package was turned into a dependency from suggested/recommended one on Debian 9.
  • PXC-903 and PXC-910: init.d/systemctl scripts on Debian 9 were updated to avoid starting wsrep-recover if there was no crash, and to fix an infinite loop at mysqladmin ping fail because of nonexistent ping user.
  • PXC-915: suppressing DDL/TOI replication in case of sql_log_bin zero value didn’t work when DDL statement was modifying an existing table, resulting in an error.

Help us improve our software quality by reporting any bugs you encounter using our bug tracking system. As always, thanks for your continued support of Percona!

PMM and IAM Roles

I started to use Percona Monitoring and Management (PMM) recently because it seems promising, and my friends from Percona always recommending it to try out, and frankly, at first sight, I like it. There are few things which I am not happy about, but mostly I feel OK – but when it comes to the […]

Query Optimizer Takes Data Buffering into Account

Last month I published a blog post at mysqlserverteam.com about how the Query Optimizer in MySQL 8.0 takes advantage of that InnoDB provides buffer estimates per table and index. In that blog post I showed how we got different query plans for Query 8 of the DBT-3 benchmark depending on whether the data was cached InnoDB's buffer pool or not.

In MySQL 5.6, we got a query plan that was well suited for a disk-bound scenario, while MySQL 5.7 switched to a query plan that reduces the execution time by 90% when all data is in memory. However, that came at the expense of longer execution times when data had to be read from disk. In MySQL 8.0 you get the best of both worlds. One query plan will be used when all data is in memory, and another plan will be used when most data need to be fetched from disk.

DBT-3 Query 21

I earlier blogged about another DBT-3 query, Query 21. This query showed a performance regression from MySQL 5.6 to MySQL 5.7 because the query optimizer overestimated the filtering effect of the WHERE clause. In that blog post, I promised that this can be avoided in MySQL 8.0 since you can create histograms to improve the filtering estimates. It turns out that the problem is avoided even without histograms.

In MySQL 5.7 we got this query plan for Query 21:

As discussed in the previous blog post, in MySQL 5.7, the optimizer chooses to start with table orders because it overestimates the filtering on this table. In MySQL 8.0 we still get the above query plan when all the data needs to be read from disk. However, if all data is in memory we get the following query plan:

As you can see from the diagram, the join order has been reversed. Using this new query plan reduces the execution time by 85% when all data is in memory. However, since this plan uses secondary indexes for two of the tables, it is not a good plan when most data has to be read from disk. In fact, if the optimizer had picked this plan in a disk-bound scenario, the query would have been 2.5 times slower than with the plan from 5.7. Hence, by taking into account whether data is in memory or needs to be read from disk, the optimizer is able to find a good plan for Query 21 in both scenarios.

Caveat

One thing to be aware of with this new optimizer behavior, is that running EXPLAIN on a query after it was executed, will not necessarily show the query plan that was used during execution. The previous execution of the query may have changed the content of the buffer pool. Hence, the optimizer may pick a different query plan for the next execution of the query.

MySQL Connector/NET 6.9.11 GA has been released

Dear MySQL users,

MySQL Connector/Net 6.9.11 is a maintenance release for the 6.9.x series
of the .NET driver for MySQL. It can be used for production
environments.

It is appropriate for use with MySQL server versions 5.5-5.7.

It is now available in source and binary form from
http://dev.mysql.com/downloads/connector/net/#downloadsandmirrorsites
(note that not all mirror sites may be up to date at this point-if you
can’t find this version on some mirror, please try again later or choose
another download site.)

Changes in MySQL Connector/Net 6.9.11 (2018-01-26, General Availability) Functionality Added or Changed * All demos, code samples, and test-debug scripts are now optional to install, whereas before these items were installed by default. (Bug #19248623) Bugs Fixed * Instances of the DataReader class did not close connections implicitly as expected when CommandBehavior was set to CloseConnection. This fix ensures that the connection is closed properly when the DataReader object no longer exists. (Bug #27277013) * When a decimal column was defined with a scale of zero, such as DECIMAL(8, 0), the value of the NumericPrecision field returned by the MySqlDataReader.GetSchemaTable method was lower by one. For example, it returned 7 instead of 8 as expected. (Bug #26954812, Bug #88058) * The data table returned by the MySqlDataReader.GetSchemaTable method had an inaccurate value of zero assigned to the ColumnSize field for LONGTEXT and LONGBLOB data types, and also indicated that the IsLong field value was false when it should have returned true. (Bug #26876592, Bug #87876) * The MySqlDataReader.GetSchemaTable method returned different column-size values when used with different character sets. (Bug #26876582, Bug #87868) * Support for making a secure connection to a server configured to use TLSv1.2 was limited by external factors. (Bug #25689154) * SSL connections made to a single MySQL instance could not be disconnected and created repeatedly without restarting the client application to clear the half-open sockets. (Bug #20393654, Bug #75022)

The documentation is available at:
http://dev.mysql.com/doc/connector-net/en/

Nuget packages are available at:
https://www.nuget.org/packages/MySql.Data/6.9.11
https://www.nuget.org/packages/MySql.Data.Entity/6.9.11
https://www.nuget.org/packages/MySql.Fabric/6.9.11
https://www.nuget.org/packages/MySql.Web/6.9.11

Enjoy and thanks for the support!

On behalf of the MySQL Release Team,
Nawaz Nazeer Ahamed

This Week in Data with Colin Charles 25: Meltdown/Spectre still dominate, FOSDEM approaches and Timescale gets funding

Join Percona Chief Evangelist Colin Charles as he covers happenings, gives pointers and provides musings on the open source database community.

Still on Meltdown/Spectre, this time MariaDB Corporation has published Meltdown Vulnerability Impact On MariaDB Server – interesting the comparison between glibc/tcmalloc. Worthy Facebook thread about this too, with a bit of chat about MongoDB performance. Officially MongoDB says a degradation of 10-15%. ScaleGrid has a good post, in which they test MongoDB against AWS/Azure/DigitalOcean. It’s interesting that on AWS they see a 4-5% hit on insert workloads, but on Azure its 10-20% and on DigitalOcean its 30%! (The comparison for the balanced workload is that on AWS its 2-3%, 20-205% on Azure, and 30% on DigitalOcean).

We’ve chosen tutorials for Percona Live Santa Clara, and will be announcing them soon; and by the first week of February most talks as well. Don’t forget you have the option to still get the best price at registration now.

Don’t forget that in the next week, we have FOSDEM — many Perconians will be there and look forward to meeting with you. We have a community table. Peter Zaitsev has a talk in the main track. Don’t forget the fringe events: on 2nd February there is a pre-FOSDEM MySQL Day, the MySQL & Friends Community Dinner, and also a CentOS Dojo that I will be speaking at. Looking forward to a packed & fun-filled Friday, Saturday and Sunday!

It’s worth reading this: Timescale raises $16M from Benchmark, NEA, Two Sigma Ventures for the database to help us understand our machines and our world. Timescale has been an active participant in the Percona Live events, and this round of funding bodes very well for the PostgreSQL database world.

Releases Link List Upcoming appearances Feedback

I look forward to feedback/tips via e-mail at colin.charles@percona.com or on Twitter @bytebot.

D-7: When in Europe, Join the MySQL Community Dinner at FOSDEM

It’s kind of difficult to start a blog with something original that hasn’t been written before when blogging about attending or sponsoring a particular event or conference…

What can I say?

FOSDEM 2018 is round the corner? Ready for FOSDEM 2018? Join us next week at FOSDEM 2018? All set for FOSDEM 2018 next week? The possibilities are endless…

So here we go ;-)

FOSDEM 2018 D-7!

If you’re in Europe and into open source (databases) make sure not to miss FOSDEM 2018 in Brussels, which takes place next week from the 2nd (unofficially) to the 4th of February (officially).

Thousands of open source enthusiasts will be gathering in the Belgium capital to talk latest technologies, concepts and ideas all around open source software.

If you haven’t made plans to attend yet, you can find all the details on the FOSDEM website.

Why and how are we at Severalnines involved?

Well, we help users automate and manage their open source databases and are historically closely tied to the MySQL database (on a personal and technology level) - though we also support PostgreSQL and MongoDB of course.

And the MySQL Community in Europe has always taken advantage of the FOSDEM conference to get together and exchange on the latest and greatest to do with MySQL. The group organising this particular aspect of FOSDEM is the MySQL & Friends group. With that, FOSDEM hosts a MySQL DevRoom dedicated to the open source database and related technologies.

And since the MySQL community has always been friendly towards food and drink, there is a yearly MySQL Community Dinner that takes place the evening before the official FOSDEM start.

That’s where we come in (alongside other illustrious names) since we’re co-sponsoring this year’s MySQL Community Dinner again!

This year the dinner is sponsored by Oracle MySQL, MariaDB, Facebook, Percona and our true selves, and we’d like to wish all participants a great evening and get together.

If you haven’t booked your tickets yet, there’s still time do so here.

Have fun at FOSDEM and enjoy the MySQL Community Dinner!

Tags:  MySQL mysql community mysql community dinner fosdem 2018 percona MariaDB oracle facebook

MySQL Cluster Manager 1.4.5 released!


MySQL Cluster Manager 1.4.5 is now available for download from My Oracle Support.

Overview
MCM 1.4.5 contains further stability and usability improvements of MySQL Cluster Manager.

The 1.4.5 release bundles MySQL Cluster 7.5.9. However, since MySQL Cluster 7.5.7, system tables contain sufficient information for MCM to properly support rolling reconfigurations when ndb_cluster_connection_pool is enabled for mysqlds.…

MySQL 8.0 RESOURCE_GROUP Overview

In this blog post, we’ll provide an overview of the new MySQL 8.0 RESOURCE_GROUP feature.

One great new feature introduced in MySQL 8.0 that – from my point of view – requires attention is RESOURCE_GROUP.

Short disclaimer: I want to point out that MySQL 8.0 is not GA yet, so it is possible for the MySQL 8.0 RESOURCE_GROUP implementation to change in features and/or behavior.

I’ve used MySQL Community Server 8.0 RC, and everything mentioned below applies to this MySQL version.

In this post, I will quickly look at this feature and summarize what it’s for, how it makes the DBA’s life a little bit easier and highlight some known limitations.

The MySQL documentation describes it as follows:

“MySQL supports creation and management of resource groups, and permits assigning threads running within the server to particular groups so that threads execute according to the resources available to the group. Group attributes enable control over its resources, to enable or restrict resource consumption by threads in the group. DBAs can modify these attributes as appropriate for different workloads.

“Currently, CPU time is a manageable resource, represented by the concept of “virtual CPU” as a term that includes CPU cores, hyperthreads, hardware threads, and so forth. The server determines at startup how many virtual CPUs are available, and database administrators with appropriate privileges can associate these CPUs with resource groups and assign threads to groups.”

Great, so now we can assign vCPU’s resources to the different groups and with different priorities. Before continuing to discover what resource groups are and how they’re cool, let’s take a quick look at limitations:

  • Resource groups are unavailable if you install the thread pool plugin
  • Resource groups are unavailable on macOS, which provides no API for binding CPUs to a thread
  • On FreeBSD and Solaris, resource group thread priorities are ignored (effectively, all threads run at priority 0)
  • On Linux, resource groups thread priorities are ignored unless the CAP_SYS_NICE capability is set. MySQL package installers for Linux systems should set this capability. For installation using a compressed tar file binary distribution or from source, the CAP_SYS_NICE capability can be set manually using the setcap command, specifying the pathname to the mysqld executable (this requires sudo access).
  • On Windows, threads run at one of five thread priority levels. The resource group thread priority range of -20 to 19 maps onto those levels.
  • Resource group management is local to the server on which it occurs. Resource group SQL statements and modifications to the resource_group data dictionary table are not written to the binary log and are not replicated.

Since we now know the limitations, let’s check on how we can use it for the real world scenario.

From my experience, many DBA’s have the problem of slow reporting and/or aggregation queries on the same instance when they have intensive OLTP workload and are executing some batch jobs. The easiest and usual way to solve this issue is to offload these activities to a slave instance. While this works, it takes some time to provision new hardware resources, set it up, etc. So in most cases, this approach could be considered mid-term.

What if you need to fix the resources contention issue on the existing server now, and offload such activities later? Or you cannot move a batch job to the slave since it’s required for consistency, and you cannot afford slave lag? Or in some cases, the batch job may need to perform a write so it simply can’t go to the slave?

In this case, resource groups are a good fix.

We have two default groups currently that we cannot delete or change:

mysql> SELECT * FROM INFORMATION_SCHEMA.RESOURCE_GROUPSG *************************** 1. row *************************** RESOURCE_GROUP_NAME: USR_default RESOURCE_GROUP_TYPE: USER RESOURCE_GROUP_ENABLED: 1 VCPU_IDS: 0-8 THREAD_PRIORITY: 0 *************************** 2. row *************************** RESOURCE_GROUP_NAME: SYS_default RESOURCE_GROUP_TYPE: SYSTEM RESOURCE_GROUP_ENABLED: 1 VCPU_IDS: 0-8 THREAD_PRIORITY: 0

Each group has a type, which is either SYSTEM or USER. The resource group type affects the range of priority values assignable to the group. This attribute, together with the differences in permitted priorities, enables system threads to be identified so as to protect them from contention for CPU resources against user threads.

The list below illustrates the priority ranges available and related to the each group type:

    • For system resource groups, the permitted priority range is -20 to 0.
    • For user resource groups, the permitted priority range is 0 to 19.The thread priority is the execution priority for threads assigned to the resource group. Priority values range from -20 (highest priority) to 19 (lowest priority). The default priority is 0, for both system and user groups.System groups are permitted a higher priority than user groups, ensuring that user threads never have a higher priority than system threads:

Assuming we have eight CPU’s (which is my case).

Now let’s create a resource group for our reporting queries, and another group for the batch jobs:

CREATE RESOURCE GROUP Reporting TYPE = USER VCPU = 5-6 THREAD_PRIORITY = 10;

CREATE RESOURCE GROUP Batch_job TYPE = USER VCPU = 7-8 THREAD_PRIORITY = 8;

Let’s verify if the groups were properly created:

mysql> SELECT * FROM INFORMATION_SCHEMA.RESOURCE_GROUPS WHERE RESOURCE_GROUP_NAME = 'Batch_job'G *************************** 1. row *************************** RESOURCE_GROUP_NAME: Batch_job RESOURCE_GROUP_TYPE: USER RESOURCE_GROUP_ENABLED: 1 VCPU_IDS: 7-8 THREAD_PRIORITY: 8

mysql> SELECT * FROM INFORMATION_SCHEMA.RESOURCE_GROUPS WHERE RESOURCE_GROUP_NAME = 'Reporting'G *************************** 1. row *************************** RESOURCE_GROUP_NAME: Reporting RESOURCE_GROUP_TYPE: USER RESOURCE_GROUP_ENABLED: 1 VCPU_IDS: 5-6 THREAD_PRIORITY: 10

So now let’s consider couple scenarios :

  • We already have our huge reporting query running on the server, and it consumes a lot of resources and slows everything down. In this case, we can do the following:
    • Find out the thread_id of this reporting query from Performance Schema threads table and assign a specific resource group to that thread_id:

SET RESOURCE GROUP Reporting FOR 4537;

  • To execute a single statement using the reporting group, use the RESOURCE_GROUP optimizer hint:

SELECT /*+ RESOURCE_GROUP(Reporting) */ `main_table`.`subscriber_id`, `main_table`.`subscriber_email`, `main_table`.`store_id`, `main_table`.`subscriber_status`, ( SELECT created_at FROM sales_order WHERE customer_email = main_table.subscriber_email ORDER BY created_at DESC LIMIT 1 ) AS `last_order_date`, ( SELECT entity_id FROM sales_order WHERE customer_email = main_table.subscriber_email ORDER BY created_at DESC LIMIT 1 ) AS `last_order_id`, ( SELECT increment_id FROM sales_order WHERE customer_email = main_table.subscriber_email ORDER BY created_at DESC LIMIT 1 ) AS `last_increment_id`, ( ...............................................................................

Threads assigned to the reporting group execute with its resources, which you can modify as desired.

For example, at the same time we have executed a batch job script with Batch_job group resources. As result, we need to decrease priority and allocate fewer CPU resources to the our reporting resource group. We can do this in the following way:

ALTER RESOURCE GROUP Reporting VCPU = 6 THREAD_PRIORITY = 19;

Conclusion

MySQL 8.0 RESOURCE_GROUP is a great and easy-to-use feature that can help a lot in certain cases. I have a strong feeling that the list of the manageable resources will not be limited to the CPU’s only, but will extend to other aspects of the server also. Once it’s production ready, I think many database administrators will find it very helpful and useful.

As a next step, I will run a couple of tests on resource utilization for different resources groups usage scenarios and performance results.

Percona Monitoring and Management (PMM) 1.6.1 Is Now Available

Percona announces the release of Percona Monitoring and Management 1.6.1. This release contains fixes to bugs found after Percona Monitoring and Management 1.6.0 was released.

Bug fixes
  • PMM-1660: QAN for MongoDB would not display data when authentication was enabled.
  • PMM-1822: In Metrics Monitor, some tag names were incorrect in dashboards.
  • PMM-1832: After upgrading to 1.5.2, it was not possible to disable an Amazon RDS instance on the Add RDS instance dashboard of Metrics Monitor.
  • PMM-1907: In Metrics Monitor, the tooltip of the Engine Uptime metric referred to an incorrect unit of measure.
  • PMM-1964: The same value of the Exporter Uptime metric could appear in different colors in different contexts.
  • PMM-1965: In the Prometheus Exporters Overview dashboard of Metrics Monitor, the drill down links of some metrics could direct to a wrong host.

How to Secure Galera Cluster - 8 Tips

As a distributed database system, Galera Cluster requires additional security measures as compared to a centralized database. Data is distributed across multiple servers or even datacenters perhaps. With significant data communication happening across nodes, there can be significant exposure if the appropriate security measures are not taken.

In this blog post, we are going to look into some tips on how to secure our Galera Cluster. Note that this blog builds upon our previous blog post - How to Secure Your Open Source Databases with ClusterControl.

Firewall & Security Group

The following ports are very important for a Galera Cluster:

  • 3306 - MySQL
  • 4567 - Galera communication and replication
  • 4568 - Galera IST
  • 4444 - Galera SST

From the external network, it is recommended to only open access to MySQL port 3306. The other three ports can be closed down from the external network, and only allows them for internal access between the Galera nodes. If you are running a reverse proxy sitting in front of the Galera nodes, for example HAProxy, you can lock down the MySQL port from public access. Also ensure the monitoring port for the HAProxy monitoring script is opened. The default port is 9200 on the Galera node.

The following diagram illustrates our example setup on a three-node Galera Cluster, with an HAProxy facing the public network with its related ports:

Based on the above diagram, the iptables commands for database nodes are:

$ iptables -A INPUT -p tcp -s 10.0.0.0/24 --dport 3306 -j ACCEPT $ iptables -A INPUT -p tcp -s 10.0.0.0/24 --dport 4444 -j ACCEPT $ iptables -A INPUT -p tcp -s 10.0.0.0/24 --dports 4567:4568 -j ACCEPT $ iptables -A INPUT -p tcp -s 10.0.0.0/24 --dport 9200 -j ACCEPT

While on the load balancer:

$ iptables -A INPUT -p tcp --dport 3307 -j ACCEPT

Make sure to end your firewall rules with deny all, so only traffic as defined in the exception rules is allowed. You can be stricter and extend the commands to follow your security policy - for example, by adding network interface, destination address, source address, connection state and what not.

MySQL Client-Server Encryption

MySQL supports encryption between the client and the server. First we have to generate the certificate. Once configured, you can enforce user accounts to specify certain options to connect with encryption to a MySQL server.

The steps require you to:

  1. Create a key for Certificate Authority (ca-key.pem)
  2. Generate a self-signed CA certificate (ca-cert.pem)
  3. Create a key for server certificate (server-key.pem)
  4. Generate a certificate for server and sign it with ca-key.pem (server-cert.pem)
  5. Create a key for client certificate (client-key.pem)
  6. Generate a certificate for client and sign it with ca-key.pem (client-cert.pem)

Always be careful with the CA private key (ca-key.pem) - anybody with access to it can use it to generate additional client or server certificates that will be accepted as legitimate when CA verification is enabled. The bottom line is all the keys must be kept discreet.

You can then add the SSL-related variables under [mysqld] directive, for example:

ssl-ca=/etc/ssl/mysql/ca-cert.pem ssl-cert=/etc/ssl/mysql/server-cert.pem ssl-key=/etc/ssl/mysql/server-key.pem

Restart the MySQL server to load the changes. Then create a user with the REQUIRE SSL statement, for example:

mysql> GRANT ALL PRIVILEGES ON db1.* TO 'dbuser'@'192.168.1.100' IDENTIFIED BY 'mySecr3t' REQUIRE SSL;

The user created with REQUIRE SSL will be enforced to connect with the correct client SSL files (client-cert.pem, client-key.pem and ca-cert.pem).

With ClusterControl, client-server SSL encryption can easily be enabled from the UI, using the "Create SSL Encryption" feature.

Galera Encryption

Enabling encryption for Galera means IST will also be encrypted because the communication happens via the same socket. SST, on the other hand, has to be configured separately as shown in the next section. All nodes in the cluster must be enabled with SSL encryption and you cannot have a mix of nodes where some have enabled SSL encryption, and others not. The best time to configure this is when setting up a new cluster. However, if you need to add this on a running production system, you will unfortunately need to rebootstrap the cluster and there will be downtime.

All Galera nodes in the cluster must use the same key, certificate and CA (optional). You could also use the same key and certificate created for MySQL client-server encryption, or generate a new set for this purpose only. To activate encryption inside Galera, one has to append the option and value under wsrep_provider_options inside the MySQL configuration file on each Galera node. For example, consider the following existing line for our Galera node:

wsrep_provider_options = "gcache.size=512M; gmcast.segment=0;"

Append the related variables inside the quote, delimited by a semi-colon:

wsrep_provider_options = "gcache.size=512M; gmcast.segment=0; socket.ssl_cert=/etc/mysql/cert.pem; socket.ssl_key=/etc/mysql/key.pem;"

For more info on the Galera's SSL related parameters, see here. Perform this modification on all nodes. Then, stop the cluster (one node at a time) and bootstrap from the last node that shut down. You can verify if SSL is loaded correctly by looking into the MySQL error log:

2018-01-19T01:15:30.155211Z 0 [Note] WSREP: gcomm: connecting to group 'my_wsrep_cluster', peer '192.168.10.61:,192.168.10.62:,192.168.10.63:' 2018-01-19T01:15:30.159654Z 0 [Note] WSREP: SSL handshake successful, remote endpoint ssl://192.168.10.62:53024 local endpoint ssl://192.168.10.62:4567 cipher: AES128-SHA compression:

With ClusterControl, Galera Replication encryption can be easily enabled using the "Create SSL Galera Encryption" feature.

SST Encryption

When SST happens without encryption, the data communication is exposed while the SST process is ongoing. SST is a full data synchronization process from a donor to a joiner node. If an attacker was able to "see" the full data transmission, the person would get a complete snapshot of your database.

SST with encryption is supported only for mysqldump and xtrabackup-v2 methods. For mysqldump, the user must be granted with "REQUIRE SSL" on all nodes and the configuration is similar to standard MySQL client-server SSL encryption (as described in the previous section). Once the client-server encryption is activated, create a new SST user with SSL enforced:

mysql> GRANT ALL ON *.* TO 'sst_user'@'%' IDENTIFIED BY 'mypassword' REQUIRE SSL;

For rsync, we recommend using galera-secure-rsync, a drop-in SSL-secured rsync SST script for Galera Cluster. It operates almost exactly like wsrep_sst_rsync except that it secures the actual communications with SSL using socat. Generate the required client/server key and certificate files, copy them to all nodes and specify the "secure_rsync" as the SST method inside the MySQL configuration file to activate it:

wsrep_sst_method=secure_rsync

For xtrabackup, the following configuration options must be enabled inside the MySQL configuration file under [sst] directive:

[sst] encrypt=4 ssl-ca=/path/to/ca-cert.pem ssl-cert=/path/to/server-cert.pem ssl-key=/path/to/server-key.pem

Database restart is not necessary. If this node is selected by Galera as a donor, these configuration options will be picked up automatically when Galera initiates the SST.

SELinux

Security-Enhanced Linux (SELinux) is an access control mechanism implemented in the kernel. Without SELinux, only traditional access control methods such as file permissions or ACL are used to control the file access of users.

By default, with strict enforcing mode enabled, everything is denied and the administrator has to make a series of exceptions policies to the elements of the system require in order to function. Disabling SELinux entirely has become a common poor practice for many RedHat based installation nowadays.

Depending on the workloads, usage patterns and processes, the best way is to create your own SELinux policy module tailored for your environment. What you really need to do is to set SELinux to permissive mode (logging only without enforce), and trigger events that can happen on a Galera node for SELinux to log. The more extensive the better. Example events like:

  • Starting node as donor or joiner
  • Restart node to trigger IST
  • Use different SST methods
  • Backup and restore MySQL databases using mysqldump or xtrabackup
  • Enable and disable binary logs

One example is if the Galera node is monitored by ClusterControl and the query monitor feature is enabled, ClusterControl will enable/disable the slow query log variable to capture the slow running queries. Thus, you would see the following denial in the audit.log:

$ grep -e denied audit/audit.log | grep -i mysql type=AVC msg=audit(1516835039.802:37680): avc: denied { open } for pid=71222 comm="mysqld" path="/var/log/mysql/mysql-slow.log" dev="dm-0" ino=35479360 scontext=system_u:system_r:mysqld_t:s0 tcontext=unconfined_u:object_r:var_log_t:s0 tclass=file

The idea is to let all possible denials get logged into the audit log, which later can be used to generate the policy module using audit2allow before loading it into SELinux. Codership has covered this in details in the documentation page, SELinux Configuration.

SST Account and Privileges

SST is an initial syncing process performed by Galera. It brings a joiner node up-to-date with the rest of the members in the cluster. The process basically exports the data from the donor node and restores it on the joiner node, before the joiner is allowed to catch up on the remaining transactions from the queue (i.e., those that happened during the syncing process). Three SST methods are supported:

  • mysqldump
  • rsync
  • xtrabackup (or xtrabackup-v2)

For mysqldump SST usage, the following privileges are required:

  • SELECT, SHOW VIEW, TRIGGER, LOCK TABLES, RELOAD, FILE

We are not going to go further with mysqldump because it is probably not often used in production as SST method. Beside, it is a blocking procedure on the donor. Rsync is usually a preferred second choice after xtrabackup due to faster syncing time, and less error-prone as compared to mysqldump. SST authentication is ignored with rsync, therefore you may skip configuring SST account privileges if rsync is the chosen SST method.

Moving along with xtrabackup, the following privileges are advised for standard backup and restore procedures based on the Xtrabackup documentation page:

  • CREATE, CREATE TABLESPACE, EVENT, INSERT, LOCK TABLE, PROCESS, RELOAD, REPLICATION CLIENT, SELECT, SHOW VIEW, SUPER

However for xtrabackup's SST usage, only the following privileges matter:

  • PROCESS, RELOAD, REPLICATION CLIENT

Thus, the GRANT statement for SST can be minimized as:

mysql> GRANT PROCESS,RELOAD,REPLICATION CLIENT ON *.* TO 'sstuser'@'localhost' IDENTIFIED BY 'SuP3R@@sTr0nG%%P4ssW0rD';

Then, configure wsrep_sst_auth accordingly inside MySQL configuration file:

wsrep_sst_auth = sstuser:SuP3R@@sTr0nG%%P4ssW0rD

Only grant the SST user for localhost and use a strong password. Avoid using root user as the SST account, because it would expose the root password inside the configuration file under this variable. Plus, changing or resetting the MySQL root password would break SST in the future.

MySQL Security Hardening

Galera Cluster is a multi-master replication plugin for InnoDB storage engine, which runs on MySQL and MariaDB forks. Therefore, standard MySQL/MariaDB/InnoDB security hardening recommendations apply to Galera Cluster as well.

This topic has been covered in numerous blog posts out there. We have also covered this topic in the following blog posts:

The above blog posts summarize the necessity of encrypting data at rest and data in transit, having audit plugins, general security guidelines, network security best practices and so on.

Use a Load Balancer Related resources  Announcing ClusterControl 1.5.1 - Featuring Backup Encryption for MySQL, MongoDB & PostgreSQL  PCI Compliance for MySQL & MariaDB with ClusterControl  How to Secure MySQL/MariaDB Servers

There are a number of database load balancers (reverse proxy) that can be used together with Galera - HAProxy, ProxySQL and MariaDB MaxScale to name some of them. You can set up a load balancer to control access to your Galera nodes. It is a great way of distributing the database workload between the database instances, as well as restricting access, e.g., if you want to take a node offline for maintenance, or if you want to limit the number of connections opened on the Galera nodes. The load balancer should be able to queue connections, and therefore provide some overload protection to your database servers.

ProxySQL, a powerful database reverse-proxy which understands MySQL and MariaDB, can be extended with many useful security features like query firewall, to block offending queries from the database server. The query rules engine can also be used to rewrite bad queries into something better/safer, or redirect them to another server which can absorb the load without affecting any of the Galera nodes. MariaDB MaxScale also capable of blocking queries based on regular expressions with its Database Firewall filter.

Another advantage having a load balancer for your Galera Cluster is the ability to host a data service without exposing the database tier to the public network. The proxy server can be used as the bastion host to gain access to the database nodes in a private network. By having the database cluster isolated from the outside world, you have removed one of the important attacking vectors.

That's it. Always stay secure and protected.

Tags:  security MySQL MariaDB galera

How to convert galera node to async slave and vice-versa with MariaDB Galera Cluster.

Recently, I was working with one of our customer and this is what their requirement as they want to automate this process for converting galera node to async slave and make async slave to galera node without shutting down any server. ———- I’ve tested locally with my galera cluster and it’s working smoothly. But with heavy load on the server, you might need to speed up this process. ———- Here are the steps for how to do that. I assumes that you already have working 3 nodes galera cluster if not, then for the testing purpose you can create it from my previous post. setup-three-nodes-mariadb-galera-cluster-on-single-server-with-mysql-sandbox ———- Btw, there is no matter how many nodes you have. Now, create one test1 table and add 3 records in galera cluster. MariaDB [nil]> select * from test1; +------+-----------+ | id   | name      | +------+-----------+ |    1 | nilnandan | |    2 | joshi     | |    3 | niljoshi  | +------+-----------+ 3 rows in set (0.00 sec) Step1: Stop Galera Replication on node3 MariaDB [nil]> SET GLOBAL wsrep_on=0; SET GLOBAL wsrep_cluster_address='dummy://'; Query OK, 0 rows affected (0.00 sec) Query OK, 0 rows affected (2.01 sec) Step2: get the value of wsrep_last_committed MariaDB [nil]> show global status like '%wsrep_last_committed%'; +----------------------+-------+ | Variable_name        | Value | +----------------------+-------+ | wsrep_last_committed | 40455 | +----------------------+-------+ Step3: On node2, find the binlog and check end_log_pos with the help of Xid. because wsrep_last_committed  == Xid [nil@centos68 data]$ mysqlbinlog --base64-output=decode-rows --verbose mysql-bin.000012  | grep -i "Xid = 40455" #180113  5:35:49 server id 112  end_log_pos 803         Xid = 40455 [nil@centos68 data]$ Step4: on node3, start replication from node2 CHANGE MASTER TO MASTER_HOST='127.0.0.1', MASTER_PORT=19223, MASTER_USER='repl_user' , MASTER_PASSWORD='replica123' , MASTER_LOG_FILE='mysql-bin.000012', MASTER_LOG_POS=803; Step5: Before start slave, add two more records in test1 table in Galera cluster so we can check after starting slave that aync replication between galera node2 and node3, is working or not.  MariaDB [nil]> insert into test1 values (4, 'nil'); Query OK, 1 row affected (0.00 sec) MariaDB [nil]> insert into test1 values (5, 'njoshi'); Query OK, 1 row affected (0.00 sec) Step6: On node3, start slave; Slave_IO_Running: Yes Slave_SQL_Running: Yes MariaDB [nil]> select * from test1; +------+-----------+ | id   | name      | +------+-----------+ |    1 | nilnandan | |    2 | joshi     | |    3 | niljoshi  | |    4 | nil       | |    5 | njoshi    | +------+-----------+ 5 rows in set (0.00 sec) you can see that the records which were inserted in remaining two nodes galera cluster before start slave, will be now available in this async slave. ———- Now, if we talk about vice-versa where we want to add this async slave as a 3rd node of galera cluster. Here are the steps, Step1: Stop slave MariaDB [nil]> stop slave; Query OK, 0 rows affected (0.01 sec) Step2: collect master log file and position from show slave  Master_Log_File: mysql-bin.000013 Exec_Master_Log_Pos: 683 Step3: get the relevant xid from binlog. [nil@centos68 data]$ mysqlbinlog --base64-output=decode-rows --verbose mysql-bin.000013 | grep -i "683" #180113  5:38:06 server id 112  end_log_pos 683         Xid = 40457 [nil@centos68 data]$ Step4: get the wsrep_cluster_state_uuid and add above xid with it. i.e  set global wsrep_start_position=wsrep_cluster_state_uuid:Xid here, wsrep_cluster_state_uuid     | afdac6cb-f7ee-11e7-b1c5-9e96fe6fb1e1 Step5: add two more records in galera cluster MariaDB [nil]> insert into test1 values (6, 'niljo'); Query OK, 1 row affected (0.01 sec) MariaDB [nil]> insert into test1 values (7, 'joshinil'); Query OK, 1 row affected (0.00 sec) and set these. MariaDB [nil]> set global wsrep_start_position='afdac6cb-f7ee-11e7-b1c5-9e96fe6fb1e1:40457'; Query OK, 0 rows affected (0.00 sec) MariaDB [nil]> SET GLOBAL wsrep_on=1; SET GLOBAL wsrep_cluster_address='gcomm://127.0.0.1:4030,127.0.0.1:5030'; Query OK, 0 rows affected (0.00 sec) after this, MariaDB [nil]> select * from test1; +------+-----------+ | id   | name      | +------+-----------+ |    1 | nilnandan | |    2 | joshi     | |    3 | niljoshi  | |    4 | nil       | |    5 | njoshi    | |    4 | nil       | |    5 | njoshi    | |    6 | niljo     | |    7 | joshinil  | +------+-----------+ 9 rows in set (0.00 sec) ———- We can see those records in this table which were inserted after stop slave and before start 3rd node. I would always suggest to test this on test/stage server before implement it to productions. ———- Few links to know more about async slave and Galera Cluster. http://www.fromdual.com/replication-channel-fail-over-with-galera-cluster-for-mysql https://www.percona.com/blog/2013/06/21/changing-an-async-slave-of-a-pxc-cluster-to-a-new-master/ http://linsenraum.de/erkules_int/2014/07/mariadb-galera-attaching-an-asynchronous-slave-using-gtid.html

MySQL 8.0.4 : New Default Authentication Plugin : caching_sha2_password

Starting with MySQL 8.0.4, we are changing the default authentication plugin for MySQL server from mysql_native_password to caching_sha2_password. Correspondingly, libmysqlclient will now use caching_sha2_password as the default authentication mechanism, too.

Why did we do it?

The advantage of mysql_native_password is that it support challenge-response mechanism which is very quick and does not require encrypted connection.…

MySQL Connector/NET 6.10.6 GA has been released

Dear MySQL users,

MySQL Connector/Net 6.10.6 is the third GA release with .NET Core
now supporting various connection-string options.

To download MySQL Connector/Net 6.10.6 GA, see the “Generally Available
(GA) Releases” tab at http://dev.mysql.com/downloads/connector/net/

Changes in MySQL Connector/Net 6.10.6 (2018-01-25, General Availability) Functionality Added or Changed * The .NET Core 2.0 implementation now supports the following connection-string options: AutoEnlist, InteractiveSession, Logging, Replication, and UseUsageAdvisor. For more information about the options, see Connector/Net Connection-String Options Reference (http://dev.mysql.com/doc/connector-net/en/connector-net- connection-options.html). (Bug #27297337) Bugs Fixed * When a decimal column was defined with a scale of zero, such as DECIMAL(8, 0), the value of the NumericPrecision field returned by the MySqlDataReader.GetSchemaTable method was lower by one. For example, it returned 7 instead of 8 as expected. (Bug #26954812, Bug #88058) * The data table returned by the MySqlDataReader.GetSchemaTable method had an inaccurate value of zero assigned to the ColumnSize field for LONGTEXT and LONGBLOB data types, and also indicated that the IsLong field value was false when it should have returned true. (Bug #26876592, Bug #87876) * The MySqlDataReader.GetSchemaTable method returned different column-size values when used with different character sets. (Bug #26876582, Bug #87868) * Support for making a secure connection to a server configured to use TLSv1.2 was limited by external factors. (Bug #25689154) * SSL connections made to a single MySQL instance could not be disconnected and created repeatedly without restarting the client application to clear the half-open sockets. (Bug #20393654, Bug #75022)

Nuget packages are available at:

https://www.nuget.org/packages/MySql.Data/6.10.6
https://www.nuget.org/packages/MySql.Web/6.10.6
https://www.nuget.org/packages/MySql.Data.Entity/6.10.6
https://www.nuget.org/packages/MySql.Data.EntityFrameworkCore/6.10.6
https://www.nuget.org/packages/MySql.Data.EntityFrameworkCore.Design/6.10.6

Enjoy and thanks for the support!

On behalf of the MySQL Release Team,
Nawaz Nazeer Ahamed

Percona XtraDB Cluster 5.6.38-26.23 Is Now Available

Percona announces the release of Percona XtraDB Cluster 5.6.38-26.23 (PXC) on January 24, 2018. Binaries are available from the downloads section or our software repositories.

Percona XtraDB Cluster 5.6.38-26.23 is now the current release, based on the following:

All Percona software is open-source and free.

Fixed Bugs
  • PXC-889: Fixed an issue where a node with an invalid value for wsrep_provider was allowed to start up and operate in standalone mode, which could lead to data inconsistency. The node will now abort in this case. Bug fixed #1728774.
  • Ensured that a node, because of data inconsistency, isolates itself before leaving the cluster, thus allowing pending nodes to re-evaluate the quorum. Bug fixed #1704404.
  • PXC-875: Fixed an issue where toggling wsrep_provider off and on failed to reset some internal variables and resulted in PXC logging an “Unsupported protocol downgrade” warning. Bug fixed #1379204.
  • PXC-883: Fixed ROLLBACK TO SAVEPOINT incorrect operation on slaves by avoiding useless wsrep plugin register for a savepoint rollback. Bug fixed #1700593.
  • PXC-887: gcache .page files were unnecessarily created due to an error in projecting gcache free size when configured to recover on restart.
  • Fixed transaction loss after recovery by avoiding interruption of the binlog recovery based on wsrep saved position. Bug fixed #1734113.
  • Fixed empty gtid_executed variable after recovering the position of a node with --wsrep_recover.
  • Fixed certification failure in the case of a node restarting at the same time when frequent TRUNCATE TABLE commands and DML writes occur simultaneously on other nodes. Bug fixed #1737731.
  • PXC-914: Suppressing DDL/TOI replication in case of sql_log_bin zero value didn’t work when DDL statement was modifying an existing table, resulting in an error.

Help us improve our software quality by reporting any bugs you encounter using our bug tracking system. As always, thanks for your continued support of Percona!

MySQL 8.0.4 RC: auth_socket Users Beware!

The news that the latest MySQL 8.0.4 RC (release candidate) is available is indeed exciting. But unfortunately for users of the auth_socket plugin, dangers lie in wait!

Back in November 2015, I reported Failure of auth_socket authentication with sha256_password as default. This prevents users that identify with the

auth_socket plugin from logging in after SHA256 authentication has been made (the default authentication method). With the news that in MySQL 8.0.4 RC the default_authentication_plugin is changed to caching_sha2_password, I was keen to find out if they addressed this bug.

The source code for the test was downloaded from dev.mysql.com and compiled using the release options. A few options were disabled to reduce build time, as well as setting the path prefixes and ensuring that we use my local OpenSSL libraries:

version="$(basename $(pwd))"; prefix="/home/ceri/opt/mysql/${version}"; cmake . -DBUILD_CONFIG=mysql_release \ -DCMAKE_INSTALL_PREFIX:PATH="${prefix}" \ -DMYSQL_DATADIR:PATH="${prefix}/data" \ -DWITH_SSL:STRING=system \ -DWITH_ARCHIVE_STORAGE_ENGINE:BOOL=OFF \ -DWITH_EMBEDDED_SERVER:BOOL=OFF \ -DWITH_EXTRA_CHARSETS:STRING="" \ -DWITH_FEDERATED_STORAGE_ENGINE:BOOL=OFF \ -DWITH_BLACKHOLE_STORAGE_ENGINE:BOOL=OFF \ -DWITH_BOOST="./$(find boost/ -maxdepth 1 -type d -not -name boost)"

After completing the build and build tests, MySQL Sandbox was used to create a test instance using the

low_level_make_sandbox  command for some extra control. Afterward, it is necessary to restore the default_authentication_plugin because it changed to mysql_native_password during the installation process:$ low_level_make_sandbox -d mysql-8.0.4-rc --datadir_from=script -b ~/opt/mysql/mysql-8.0.4-rc -i 8.0 -P 20804 $ sed -Ei 's/^(default_authentication_plugin=mysql_native_password)/#\1/' my.sandbox.cnf

After starting the instance, I then created the quick test case. This installs the

auth_socket plugin and creates a user that will use it to identify themselves:mysql [localhost] {root} ((none)) > show global variables like 'default_authentication_plugin'; +-------------------------------+-----------------------+ | Variable_name | Value | +-------------------------------+-----------------------+ | default_authentication_plugin | caching_sha2_password | +-------------------------------+-----------------------+ 1 row in set (0.00 sec) mysql [localhost] {root} ((none)) > install plugin auth_socket soname 'auth_socket.so'; Query OK, 0 rows affected (0.02 sec) mysql [localhost] {root} ((none)) > create user ceri@localhost identified with auth_socket; Query OK, 0 rows affected (0.04 sec) mysql [localhost] {root} ((none)) > grant all on *.* to ceri@localhost; Query OK, 0 rows affected (0.03 sec)

Sadly, a familiar outcome greeted me when trying to connect via this new user – although interestingly, a new error message!

$ ./use -uceri ERROR 2000 (HY000): Unknown MySQL error

We can see the expected error message by connecting using a 5.7 client (a handshake error):

$ ~/opt/mysql/mysql_5.7.20/bin/mysql --defaults-file=./my.sandbox.cnf -uceri ERROR 2012 (HY000): Error in server handshake

While there are lots of great improvements and new features in MySQL 8.0.4 RC, any systems that are using the

auth_socket plugin will need to ensure that they force default_authentication_plugin=mysql_native_password – at least for now.

Webinar Thursday, January 25, 2018: Troubleshooting MySQL Crashes

Please join Percona’s Principal Support Engineer, Sveta Smirnova, as she presents Troubleshooting MySQL Crashes on January 25, 2018, at 10:00 am PST (UTC -8) / 1:00 pm EST (UTC -5).

Register Now

 

This webinar is for every MySQL user! In this talk, I won’t focus on how to analyze core files, read the source code or set breakpoints. Instead, I will focus on techniques that are available to anyone, even a novice.

Many tutorials, including my own, written based on Roel Van de Paar’s video, suggest how to create and analyze core files created at the time of a crash. While this is one of the strongest possible troubleshooting techniques for crashes, it is not the only technique. There are more easy and accessible methods for any level of MySQL user.

You will learn why the MySQL Server crashes, how to identify the source of the crash and what to do to prevent crashes in the future.

“Lost connection to MySQL server” and “Server has gone away” are the messages the application sees when MySQL server crashes.

In this webinar, I will discuss:

  • What to check first
  • How to understand error messages
  • Typical reasons for crashes
  • How to find the reason for a crash without touching the MySQL source code
  • How to read backtraces

I will also cover the limitations of these techniques, such as what they don’t reveal about MySQL crashes and what is the most complicated part of each of them.

Register for the webinar now.

Sveta Smirnova, Principal Technical Services Engineer

Sveta joined Percona in 2015. Her main professional interests are working with tricky issues, bugs, finding patterns which can solve typical issues quicker, teaching others how to deal with MySQL issues, bugs and gotchas effectively. Before joining Percona Sveta worked as Support Engineer in MySQL Bugs Analysis Support Group in MySQL AB-Sun-Oracle. She is the author of book “MySQL Troubleshooting” and JSON UDF functions for MySQL.

MariaDB MI18 Conference in New York February 26–27. Meet Galera Cluster developers. Visit BlaBlaCar and Ansell Guardian Galera presentations.

Use the opportunity to talk to Galera Cluster developers and experts. Visit Galera Cluster booth at Conrad Hotel, New York City February 26-27. We will be happy to answer your questions and verify your Galera deployment plans.

There are many Galera Cluster presentations at the conference.

 

Under the Hood: Galera Cluster

Seppo Jaakola, CEO Codership

Tuesday 27th, 8:40 am – 9:30 am

This session will provide attendees with common use cases for clustering, a comprehensive explanation of how clustering works with Galera and introduce new features and improvements available in Galera Cluster 4.

 

Global Data Replication with Galera for Ansell Guardian

Greg Henderson and Louis Zircher

Monday 26th, 4:00 pm – 4:50 pm

In early 2017, we seamlessly replaced the global geo-distributed data synchronization processes supporting the Guardian application suite with MariaDB TX, resulting in better performance and vastly reduced support issues from the previous MySQL-based solution. We will discuss our preparation for this successful implementation and how MariaDB TX with clustering supports the Ansell Guardian application – and the in-house scripting tools we developed to simplify administration of it.

 

Scalability via Expendable Resources: Containers at BlaBlaCar

Maxime Fouilleul, Lead Database Architect

Tuesday 27th, 2:10 pm – 3:00 pm

When it comes to building scalable infrastructure, making resources expandable is always the right choice. In this session, we will discuss our shift to containers and high availability. We will provide an overview of our infrastructure and environment, introduce our service discovery solution and reveal what we call “Backend High Availability Pillars” with MariaDB Galera as example.

 

Choosing the Right High Availability Strategy for You

Gerardo Narvaja and Ulrich Moser, MariaDB

Monday 26th, 3:00 pm – 3:50 pm

This session will outline the high availability options available in MariaDB TX, highlight the pros and cons of different approaches, explain the trade-offs involved, and show how to optimize for consistency and/or performance.

 

 

How to Install Nginx with PHP + MySQL (LEMP) on Debian 9

This tutorial shows the installation of a Nginx web server on Debian 9 together with MySQL or MariaDB as database, PHP 7 and free Let's encrypt SSL certificate. Nginx web server is known for its stability, rich feature set, simple configuration, and low resource consumption.

Replication Features in MySQL 8.0.4

MySQL 8 second release candidate is out (MySQL 8.0.4). Besides fixes to replication issues we have also delivered a couple of enhancements in this release. Let me quickly summarize them.

  • Additional instrumentation for Group Replication (WL#9856). We have instrumented mutexes and condition synchronization objects on the group communication library.

Pages