MySQL Shell is a pretty nice piece of software. Is not just another mysql client but it is also a tool that offers scripting capabilities for JavaScript and Python. And one of the coolest things you can do with it is to check if your MySQL 5.7 server is ready for an upgrade or not. Enter: Upgrade Checker Utility.

MySQL Shell Upgrade Checker Utility

So what is it? It is a script that will check your MySQL 5.7 instance for compatibility errors and issues with upgrading. It’s important to notice the word “check”. It doesn’t fix. Just check. Fix is on you, friendly DBA (or we can happily assist with it).

But isn’t there something that already does that? Close, but no. The mysqlchk program and the –check-upgrade parameter does something similar: Invokes the CHECK TABLE …. FOR UPGRADE command. The Upgrade Checker goes beyond that. There are also instructions to perform the same checks independently, available here: https://dev.mysql.com/doc/refman/8.0/en/upgrade-prerequisites.html

Now, how can I use it? First of all, you’ll have to install the MySQL Shell package:

yum install -y mysql-shell.x86_64
….
….
Transaction test succeeded
Running transaction
  Installing : mysql-shell-8.0.17-1.el7.x86_64                                                                      1/1
  Verifying  : mysql-shell-8.0.17-1.el7.x86_64                                                                      1/1

Installed:
  mysql-shell.x86_64 0:8.0.17-1.el7

Now you are ready to perform the check. Is a simple as executing this one-liner:

mysqlsh root@localhost -e “util.checkForServerUpgrade();”

[root@mysql2 ~]# mysqlsh root@localhost -e "util.checkForServerUpgrade();"
The MySQL server at /var%2Flib%2Fmysql%2Fmysql.sock, version 5.7.27-log - MySQL
Community Server (GPL), will now be checked for compatibility issues for
upgrade to MySQL 8.0.17...

1) Usage of old temporal type
  No issues found

2) Usage of db objects with names conflicting with reserved keywords in 8.0
  No issues found

3) Usage of utf8mb3 charset
  No issues found

4) Table names in the mysql schema conflicting with new tables in 8.0
  No issues found

5) Partitioned tables using engines with non native partitioning
  No issues found

6) Foreign key constraint names longer than 64 characters
  No issues found

7) Usage of obsolete MAXDB sql_mode flag
  No issues found

8) Usage of obsolete sql_mode flags
  No issues found

9) ENUM/SET column definitions containing elements longer than 255 characters
  No issues found

10) Usage of partitioned tables in shared tablespaces
  No issues found

11) Circular directory references in tablespace data file paths
  No issues found

12) Usage of removed functions
  No issues found

13) Usage of removed GROUP BY ASC/DESC syntax
  No issues found

14) Removed system variables for error logging to the system log configuration
  To run this check requires full path to MySQL server configuration file to be specified at 'configPath' key of options dictionary
  More information:
    https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-13.html#mysqld-8-0-13-logging

15) Removed system variables
  To run this check requires full path to MySQL server configuration file to be specified at 'configPath' key of options dictionary
  More information:
    https://dev.mysql.com/doc/refman/8.0/en/added-deprecated-removed.html#optvars-removed

16) System variables with new default values
  To run this check requires full path to MySQL server configuration file to be specified at 'configPath' key of options dictionary
  More information:
    https://mysqlserverteam.com/new-defaults-in-mysql-8-0/

17) Schema inconsistencies resulting from file removal or corruption
  No issues found

18) Issues reported by 'check table x for upgrade' command
  No issues found

19) New default authentication plugin considerations
  Warning: The new default authentication plugin 'caching_sha2_password' offers
    more secure password hashing than previously used 'mysql_native_password'
    (and consequent improved client connection authentication). However, it also
    has compatibility implications that may affect existing MySQL installations.
    If your MySQL installation must serve pre-8.0 clients and you encounter
    compatibility issues after upgrading, the simplest way to address those
    issues is to reconfigure the server to revert to the previous default
    authentication plugin (mysql_native_password). For example, use these lines
    in the server option file:

    [mysqld]
    default_authentication_plugin=mysql_native_password

    However, the setting should be viewed as temporary, not as a long term or
    permanent solution, because it causes new accounts created with the setting
    in effect to forego the improved authentication security.
    If you are using replication please take time to understand how the
    authentication plugin changes may impact you.
  More information:
    https://dev.mysql.com/doc/refman/8.0/en/upgrading-from-previous-series.html#upgrade-caching-sha2-password-compatibility-issues
    https://dev.mysql.com/doc/refman/8.0/en/upgrading-from-previous-series.html#upgrade-caching-sha2-password-replication

Errors:   0
Warnings: 1
Notices:  0

No fatal errors were found that would prevent an upgrade, but some potential issues were detected. Please ensure that the reported issues are not significant before upgrading.

Cool, right?

Some things were missing due to lack of parameter. Let’s pass it.

util.checkForServerUpgrade('root@localhost:3306', {"password":"password", "targetVersion":"8.0.11", "configPath":"/etc/my.cnf"})

Now we have 22 warnings instead of one!

13) System variables with new default values
  Warning: Following system variables that are not defined in your
    configuration file will have new default values. Please review if you rely on
    their current values and if so define them before performing upgrade.
  More information:
    https://mysqlserverteam.com/new-defaults-in-mysql-8-0/

  back_log - default value will change
  character_set_server - default value will change from latin1 to utf8mb4
  collation_server - default value will change from latin1_swedish_ci to
    utf8mb4_0900_ai_ci
  event_scheduler - default value will change from OFF to ON
  explicit_defaults_for_timestamp - default value will change from OFF to ON
  innodb_autoinc_lock_mode - default value will change from 1 (consecutive) to
    2 (interleaved)
  innodb_flush_method - default value will change from NULL to fsync (Unix),
    unbuffered (Windows)
  innodb_flush_neighbors - default value will change from 1 (enable) to 0
    (disable)
  innodb_max_dirty_pages_pct - default value will change from 75 (%)  90 (%)
  innodb_max_dirty_pages_pct_lwm - default value will change from_0 (%) to 10
    (%)
  innodb_undo_log_truncate - default value will change from OFF to ON
  innodb_undo_tablespaces - default value will change from 0 to 2
  log_error_verbosity - default value will change from 3 (Notes) to 2 (Warning)
  max_allowed_packet - default value will change from 4194304 (4MB) to 67108864
    (64MB)
  max_error_count - default value will change from 64 to 1024
  optimizer_trace_max_mem_size - default value will change from 16KB to 1MB
  performance_schema_consumer_events_transactions_current - default value will
    change from OFF to ON
  performance_schema_consumer_events_transactions_history - default value will
    change from OFF to ON
  slave_rows_search_algorithms - default value will change from 'INDEX_SCAN,
    TABLE_SCAN' to 'INDEX_SCAN, HASH_SCAN'
  table_open_cache - default value will change from 2000 to 4000
  transaction_write_set_extraction - default value will change from OFF to
    XXHASH64

