MySQL HeatWave on AWS is now available in AWS Europe London and Frankfurt regions

In the world of modern web applications, it is increasingly important to support a diverse range of languages and character sets. With the rise of globalization, the need to store and process multilingual data has become essential. MySQL, one of the most popular relational database management systems, recognizes this need and has introduced utf8mb4 in its 8.0 version as a game-changer. In this blog post, we will explore utf8mb4 and its advantages in MySQL 8.0, backed by practical examples.

Understanding utf8mb4

Before diving into the benefits, let’s clarify what utf8mb4 represents. In MySQL, “utf8” refers to a character encoding that supports the Unicode character set using a maximum of three bytes per character. However, the original utf8 implementation in MySQL does not cover all Unicode characters. utf8mb4, on the other hand, is a modified version of utf8 that supports the complete Unicode character set, including emojis …

Using MySQL Autopilot to improve price performance for OLTP workloads

Here, we will explore the ins and outs of MySQL DATEDIFF and its practical applications. We will look deeply into its syntax and provide you with real-world examples to showcase how DATEDIFF can be utilized in different scenarios, such as calculating age, tracking project durations, and more.

The post MySQL DATEDIFF: Function Explanation with Examples appeared first on Devart Blog.

Welcome to the 86th installment of the OpenLampTech developer newsletter. The authors whose content I share sure do make my job easy (and enjoyable). Thank you for reading.

Custom WooCommerce and Shopify Solutions

Discover useful WooCommerce and Shopify custom solutions for your online store today at affordable prices!

Learn More

The Newsletter for PHP and MySQL Developers

Receive a copy of my ebook, “10 MySQL Tips For Everyone”, absolutely free when you subscribe to the OpenLampTech newsletter.

In OpenLampTech issue #86, we have some fantastic articles on:

• A new …

JAPAC conferences with MySQL, July 2023

On the Internet, you can get a lot of advice from almost anywhere when you’re looking for information on how to do your DBA job.

My blog is one of these sources of advice, and depending on the source, we generally trust the advice more or less.

But sometimes advice doesn’t take the whole picture into account, and even if it comes from a recognized authority, it can lead to more or less serious problems.

Let’s consider the following situation:

We have an InnoDB ReplicaSet with 1 replication source (primary) and 2 replicas:

 JS > rs.status()
{
    "replicaSet": {
        "name": "myReplicaSet", 
        "primary": "127.0.0.1:3310", 
        "status": "AVAILABLE", 
        "statusText": "All instances available.", 
        "topology": {
            "127.0.0.1:3310": {
                "address": "127.0.0.1:3310", 
                "instanceRole": "PRIMARY", 
                "mode": "R/W", …

To continue our journey to Moodle on Oracle Cloud Infrastructure using Ampere compute instances and MySQL HeatWave Database Service [1] [2], in this article we will see how to scale our architecture using multiple Moodle instances, High Availability for the Database and Read Scale-Out.

This is the architecture we will deploy:

The same principles can be applied to other projects, not just Moodle.

Multiple Compute Instances & MySQL HeatWave High Availability

The first step is to use again the Stack to deploy the initial resources. We must insure that we use a MySQL Shape that has at least 4 OCPUs to …

In this final article on deploying Moodle to OCI with MySQL HeatWave, we are exploring a more complex architecture ensuring high availability and performance.

There is a really nice article by Pep Pla, over at the Percona blog

about fragmentation in MySQL InnoDB tablespaces, which you should read.

The article discusses “fragmentation” of data in tables, which happens in a way similar to how it happens in filesystems.

InnoDB stores data by default in tablespaces, which by default are a file per table. These files are subject to the fragmentation and growth rules of your filesystem, but if you are smart, you are running MySQL on Linux on the XFS. In that case, filesystem fragmentation (and unexplained commit latency variance) are not an issue, because XFS takes care of handling this properly, and only database-internal fragmentation remains.

…