MySQL Cluster 8.0.18 RC2 was released a few weeks back packed
with a set of
new interesting things.
One major change we have done is to increase the number of data
nodes from 48 to
144. There is also ongoing work to fully support 3 and 4 replicas
in MySQL
Cluster 8.0. NDB has actually always been designed to handle up
to 4 replicas.
But the test focus have previously been completely focused on 2
replicas. Now we
expanded our test focus to also verify that 3 and 4 replicas work
well. This means
that with NDB 8.0 we will be able to confidently support 3 and 4
replicas.
This means that with NDB 8.0 it will be possible to have 48
node
groups with 3 replicas in each node group in one cluster.
The higher number of nodes in a cluster gives the possibility to
store even more
data in the cluster. So with 48 node groups it is possible to
store 48 TByte of
…
To illustrate how easy it’s to see who’s trying to access data they have not been granted for, we will first create a schema with two tables:
mysql> create database mydata;
mysql> use mydata
mysql> create table table1 (id int auto_increment primary key,
name varchar(20), something varchar(20));
mysql> create table table2 (id int auto_increment primary key,
name varchar(20), something varchar(20));
Now, let’s create a user :
mysql> create user myuser identified by 'mypassword';
And as it’s always good to talk about SQL ROLES, let’s define 3 roles for our user:
- myrole1: user has access to both tables in their entirety, reads and writes
- myrole2: user has access only to `table2`, reads and writes
- myrole3: user has only access to the column `name`of `table1` and …
MySQL InnoDB Cluster consists of 3 components:
- MySQL Group Replication (a group of database server which replicates to each other with fault tolerance).
- MySQL Router (query router to the healthy database nodes)
- MySQL Shell (helper, client, configuration tool)
In the first part of this walkthrough, we are going to deploy a MySQL InnoDB Cluster. There are a number of hands-on tutorial available online but this walkthrough covers all the necessary steps/commands to install and run the cluster in one place. We will be covering monitoring, management and scaling operations as well as some gotchas when dealing with MySQL InnoDB Cluster in the second part of this blog post.
The following diagram illustrates our post-deployment architecture:
We are going to deploy a total of 4 nodes; A three-node MySQL Group Replication and one MySQL router node co-located within the application …
[Read more]In my previous blog, I have explained how the MySQL clone plugin works internally. In this blog, I am going to do a comparison of Backup and Recovery speed of MySQL clone plugin with other available mysql open source backup tools.
Below tools are used for speed comparison of Backup and Recovery,
- Clone-Plugin
- Xtrabackup
- mysqldump
- mydumper with myloader
- mysqlpump
Test …
[Read more]For a long time, the only algorithm for executing a join in MySQL has been variations of the nested loop algorithm. With the release of MySQL 8.0.18, the server can now execute joins using hash join. This blog post will have a look at how it works, when it is used, and how it compares to the old join algorithms in MySQL in terms of performance.…
Facebook Twitter LinkedIn
Recently, at Percona Live Europe 2019, Dimitri Kravchuk from Oracle mentioned that he observed some unclear drop in performance for MySQL on an ext4 filesystem with the latest Linux kernels. I decided to check this case out on my side and found out that indeed, starting from linux kernel 4.9, there are some cases with notable (up to 2x) performance drops for ext4 filesystem in direct i/o mode.
So what’s wrong with ext4? It started in 2016 from the patch that was pushed to kernel 4.9: “ext4: Allow parallel DIO reads”. The purpose of that patch was to help to improve read scalability in direct i/o mode. However, along with improvements in pure read workloads, it also introduced regression in intense mixed random read/write scenarios. And it’s quite weird, but this issue had not been …
[Read more]Discover the new Continuent Tungsten Replicator (AMI) – the most advanced & flexible replication engine for MySQL, MariaDB & Percona Server, including Amazon RDS MySQL and Amazon Aurora
We’re excited to announce the availability on the Amazon Marketplace of a new version of the Tungsten Replicator (AMI).
Tungsten Replicator (AMI) is a replication engine that provides high-performance and improved replication functionality over the native MySQL replication solution and provides the ability to apply real-time MySQL data feeds into a range of analytics and big data databases.
Tungsten Replicator (AMI) builds upon …
[Read more]MySQL Cluster is an open-source distributed in-memory database. It combines linear scalability with high availability, providing in-memory real-time access with transactional consistency across partitioned and distributed datasets. It was developed to support scenarios requiring high-availability (99.999% or more) and predictable query time. Testing such a system is achieved via many interconnected pieces ranging from a large set of automated tests and manual exploratory testing. This post explores an overview of the testing methodologies we use and the current challenges we face.
Gaming, banking, telcos, and online services all are powered by fully-redundant and fault-tolerant software systems. At the heart of those systems, you can find MySQL Cluster — a distributed in-memory database having a minimum of five-9s availability (around 5 minutes a year). This open-source database provides nearly-linear …
[Read more]dbForge Fusion is a line of Visual Studio plugins designed to simplify database development and enhance data management capabilities. This line comprises three tools: dbForge Fusion for SQL Server, dbForge Fusion for MySQL, and dbForge Fusion for Oracle. We are happy to announce new updates for each of these tools which come with many improvements […]
The post New dbForge Fusion tools with Visual Studio 2019 Support appeared first on blog.
A user defined table and its corresponding index data, in InnoDB, is stored in files that have an extension .ibd. There are two types of tablespaces, general (or shared) tablespace and file-per-table. For shared tablespaces, data from many different tables and their corresponding indexes may reside in a single .ibd…
Facebook Twitter LinkedIn