There’s some work to do there.

And now the question:

Does it work with Percona Server for MySQL? Yes, it does!

To avoid messing with repos I just got the Shell from the MySQL downloads:

wget https://dev.mysql.com/get/Downloads/MySQL-Shell/mysql-shell-8.0.17-linux-glibc2.12-x86-64bit.tar.gz; tar -xvzf mysql-shell-8.0.17-linux-glibc2.12-x86-64bit.tar.gz;  cd mysql-shell-8.0.17-linux-glibc2.12-x86-64bit/bin/;./mysqlsh

In conclusion, doing the pre-checks required to go from MySQL 5.7 to MySQL 8 is easier than ever with the MySQL Shell Upgrade Checker Utility. Besides reading the release notes before doing so, the only necessary step to perform is now a command that will leave little room for mistakes. Happy upgrade!

When building network libraries for Node.js, as we do at work, one quite quickly comes by Node's Buffer type. A Buffer gives access to a memory region in a quite raw form, allowing to handle raw data and allowing to interpret binary streams. The Buffer interface predates ES6 TypedArrays and has some optimizations.

Two optimisations are notable:

For one the slice() method does not copy data, but returns a view on the underlying data. This makes it quite efficient to work on a window of the data, but when writing one has to be careful. Simple example:

const buffer = Buffer.from("hello");
const slice = buffer.slice(1,2);
slice[0] = 97;
console.log(buffer.toString('utf8')); // will print 'hallo'

The second one is that allocating a small buffer won't actually go to the operating system and allocate a memory area, but Node.js has a memory region from which small buffers can be derived quickly. This actually works by using the slicing logic.

const buffer1 = Buffer.from("hello");
const buffer2 = Buffer.from("world");
console.log(buffer1.byteOffset);   // 0
console.log(buffer2.byteOffset);   // 8

This indicates that both buffers use the same memory region with an alignment of 8 bytes.

So how does this work? - Underlying the Buffer, in modern versions of Node is an ArrayBuffer. We can ask the Buffer to provide us with the underlying ArrayBuffer using the .buffer property. One thing one has to be careful about is that for a slice the returned ArrayBuffer will be the full buffer and not only a sliced part. Giving the two Buffers from above we can see this.

const buffer3 = Buffer.from(buffer2.buffer);
console.log(buffer3.length);    // 8192
const buffer4 = buffer3.slice(0, 5);
console.log(buffer4.toString('utf8'));  // hello

