So, as you’ve noticed, I’ve been playing around with MySQL Router v8.4.3 and read-write splitting, and now I’ve come across some issues that my environment has generated and I’ve opened some bugs against the fiend:

Bug 116950 – Router Read-Write splitting config causes PHP RSET_HEADER error

Bug 116951 – mysqlrouter Error parsing stats_updates_frequency errors

Bug 116952 – Router w/ RW split causes ERROR: 4501 if sql script contains comments lines (“– “)

(Yup, I prepared each bug description, repeatable tasks and suggested fix …

This tutorial explores HeatWave GenAI, a cloud service that simplifies interacting with unstructured data using natural language. It combines large language models, vector stores, and SQL queries to enable tasks like content generation, chatbot, and retrieval-augmented generation (RAG). The focus is on RAG and how HeatWave GenAI’s architecture helps users gain insights from their data.

The post Simplifying AI Development: A Practical Guide to HeatWave GenAI’s RAG & Vector Store Features first appeared on dasini.net - Diary of a MySQL expert.

MySQL HeatWave, an Oracle Cloud service, delivers high-performance query processing, efficiently manages large data volumes, and combines transactional and analytical processing within the same system. This article highlights its key features and benefits.

The post MySQL HeatWave: Real-Time Analytics and High-Performance Data Processing appeared first on Devart Blog.

I’m just trying out the v8.4 Read-Write configuration for MySQL Router, that comes default in the community edition and, as they say, TL;DR “it’s default upon bootstrap”.

What does this mean and how can I go about it?

The overview is simple:

• Either install or upgrade your existing MySQL Router to v8.4 at least.
• Bootstrap the Router.
• Use the port 3310 or change it to fit your needs.

Let’s get to it:

Stop your running router:

systemctl stop mysqlrouter

Copy the old config, just in case:

cp /etc/mysqlrouter/mysqlrouter.conf /etc/mysqlrouter/mysqlrouter_v80.conf

I normally keep my mysql linux repository disabled so no “yum update” takes over version control and gives me a nasty surprise afterwards. As so, I uncomment the “mysql” entry:

vi /etc/yum.conf …

TL;DR ALTER TABLE and OPTIMIZE TABLE on an InnoDB table, which rebuilds the table without blocking concurrent changes to it (i.e., executed using INPLACE algorithm) and concurrent DML or purge activity on the table can occasionally lead to two significant problems: ALTER/OPTIMIZE TABLE failing with an unnecessary duplicate key error (even though there are no […]

MySQL 8.4 and newer have extended the Global Transaction ID (GTID) functionality with a new “tag” option.

Refresher on GTID

A GTID is a unique ID that is assigned to a transaction. This is used if gtid_mode is set to ON. The benefit of this is that a transaction can be uniquely identified in a MySQL replication setup with multiple levels. Among others this makes it easier to refactor a replication tree as a MySQL replica knows which transactions it has seen and can use this to find the right position to start replicating from a new source.

The format of GTIDs is documented here.

Before GTID was used replication worked based on a file and offset (e.g. file=binlog.000001,offset=4), which is unique to every server.

A GTID without tag looks like …

Last month we released MySQL 9.1, the latest Innovation Release. Of course, we released bug fixes for 8.0 and 8.4 LTS but in this post, I focus on the newest release. Within these releases, we included patches and code received by our amazing Community. Here is the list of contributions we processed and included in […]

With multi-threaded replication (MTR), a replica can commit transactions in the same order as the source, or not. This is determined by sysvar replica_preserve_commit_order (RPCO). As of MySQL v8.0.27 (released October 2021) it’s ON by default, but it was OFF by default for several years prior. In either case, it’s relatively new compared to 20+ years of single-threaded replication for which commit order was not an issue or option. But with MTR, it’s important to understand the affects of RPCO, especially with respect to the focus of this three-part series: replication lag.

I recently became aware of WeSQL. A MySQL-compatible database that separates compute and storage, using S3 as the storage layer. The product uses a columnar format by default which is significantly more space-efficient than InnoDB.

WeSQL introduces a new storage engine called SmartEngine using a LSM-tree-based structure that is ideal for a storage bucket implementation, and documentation shows the implementation of raft replication to combat latency concerns. There is a lot more information to review, the serverless architecture and WeScale, a database proxy and resource manager.

It was very easy to take it for an initial spin using a docker container and an AWS S3 bucket. I would really like to try CloudFlare R2 which implements the S3 API.

Under the covers there …

After installing & configuring Dolphie, let’s take a look into how we can “re-record not fadeaway” and avoid using a VHS tape.

One of the coolest features is being able to go back in time with Dolphie and analyze what was happening at a specific moment.

This feature requires recording so we can replay.

Setting Dolphie up for recording mode.

I’m really just going to share the links to the the github site and organize my steps so someone else might want to rinse’n’repeat or “replay”. I’m just a mere messenger.

It works via the Daemon mode. …