A raw ArrayBuffer doesn't provide many things, but we can create a new Buffer on top of it. This won't copy the data, but use the same memory as above. We can see the the pre-allocated block by Node (in the version I'm using for this test) apparantely is 8192 bytes. 8k is a common size used for multiple buffers. A factor in such a choice is that many filesystems use 512 byte blocks and 8k is a handleable multiple of it. Additionally CPU caches often are mutiples of 8k. So this is not a fully arbitrary choice.

Since most of the data most likely is rubbish we slice it and look at the beginning of the data and notably we're not seeing "world", but "hello" confirming that these are indeed using the same underlying buffer.

As said Buffer is a Node-specific type and different Node.js libraries can't handle it. One of thosel ibraries we use is the Google Protocol Buffer library. In simple terms protobuf is a format for serializing data for example for exchange over network. We can call it a typed and more efficient JSON alternative.

Protobuf's deserializeBinary() function now won't work with Buffer instaces, but requires a TypedArray, like Uint8Array. A Uint8Array is the ES6 counterpart to Node's Buffer. It is a layer on top of ArrayBuffer for accessing bytes.

The easy way to make it work is converting a Buffer to Uint8Array like this:

const buf = stream.read(length);
const u8 = new Uint8Array(buf);
const msg = Message.deserializeBinary(u8);

However this is inefficient as the Uint8Array constructor will copy the data. But as we learned, both Buffer and Uint8Array are just views on top of an ArrayBuffer. The Buffer gives us access to the ArrayBuffer and if we are careful about our slicing offsets we can ask the Uint8Array to re-use the same memory without copying:

const buf = stream.read(length);
const u8 = new Uint8Array(buf.buffer, buf.byteOffset, buf.length);
const msg = Message.deserialzeBinary(u8);

A tiny bit more to type, but a notable gain in performance, which we can verify with a trivial benchmark:

console.time("A");
for (let i = 0; i < 1000; ++i) {
    const b = new Buffer(10000);
    const u = new Uint8Array(b);
}
console.timeEnd("A");

console.time("B");
for (let i = 0; i < 1000; ++i) {
    const b = new Buffer(10000);
    const u = new Uint8Array(b.buffer, b.byteOffset, b.length);
}
console.timeEnd("B");

On my machine I see results like

A: 9.895ms
B: 5.216ms

Difference in a real application of course will be different.

Author: Robert Agar

One of the tasks that a database team needs to be prepared to perform is a MySQL migration. In the deep, dark past of the early 21st Century, this would have involved moving a MySQL database from one server to another one located within your company’s data center. This might have been done to take advantage of better hardware with which to provide optimal service to the database’s end users. As the IT needs of a business change, systems are often shuffled around to make the best use of computing resources.

Besides enjoying the faster performance the main impact of migration on your database team is the requirement to use a different IP address to connect to the server hosting the databases they support. No big deal. The assumption would be that all tools and monitoring platforms in place before the migration will continue to function correctly. Once the dust settles, all is well in the world of your DBAs.

If your database team is called upon to engage in a MySQL migration tomorrow, chances are good that it involves the cloud in some way. The migration can be from your on-premises systems to a cloud provider. Your company may be moving its IT environment already hosted in the cloud to a different service. In some cases, a business may decide that the cloud was not the right move for a particular system and want to bring it back to their physical data center.

Let’s take a look at the challenges that you may face as a DBA when you are required to move a MySQL database around in the cloud.

Migrating a MySQL Database to a Cloud Provider

The popularity of MySQL demands that the major cloud providers include support for the database platform in their portfolio of services. Google, Amazon, Oracle, and Microsoft are some of the potential landing places for your cloud databases. There will necessarily be some specific steps that must be taken to migrate to a particular vendor, but there are many general database migration tips and procedures that will serve you well no matter which provider your company selects.

Preparation is the cornerstone of a successful MySQL migration. Preparing for migration can be broken down into two equally important components.

Understanding your environment

Before you embark on your migration journey, you need to fully understand all of the moving parts associated with the move. Failure to address this important aspect of your migration will negatively impact its chances of success. Here are some specific aspects of the system that need to be addressed before moving forward.

Database – It may seem obvious, but a deep understanding of the database being migrated is vitally important when commencing the process. Thorough knowledge regarding the size of the database and its tables and schemas is required. You also need to know if you have any unique data types in the schemas and if there are numerous large objects that may slow down the process.

Network – Migration requires data movement and your network is the highway over which your database’s information will travel. One very important detail to attend to is ensuring that the proper teams are involved to open firewall ports and configure routing to enable data flow. Your network’s available bandwidth is also a critical consideration that will determine if you can complete the migration in the required time frame.

Planning for the migration

You need to adequately plan for database migration. It’s not the kind of thing that you decide to do on a whim. Assuming that there has already been a discussion about the benefits of migrating and the provider that will host your database, you need to plan the details of the actual move itself.

The main factors to consider are the amount of time that the migration will take and the human resources who will perform the work. You want to be realistic in developing your timetable to ensure that all loose ends are addressed before proceeding. You also want to engage a team of your best people. The last thing you need is to have a migration fail because of technical inexperience.

Once the proper planning is finished and the system is fully understood you are ready to go ahead with the migration. Some potential pitfalls to be aware of include:

• The complexity of your source data can complicate the migration process.
• Data loss or corruption is possible during the migration process. You should use tools to validate the migrated data and reconcile details such as the number of records that are moved.
• Inconsistent data quality can result from issues experienced while migrating. Data should be tested thoroughly and early in the process to ensure the data is valid before signing off on the success of the migration.

Ensuring Stability After Migration

We now fast-forward to the migration postmortem meetings. The process has been successfully performed and the database team is now settling in for the first day of administering their old acquaintance who now has a new address. Fortunately, the main tool they use to keep the database running smoothly has not changed at all.

SQL Diagnostic Manager for MySQL offers your DBAs the same level of functionality when monitoring their MySQL instances no matter where they are located. The real-time monitoring, configuration change tracking, and custom dashboards and charts work the same way whether the database is down the hall or somewhere in the cloud.

This removes one source of stress as your team can concentrate on identifying potential areas for optimization that are presented by the migration without the need to learn a new tool. Using SQL Diagnostic Manager for MySQL on both sides of your migration can be a big help in ensuring its success.

The post Minimizing the Stress of Migrating MySQL to the Cloud appeared first on Monyog Blog.

As follow up to the previous blog announcement from July about the conferences and events MySQL & MySQL Community Team are attending, we would like to inform you about where you can find us during October & November 2019. Please find the list below:

October 2019:

• PerconaLive, Amsterdam, Holland, September 30-October 2, 2019
  • For detailed information see the blog post from last week.
• OpenTech Summit, Bangkok, Thailand, October 1-2, 2019
  • MySQL becomes a Gold sponsor with a Gold booth in the expo area and four MySQL talks as follows:
    • "MySQL Overview for Oracle DBAs" given by Ryan Kuan, the MySQL Master Principal Solution Engineer. Talk scheduled for Oct 1 @14:00.
    • "The Secret of MySQL InnoDB cluster Deployment" given by Ivan Ma, the MySQL Principal Solution Engineer. Talk scheduled for Oct 1 @14:30
    • "Unleasing the power of NoSQL using MySQL 8.0" given by Ryan Kuan. Talks scheduled for Oct 1 @ 16:00.
    • "MySQL Troubleshooting and Performance Analysis" given by Ivan Ma. Talk scheduled for Oct 1 @16:30.
  • Come to visit our booth to talk to our MySQL experts! 
• JCConf, Taipei, Taiwan (October 4, 2019)
  • As a tradition MySQL is a Silver sponsor of this Java conference. This year you can find our team at the MySQL booth in the expo area as well as find a MySQL talk in the schedule as follows: 
    • "How Java Leverage MySQL Cluster To Build Application with 99.9999% Availability" given by Ivan Tu, the MySQL Solution Engineering Manager. His talk is scheduled for 13:55-14:40.
  • There is also a 3 minutes MySQL talk before sessions scheduled.
  • We are looking forward to talking to you at JCConf this year!
• Gitex, Dubai, United Arab Emirates, October 6-10, 2019
  • As usual our MySQL representatives are present at Gitex in Dubai. You can find us at Oracle booth or around if you are present. 
• Little Rock Tech Fest, Little Rock, AR, US, October 10-11, 2019
  • As a Silver sponsor MySQL will get a booth in the expo area and this time also with a MySQL talk on:
    • "Windowing Functions in MySQL" given by David Stokes, the MySQL Community Manager. His talk is scheduled for Oct 10 @3pm.
  • Come to talk to us!
• UbuCon Europe, Sintra, Portugal, October 10-13, 2019
  • MySQL team is supporting this Ubuntu conference as Silver sponsor. This time you can find us talking about: 
    • "Introduction to the new Oracle DBA: MySQL & Oracle." given by Keith Hollman, the MySQL Principal Sales Consultant.
    • "MySQL 8.0: Highly Available, JSON, NOSQL & Document Store Straight out-of-the-box" given by Keith Hollman. See schedule for more details about both Keith's talks.
    • Tiago Jorge talk approved: "MySQL 8.0: The New Replication Features" given by Tiago Jorge, the MySQL Software Architect. His talk is scheduled for Oct 12 @15:30 in Auditório Ubuntu.
• Zabbix Summit, Riga, Latvia, October 11-12, 2019
• All Things Open 2019, Raleigh, NC, October 13-15, 2019
• OpenSource Conference India (OSI Days), Bangalore, India, October 17-18, 2019
• MOPCON, Taipei, Taiwan, October 19-20, 2019
• PHP[World], WDC, US, October 23-24, 2019
• Forum PHP, Paris, France October 24-25, 2019

November 2019:

• Highload++, Moscow, RF (November 7-8, 2019)
• BGOUG, Pravets, Bulgaria (November 15-17, 2019)

[more details are coming soon]

MySQL has had an interesting optimization for years now¹, which has popped up from time to time: in certain circumstances, it may choose to use an index that is index-wise less efficient, but provides the resulting rows in order, to avoid a filesort of the result.

What does this typically look like in production? A query that seems simple and easy takes much longer than it should, sometimes. (Perhaps in production, the query gets killed by pt-kill or exceeds the max_execution_time provided.) The query could be very simple indeed:

SELECT ... WHERE `other_id` = 555 ORDER BY `id` ASC LIMIT 1

There’s an index on other_id, and running the query with an appropriate USE INDEX, the query is fast. Even weirder, changing the query to use LIMIT 10 causes it to run lightning-fast! If anything, the LIMIT 1 should be faster… so, what gives?

Looking at the EXPLAIN, you may notice that the LIMIT 1 version is using access type index on the PRIMARY key (in this case id), whereas the LIMIT 10 version is using ref on a secondary key. Access type index means a full-index scan… on the primary key… which is the clustered key… which is a full table scan.

The optimization is hoping that the LIMIT n with a small enough limit will allow execution to be completed early, without scanning many rows, once the LIMIT is satisfied. This hope is often misplaced: there is no guarantee that there will be any matching rows in the first m rows of the table when ordered by the unwisely-chosen index. Hope is not a strategy.

Although the underlying issue had been reported several times already, under various circumstances, since there were so many individual bugs reported, I filed a new bug with a summary of the situation… and a patch: MySQL Bug 97001.

On MySQL Bug 97001, I proposed a solution (and provided a patch, submitted to Oracle under the NDA) introducing a new optimizer_switch flag named reconsider_index_for_order (defaulting to on to duplicate the current behavior). Although this optimization might benefit some queries, it’s too dependent on the actual data in the involved tables, so it’s not a good candidate for a general optimizer feature in my opinion. Maybe the default could eventually be off allowing users to opt into this optimization when they want it but providing compatible default behavior.

¹ The underlying optimization actually appears to be have roots in some very old code, most importantly probably one specific commit in 5.1.

In MySQL and Oracle, you set a session variable quite differently. That means you should expect there differences between setting a session variable in Postgres. This blog post lets you see how to set them in all three databases. I’m always curious what people think but I’m willing to bet that MySQL is the simplest approach. Postgres is a bit more complex because you must use a function call, but Oracle is the most complex.

The difference between MySQL and Postgres is an “@” symbol versus a current_setting() function call. Oracle is more complex because it involves the mechanics in Oracle’s sqlplus shell, SQL dialect, and PL/SQL language (required to assign a value to a variable).

MySQL

MySQL lets you declare a session variable in one step and use it one way in a SQL statement or stored procedure.

Postgres

Postgres lets you declare a session variable in one step and use it one way in a SQL statement or stored procedure.

Oracle

There are two steps required to declare a session variable in Oracle. First, you need to define the variable in the SQL*Plus session. Oracle lets you define a variable like you would define a variable in the C language, using extern before the variable’s type. Second, you assign a value to the session variable in an anonymous PL/SQL block. There is no single line statement to declare a variable with an initial value.

EverData a leading data center and cloud solution provider in India has recently been writing quite a bit about Galera Cluster and it seems like we should highlight them. For one, they’ve talked about streaming replication in Galera Cluster 4, available in MariaDB Server 10.4. However, let us focus on their post: Galera Cluster vs Amazon RDS: A Comprehensive Review.

They compared MySQL with MHA, MySQL with Galera Cluster and also Amazon Web Services (AWS) Relational Database Service (RDS). Their evaluation criteria was to see how quickly there would be recovery after a crash, as well as performance while managing concurrent reads and writes.

In their tests, they found that time for failover with Galera Cluster between 8-10 seconds, whereas Aurora (so they were not using Amazon RDS?) took between 15-51 seconds, and MySQL with MHA took 140 seconds (which seems excessively high, considering this solution has been known to do sub-10 second failovers — so maybe needing some configuration tuning?)

In terms of performance, MySQL with MHA comes out the winner over Galera Cluster, but Galera Cluster comes out ahead of RDS (is this RDS MySQL or Aurora?). This can simply be explained that MySQL with MHA was likely configured with asynchronous replication and not semi-synchronous, and you’re only writing to one node as opposed to three nodes. (MHA setups recommend the use of semi-synchronous replication; also later on in the report, there is a note about replication lag).

Some takeaways in conclusion, straight from their report:

• “If HA and low failover time are the major factors, then MySQL with Galera is the right choice.”
• High Availability: “MySQL/Galera was more efficient and consistent, but the RDS didn’t justify the episodes of replication lags.”
• Performance: “MySQL/Galera outperformed the RDS in all tests — by the execution time, number of transactions, and rows managed.”

“we can see that MySQL/Galera manages the commit phase part more efficiently along with the replication and data validation.” Source: EverData

Looks extremely positive from a Galera Cluster standpoint, and we thank the team at EverData for such a report. It is interesting to read so take look Galera Cluster vs Amazon RDS: A Comprehensive Review.  

Just delivered a tutorial on MariaDB Server 10.4. Decided to take a closer look at the schedule for Percona Live Europe Amsterdam 2019 and one thing is clear: feels like there should also be a ProxySQL tutorial, largely because at mine, I noticed like 20% of the folk saying they use it.

Seems like there are 2 talks about it though, one about real world usage on Oct 1, and one about firewall usage with AWS, given by Marco Tusa on Oct 2.

Which led me to the ProxySQL Technology Day 2019 in Ghent, Belgium. October 3 2019. 2 hour train ride away from Amsterdam Schipol (the airport stop). It is easy to grab a ticket at Schipol Plaza, first class is about €20 more per way than second class, and a good spot to stay could be the Ibis Budget Dampoort (or the Marriott Ghent). Credit card payments accepted naturally, and I’m sure you can also do this online. Didn’t take me longer than five minutes to get all this settled.

So, the ProxySQL Technology Day is free, seems extremely focused and frankly is refreshing because you just learn about one thing! I feel like the MySQL world misses out on this tremendously as we lost the users conference… Interesting to see if this happens more in our ecosystem!

Overview

Clustering provides high availability and disaster recovery, along with the ability to read-scale both locally and globally. Some clusters even provide active/active capabilities, which others have a single master.

Real time database replication is a must for clustering and other key business purposes, like reporting. There are a number of replication technologies available for MySQL, and some are even bundled into various solutions. When choosing a replication methodology, it is paramount to understand just how the data moves from source to target. In this blog post, we will examine how asynchronous, synchronous, and “semi-synchronous” replication behave when used for clustering. Also, we will explore how replication affects database performance and data availability.

Asynchronous Replication

Asynchronous replication (async for short) is used by MySQL natively as well as by our own Tungsten Replicator. With async, all replication is decoupled from the database. Specifically, replication is a background process that reads events from the binary log on disk and makes those events available to the slaves upon request. There is no change to how the application works, and thus is quick and easy to implement. Also, async does not slow down the response from MySQL to the application.

With asynchronous replication, you have:

• The least impact to application performance of any replication type, because replication is handling database events separately in the background by reading the binary logs.
• The best (and really the only) choice for WAN replication because the application does not need to wait for confirmation from each slave before proceeding – this delay is prohibitive over long distances due to the simple physics of the speed of light creating delays in transit (Round-Trip-Time or RTT).
• The ability to deploy databases at geo-scale, serving applications that need high performance globally. Replication is de-coupled from your application, so slow WAN links do not imapct application performance.
• A chance of data lag on the replication slaves, which means that the slaves are not completely up-to-date with the master. In the event of a failure, there is a chance the newly-promoted slave would not have the same data as the master.
• The risk of data loss when promoting a slave to master per the above point. There are a number techniques to mitigate data loss which will be discussed in another blog post.

Synchronous Replication

Used by Galera and its variants, synchronous replication (sync for short) addresses the above data loss issues by guaranteeing that all transactions are committed on all nodes at database commit. Synchronous replication will wait until all nodes have the transaction committed before providing a response to the application, as opposed to asynchronous replication which occurs in the background after a commit to the master. With the sync method, you can be sure that if you commit a transaction, that transaction will be committed on every node.

With synchronous replication, you have:

• The most significant application lag of any type of replication, because your application must wait for all nodes in the cluster to commit the transaction too.
• Per above, it is complicated to implement over wide-area or slow networks, due to the almost prohibitive application lag, as it waits for transactions to be committed on remote databases.
• Transaction commit on all nodes, guaranteed.
• No slave data lag, as slaves are always up to date by definition.
• No chance of a data loss window in the event of a failover.
• Possibility to have multiple masters in a local cluster using a process called “certification”; certification will process transactions in order or, in the event of a conflict, raise an error.

Semi-Synchronous Replication

“Semi-Synchronous Replication,” used early on by Facebook and YouTube, attempts to merge the advantages of both asynchronous and semi-synchronous replication. With semi-synchronous replication (semi-sync for short), transactions are committed on the master, transferred to at least one slave node but NOT NECESSARILY committed. At this point, control is handed back to the application and commits to the slaves are handled in the background. Compared to synchronous replication, applications can potentially be more responsive since they receive control back sooner (though it is not as fast as async). Also, compared to async, there is less chance of data loss and potentially less replication lag.

With semi-synchronous replication, you have:

• Application response that is faster than synchronous replication, but slower than asynchronous replication
• The potential for a data loss window that is smaller than with asynchronous replication, but still larger than with synchronous replication.
• Configuration is more complex than with asynchronous replication, since it is not decoupled from the master database.
• A relatively new technology as compared to other replication methodologies. It remains to be seen if semi-sync will be a viable solution for production workloads.

Why does Tungsten Clustering choose Asynchronous Replication?

Tungsten Clustering uses the Tungsten Replicator, leveraging asynchronous replication, so that complex clusters can be deployed at geo scale without modifying or impacting applications or database servers. When deploying over wide area networks, asynchronous replication is the best and usually only option to protect application performance. Also, even over fast LAN’s, for write-intensive workloads, asynchronous replication is the best choice because the bottom-line impact to the application is minimized.

Look out for Part 2 of this blog, that will dive into how different replication technologies impact cluster behavior in day-to-day operations (such as failover, local and global replication breaks, zero downtime, maintenance updates, etc.).

For more information about Tungsten clusters, please visit https://docs.continuent.com

If you would like to speak with one of our team, please feel free to reach out here: https://www.continuent.com/contact

SQL Left Function Example | LEFT() In SQL Server And MySQL is today’s topic. LEFT FUNCTION in SQL is used for extracting a substring starting from the left, followed by the number of characters. The LEFT() function extracts several characters from the string (starting from left).

SQL Left Function

The LEFT() function extracts a given number of characters from the left side of a supplied string.

The syntax of the LEFT() function is as follows.

SELECT LEFT (string, no_of_characters);

See the following parameters.

PARAMETERS:

1. String: An input string from which the substring will be extracted and can be a literal string, variable or a column.
2. No_of_characters: Number of characters you wish to extract from the string.

The LEFT() function returns a value of VARCHAR when the input_string is non-Unicode character data type and returns an NVARCHAR if the input_string is a Unicode character data type.

Example of SQL LEFT()

Query 1

SELECT LEFT ('AppDividend.com', 11);

Output

AppDividend

Here 11 characters were displayed starting from the left-most part of the string.

Query 2

SELECT LEFT ('AppDividend.com', 3);

Output

App

Here 3 characters were displayed starting from the left-most part of the string.

Query 3

SELECT LEFT ('SQL IS FUN', 4);

Output

'SQL '

Here 4 characters were displayed starting from the left-most part of the string. After SQL there is whitespace which is also counted as a character.

Query 4

SELECT LEFT ('SQL IS FUN', 20);

Output

SQL IS FUN

Here the number of characters exceeded the length of the string as a whole result string is displayed as an output.

Let’s apply the LEFT function in a Table.

Table: Employee

Now if we want to display the first 7 digits of the phone, then the following query has to be written:

Query 5

Select First_name AS Emp_Name, LEFT (Phone, 7) AS First_seven_digit 
from Employee;

Output

So, you can see that the first seven-digit of phone number is displayed under the column named Phone.

If the number_of_characters exceeds the length of the string, the LEFT function will return string.

MySQL LEFT() Function

MySQL LEFT() function extracts a number of characters from a string (starting from left).

Query

SELECT LEFT("MySQL Tutorial", 3) AS ExtractString;

Output

SQL Server LEFT() Function

The following statement uses LEFT() to return the three leftmost characters of the character string.

SELECT LEFT('Millie Bobby Brown', 6) Output_string;

Output

Output_string
-------------
Millie
 
(1 row affected)

Finally, SQL Left Function Example | LEFT() In SQL Server And MySQL is over.

Recommended Posts

Understanding Difference Method in SQL

SQL CONCAT_WS Function Example

SQL CHARINDEX Function Example

SQL Char Function Example

SQL ASCII FUNCTION Example

The post SQL Left Function Example | LEFT() In SQL Server And MySQL appeared first on AppDividend.

Lower() Function Example In MySQL and SQL Server is today’s topic. The SQL LOWER function converts all the characters in a string into lowercase. If you want to convert all characters in a string into uppercase, you should use the UPPER function. SQL LOWER function is used for lowering the case of a string, i.e. all the characters in the specified string will be converted to lower case. This is one of the String functions.

SQL LOWER Function

See the following syntax.

SELECT LOWER (input_string)

PARAMETERS:

Input_string: It is the string whose characters are to be converted to lowercase. The input string can be any string or any table column.

NOTE:

If any number is given as an input, then it will remain unaffected.

Examples of LOWER() Function

Query 1

SELECT LOWER ('APPDIVIDEND.COM');

Output

appdividend.com

Query 2

SELECT LOWER ('AppDividend.com');

Output

appdividend.com

Query 3

SELECT LOWER ('SQL is FuN');

Output

sql is fun

Query 4

SELECT LOWER (‘ABC123DEF’);

Output

abc123def

As mentioned above, numerals are unaffected by the lower function.

Above were common examples to make you clear how this function works.

Let’s apply this to a table.

TABLE: (Employee)

Let’s display the full name of the employee by converting all its characters to lowercase.

QUERY

SELECT First_name, Last_name, CONCAT_WS (' ', LOWER (First_name), LOWER (Last_name)) Full_name 
FROM Employee;

Output

Here you can see that full_name is displayed under the column name Full_name whose characters are in lowercase.

The names are separated by a space using concat_ws function.

MySQL LOWER() Function

MySQL LOWER() converts all the characters in a string to lowercase characters.

Query

SELECT LOWER('APPDIVIDEND');

Output

+-----------------------+
| LOWER('MYTESTSTRING') |
+-----------------------+
| appdividend           | 
+-----------------------+

SQL Server LOWER() Function

The SQL LOWER() function converts all the characters in a string into lowercase.

Query

SELECT LOWER('KRUNAL LATHIYA');

Output

krunal lathiya
(1 row)

Finally, SQL LOWER Function | Lower() Function In MySQL and SQL Server Tutorial is over.

Recommended Posts

SQL AND OR NOT Operator Example Tutorial

NULL Functions in SQL Tutorial

Implement Error Handling in SQL

String Functions In SQL

Check Constraint In SQL

The post SQL LOWER Function | Lower() Function In MySQL and SQL Server appeared first on AppDividend.

Percona is happy to announce the first experimental binary of Percona XtraDB Cluster 8.0 on October 1, 2019. This is a major step for tuning Percona XtraDB Cluster to be more cloud- and user-friendly. This release combines the updated and feature-rich Galera 4, with substantial improvements made by our development team.

Improvements and New Features

Galera 4, included in Percona XtraDB Cluster 8.0, has many new features. Here is a list of the most essential improvements:

Installation

You can only install this release from a tarball and it, therefore, cannot be installed through a package management system, such as apt or yum. Note that this release is not ready for use in any production environment.

Percona XtraDB Cluster 8.0 is based on the following:

• Percona Server for MySQL 8.0.15-5
• Codership WSREP API release 27
• Codership Galera library 4.2

Please be aware that this release will not be supported in the future, and as such, neither the upgrade to this release nor the downgrade from higher versions is supported.

This release is also packaged with Percona XtraBackup 8.0.5. All Percona software is open-source and free.

In order to experiment with Percona XtraDB Cluster 8.0 in your environment, download and unpack the tarball for your platform.

Note

Be sure to check your system and make sure that the packages are installed which Percona XtraDB Cluster 8.0 depends on.

For Debian or Ubuntu:

$ sudo apt-get install -y \
socat libdbd-mysql-perl \
rsync libaio1 libc6 libcurl3 libev4 libgcc1 libgcrypt20 \
libgpg-error0 libssl1.1 libstdc++6 zlib1g libatomic1

For Red Hat Enterprise Linux or CentOS:

$ sudo yum install -y openssl socat  \
procps-ng chkconfig procps-ng coreutils shadow-utils \
grep libaio libev libcurl perl-DBD-MySQL perl-Digest-MD5 \
libgcc rsync libstdc++ libgcrypt libgpg-error zlib glibc openssl-libs

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!

At Shopify, we run a large fleet of MySQL servers, with numerous replica-sets (internally known as “shards”) spread across three Google Cloud Platform (GCP) regions. Given the petabyte scale size and criticality of data, we need a robust and efficient backup and restore solution. We drastically reduced our Recovery Time Objective (RTO) to under 30 minutes by redesigning our tooling to use disk-based snapshots, and we want to share how it was done.

Challenges with Existing Tools

For several years, we backed up our MySQL data using Percona’s Xtrabackup utility, stored its output in files, and archived them on Google Cloud Storage (GCS). While pretty robust, it provided a significant challenge when backing up and restoring data. The amount of time taken to back up a petabyte of data spread across multiple regions was too long, and increasingly hard to improve. We perform backups in all availability regions to decrease the time it takes to restore data cross-region. However, the restore times for each of our shards was more than six hours, which forced us to accept a very high RTO.

While this lengthy restore time was painful when using backups for disaster recovery, we also leverage backups for day-to-day tasks, such as re-building replicas. Long restore times also impaired our ability to scale replicas up and down in a cluster for purposes like scaling our reads to replicas.

Overcoming Challenges

Since we run our MySQL servers on GCP’s Compute Engine VMs using Persistent Disk (PD) volumes for storage, we invested time in leveraging PD’s snapshot feature. Using snapshots was simple enough, conceptually. In terms of storage, each initial snapshot of a PD volume is a full copy of the data, whereas the subsequent ones are automatically incremental, storing only data that has changed.

In our benchmarks, an initial snapshot of a multi-terabyte PD volume took around 20 minutes and each incremental snapshot typically took less than 10 minutes. The incremental nature of PD snapshots allows us to snapshot disks very frequently, helps us with having the latest copy of data, and minimizes our Mean Time To Recovery.

Modernizing our Backup Infrastructure

Taking a Backup

We built our new backup tooling around the GCP API to invoke PD snapshots. This tooling takes into account the availability regions and zones, the role of MySQL instance (replica or master) and the other MySQL consistency variables. We deployed this tooling in our Kubernetes infrastructure as CronJobs, giving the jobs a distributed nature and avoiding tying them to our individual MySQL VMs allowing us to avoid having to handle coordination in case of a host failure. The CronJob is scheduled to run every 15 minutes across all the clusters in all of our available regions, helping us avoid costs related to snapshot transfer across different regions.

Backup workflow selecting replica and calling disk API to snapshot, per cron schedule

The backup tooling creates snapshots of our MySQL instances nearly 100 times a day across all of our shards, totaling thousands of snapshots every day with virtually no failures.

Since we snapshot so frequently, it can easily cost thousands of dollars every day for snapshot storage if the snapshots aren’t deleted correctly. To ensure we only keep (and pay for) what we actually need, we built a framework to establish a retention policy that meets our Disaster Recovery needs. The tooling enforcing our retention policy is deployed and managed using Kubernetes, similar to the snapshot CronJobs. We create thousands of snapshots every day, but we also delete thousands of them, keeping only the latest two snapshots for each shard, and dailies, weeklies, etc. in each region per our retention policy

Backup retention workflow, listing and deleting snapshots outside of retention policy

Performing a Restore

Having a very recent snapshot always at the ready provides us with the benefit of being able to use these snapshots to clone replicas with the most recent data possible. Given the small amount of time it takes to restore snapshots by exporting a snapshot to a new PD volume, this has brought down our RTO to typically less than 30 minutes, including recovery from replication lag.

Backup restore workflow, selecting a latest snapshot and exporting to disk and attaching to a VM

Additionally, restoring a backup is now quite simple: The process involves creating new PDs with source as the latest snapshot to restore and starting MySQL on top of that disk. Since our snapshots are taken while MySQL is online, after restore it must go through MySQL InnoDB instance recovery, and within a few minutes the instance is ready to serve production queries.

Assuring Data Integrity and Reliability

While PD snapshot-based backups are obviously fast and efficient, we needed to ensure that they are reliable, as well. We run a backup verification process for all of the daily backups that we retain. This means verifying two daily snapshots per shard, per region.

In our backup verification tooling, we export each retained snapshot to a PD volume, attached to Kubernetes Jobs and verify the following:

• if a MySQL instance can be started using the backup
• if replication can be started using MySQL Global Transaction ID (GTID) auto-positioning with that backup
• if there is any InnoDB page-level corruption within the backup

Backup verification process, selecting daily snapshot, exporting to disk and spinning up a Kubernetes job to run verification steps

This verification process restores and verifies more than a petabyte of data every day utilizing fewer resources than expected.

PD snapshots are fast and efficient, but the snapshots created exist only inside of GCP and can only be exported to new PD volumes. To ensure data availability in case of catastrophe, we needed to store backups at an offsite location. We created tooling which backs up the data contained in snapshots to an offsite location. The tooling exports the selected snapshot to new PD volume and runs Kubernetes Jobs to compress, encrypt and archive the data, before transferring them as files to an offsite location operated by another provider.

Evaluating the Pros and Cons of Our New Backup and Restore Solution

Pros

• Using PD snapshots allows for faster backups compared to traditional file-based backup methods.
• Backups taken using PD snapshots are faster to restore, as they can leverage vast computing resources available to GCP.
• The incremental nature of snapshots results in reduced backup times, making it possible to take backups more frequently.
• The performance impact on the donors of snapshots is noticeably lower than the performance impact of the donors of xtrabackup based backups.

Cons

• Using PD snapshots is more expensive for storage compared to traditional file based backups stored in GCS.

• The snapshot process itself doesn’t perform any integrity checks, for example, scanning for InnoDB page corruption, ensuring data consistency, etc. which means additional tools may need to be built.

• Because snapshots are not inherently stored as a conveniently packaged backup, it is more tedious to copy, store, or send them off-site.

We undertook this project at the start of 2019 and, within a few months, we had a very robust backup infrastructure built around Google Cloud’s Persistent disk snapshot API. This tooling has been serving us well and has introduced us to new possibilities like, scaling replicas up and down for reads quickly using these snapshots apart from Disaster recovery.

MySQL to ClickHouse Replication 

MySQL works great for Online Transaction Processing (OLTP) systems, MySQL performance degrades with analytical queries on very large database infrastructure, I agree you can optimize MySQL query performance with InnoDB compressions but why then combine OLTP and OLAP (Online Analytics Processing Systems) when you have columnar stores which can deliver high performance analytical queries more efficiently? I have seen several companies building dedicated MySQL servers for Analytics but over the period of time they end spending more money in fine tuning MySQL for Analytics with no significant improvements, There is no point in blaming MySQL for what it is not built for, MySQL / MariaDB is any day a bad choice for columnar analytics / big data solutions.  Columnar database systems are best suited for handling large quantities of data: data stored in columns typically is easier to compress, it is also easier to access on per column basis – typically you ask for some data stored in a couple of columns – an ability to retrieve just those columns instead of reading all of the rows and filter out unneeded data makes the data accessed faster. So how can you combine the best of both ? Using MySQL purely for Transaction Processing Systems and Archiving MySQL Transactional Data for Data Analytics on a columnar store like ClickHouse, This post is about archiving and replicating data from MySQL to ClickHouse, you can continue reading from here.

Recommended Reading for ClickHouse: 

• Why we recommend ClickHouse over many other columnar database systems ? https://minervadb.com/index.php/2018/03/06/why-we-recommend-clickhouse-over-many-other-columnar-database-systems/ 
• Benchmarking ClickHouse on my MacBook Pro (Super impressive performance) – https://minervadb.com/index.php/2018/01/23/benchmarking-clickhouse-2/
• ClickHouse GitHub – https://github.com/ClickHouse 
• Altinity GitHub – https://github.com/Altinity
• What you should know about RAID to improve Database Systems Performance – https://minervadb.com/index.php/2019/08/04/raid-redundant-storage-for-database-reliability/

The post Database Replication from MySQL to ClickHouse for High Performance WebScale Analytics appeared first on MySQL Consulting, Support and Remote DBA Services.

SQL LTRIM Function Example is today’s topic. SQL LTRIM function is used for removing all the leading whitespaces or specified characters from the string, i.e. from the left-hand side of the string. In this tutorial, you will learn how to use a MySQL and SQL Server LTRIM() function to remove leading blanks from a string. Oracle/PLSQL LTRIM function removes all specified characters from the left-hand side of a string.

SQL LTRIM Function

The LTRIM() function returns the string after removing leading blanks.

The following shows the syntax of the LTRIM() function.

SELECT LTRIM (input_string, [trim_string])

PARAMETERS

Input_string: It is the string from where the characters have to be removed from the left-hand side.

Trim_string: It is completely optional. It is mainly used for specifying the characters to be removed. If this parameter is omitted, then all the leading spaces will be removed.

Examples of trim() function in SQL

Query 1

SELECT LTRIM (‘    SQL’);

Output

SQL

Here all the leading spaces are removed from the string.

Query 2

SELECT LTRIM (‘000123’, ‘0’);

Output

123

As Trim_string was specified as 0. So, all leading 0 were removed from the string.

Query 3

SELECT LTRIM (‘00012300’, ‘0’);

Output

12300

As Trim_string was specified as 0. So, all leading 0 were removed from the string but not the trailing zeroes because the function used here was LTRIM which removes only the leading zeroes.

Query 4

SELECT LTRIM (‘2145AppDividend’, ‘012345’);

Output

AppDividend

In the above example, all combinations of 0 to 5 are listed. By doing this, all the order of the leading numbers from the string will be removed.

Query 5

SELECT LTRIM (‘aabbabcSQLabc’, ‘abc’);

Output

SQLabc

In the above example, ‘abc’ is declared as Trim_string. So, ‘a,’ ‘b,’ ‘c’ is considered as an individual character. So, all leading characters of ‘abc’ are removed from the string.

Above were the common examples to make you clear how the LTRIM function works.

Let’s apply this function to a table.

Table: Employee

Previously, in the employee table, ‘#’ was added before the emp_id. Now we want to remove this character from the emp_id and display only the number. So, to do this following query has to be written.

Query

Select LTRIM (Emp_id, ‘#’) AS Emp_id, Emp_name, City, State, Salary 
from Employee;

Output

Here, you can see that the new table is created by removing leading ‘#’ unique character from the Emp_id.

LTRIM() Function in SQL Server

See the following example in SQL Server.

Query

SELECT  LTRIM('   AppDividend Uses Cloud Hosting') result;

Output

result
----------------------------
SQL Server LTRIM Function
 
(1 row affected)

LTRIM() Function in MySQL

The function works onwards from  MySQL 4.0. See the example in MySQL.

Query

SELECT LTRIM("     MySQL LTRIM() Tutorial") AS LeftTrimmedString;

Output

MySQL LTRIM() Tutorial

Finally, SQL LTRIM Function Example | LTRIM In MySQL And SQL Server is over.

Recommended Posts

Lower() Function Example In MySQL and SQL Server

SQL BETWEEN AND IN OPERATOR Tutorial

SQL Triggers Tutorial With Example

SQL Wildcard Operators Tutorial

SQL Distinct Keyword Tutorial

SQL Aggregate Functions Example

The post SQL LTRIM Function Example | LTRIM In MySQL And SQL Server appeared first on AppDividend.

Percona Live Europe Amsterdam Day 1 was a bunch of fun, especially since I didn’t have to give a talk or anything since my tutorial was over on Day 0.

At lunch, I realised that there are a lot more fringe events happening around Percona Live… and if you’ve seen how people do “tech weeks”, maybe this is what the event ends up being – a show, plus plenty of focused satellite events. FOSDEM in the open source world totally gets this, and best of all, also lists fringe events (see example from 2019).

So, Thursday evening gets a few fringe events, a relatively short train ride away:

• ClickHouse Paris Meetup 2019
• ProxySQL Technology Day Ghent

Anyway, what was Day 1 like? Keynotes started the morning, and I did make a Twitter thread. It is clear that there is a lot of talk amongst companies that make open source software, and companies in the ecosystem that somehow also derive great value from it. Some look at this as the great cloud vendors vs open source software vendors debate, but this isn’t necessarily always the case – we’ve seen this as Percona’s model too. And we’ve seen cloud companies contribute back (again, just like Percona). Guess this is a topic for a different post, because there are always two sides to this situation…

It is also clear that people want permissive open source licenses over anything source available. If you’re a CxO looking for software, it would be almost irresponsible to be using critical software that is just source available with a proprietary license. After all, what happens when the company decides to ask for more money? (Companies change ownership too, you know).

It is probably clear the best strategies are the “multi” (or hybrid) strategies. Multiple databases, multiple clouds, and going all in on open source to avoid vendor lock-in. Of course, don’t forget that open source software also can have “vendor lock-in” – always look at the health metrics of a project, vs. a product. We’re lucky in the MySQL ecosystem that we have not just the excellent work of Oracle, but also MariaDB Corporation / MariaDB Foundation and also Percona.

MySQL 8.0 adoption is taking off, with about 26% of the users on it. Those on MySQL 5.6 still seem to be on it, and there has been a decrease in 5.7 use to grow that 8.0 pie. It isn’t clear how these stats are generated (since there is no “phone home” functionality in MySQL; also the MariaDB Server variant doesn’t get as much usage as one would like), but maybe it is via download numbers?

Anyone paying any attention to MySQL 8 will know that they have switched to a “continuous delivery model”, also known as, you get new features in every point release. So the latest 8.0.18 gets EXPLAIN ANALYZE, and while we can’t try it yet (not released, and the documentation isn’t updated), I expect it will be fairly soon. I am eager to try this, because MariaDB Server has had ANALYZE since 10.1 (GA – Oct 2015). And it wasn’t long ago that MySQL received CHECK constraints support (8.0.16). Also the CLONE plugin in 8.0.17 warrants some checking/usage!

Besides all the hallway chats and meetings I did manage to get into a few sessions… Rakuten Intelligence talked about their usage of ProxySQL, and one thing was interesting with regard to their future plans slide – they do consider group replication but they wonder what would replace their custom HA software? But most importantly they wonder if it is stable and which companies have successfully deployed it, because they don’t want to be the first. Question from the floor about Galera Cluster came up, and they said they had one app that required XA support – looks like something to consider once Galera 4 is fully baked!

The PXC–8 talk was also chock full of information, delivered excellently, and something to try soon (it wasn’t quite available yesterday, but today I see a release announcement: Experimental Binary of Percona XtraDB Cluster 8.0).

I enjoyed the OpenCorporates use case at the end too. From the fact that for them, being on-premise would be cheaper than the cloud, how they use ProxySQL, Galera Cluster branch Percona XtraDB Cluster (PXC), and ZFS. ZFS is not the most common filesystem for MySQL deployments, so it was interesting to see what could be achieved.

Then there was the Booking.com party and boy, did they outdo themselves. We had a menu, multi-course meal with wine pairings, and a lot of good conversation. A night wouldn’t be complete without some Salmiakkikossu, and Monty sent some over for us to enjoy.

Food at the Hilton has been great too (something I would never really want to say, considering I’m not a fan of the hotel chain) – even the coffee breaks are well catered for. I think maybe this has been the best Percona Live in terms of catering, and I’ve been to a lot of them (maybe all…). I have to give much kudos to Bronwyn and Lorraine at Percona for the impeccable organisation. The WiFi works a charm as well. On towards Day 2!