At some points, many of our customers need to handle insertions of large data sets and run into slow insert statements. This article will try to give some guidance on how to speed up slow INSERT SQL queries.

The following recommendations may help optimize your data loading operations:

1. Remove existing indexes - Inserting data to a MySQL table will slow down once you add more and more indexes. Therefore, if you're loading data to a new table, it's best to load it to a table without any indexes, and only then create the indexes, once the data was loaded.

   When you're inserting records, the database needs to update the indexes on every insert, which is costly in terms of performance. It's much faster to insert all records without indexing them, and then create the indexes once for the entire table.

…

Another common question I receive about MySQL Shell Dump & Load Utility is how to dump a schema and load it with another name. Make a copy in fact.

Dumping the Schema

To do so, we need to use the dumpTables() method:

JS  util.dumpTables("test", [], "/tmp/dump", {all: true})

It is important to notice that the second parameter is an empty array and the option “all” is enabled.

This will dump all tables of the test schena into /tmp/dump.

Loading the data into another Schema

Now, we will load the data we previously dump into another schema.

The first thing to do is to create the destination schema:

JS  \sql create database test2

And finally, we load the data:

JS  …

In this blog series, I’m describing how InnoDB locks data (tables and rows) in order to provide illusion to clients that their queries are executed one after another, and how this was improved in recent releases.

As we’ve already seen, the order in which server pretends transactions are happening (the serialization order) is tied to the order in which locks are granted to transactions.…

Facebook Twitter LinkedIn

While I was working on my grFailOver POC, I have also done some additional parallel testing. One of them was to see how online DDL is executed inside a Group Replication cluster.

The online DDL feature provides support for instant and in-place table alterations and concurrent DML. Checking the Group Replication (GR) official documentation, I was trying to identify if any limitation exists, but the only thing I have found was this:

“Concurrent DDL versus DML Operations.  Concurrent data definition statements and data manipulation statements executing against the same object but on different servers is not supported when using multi-primary mode. During execution of Data Definition Language (DDL) statements on an object, executing concurrent Data Manipulation Language (DML) on the …

As you know, the best way to perform logical dump for MySQL is to use MySQL Shell Dump & Load utilities. This is the most powerful option as it can dump and load in parallel (it also include many options to migrate to MDS very easily and supports OCI Object Store too).

One of the main question I receive related to MySQL Shell utility is related to the use of MySQL Shell in non-interactive mode with parameters requiring arrays.

What does that mean ?

For example if you want to dump a MySQL instance but you want to exclude some tables, you have an option called excludeSchemas and it expect an array of strings with the list of schemas you want to exclude in the dumb.

In interactive mode, this is how we use it:

JS> util.dumpInstance("/tmp/dump", {excludeSchemas: 
    ["mysql_innodb_cluster_metadata", "fred_test"], 
    threads: 8, showProgress: true})

However this notation is not …

Amazon Redshift has been providing scalable, quick-to-access analytics platforms for many years, but the question remains: how do you get the data from your existing datastore into Redshift for processing? This blog looks at that question by providing some background information on Redshift replication as well as details on how to easily replicate from MySQL to Redshift.

Tags: MySQLreplicationreal-timetungsten replicatoramazon marketplace …

Where x is >= 22 ;)

The Problem

There are few things your data does not like. One is water and another is fire. Well, guess what:

If you think that everything will be fine after all, take a look:

Given my ISP had part of its management infrastructure on OVH, they had been impacted by the incident.

As you can see from the highlight, the ticket number in three years changes very little (2k cases) and the date jumps from 2018 to 2021. On top of that, I have to mention I had opened several tickets the month before that disappeared. 

So either my ISP was very lucky and had very few cases in three years and sent all my tickets to /dev/null... or they have lost THREE YEARS of data.   

Let us go straight to the chase; they have lost …

Where x is >= 22 ;)

The Problem

There are few things your data does not like. One is water and another is fire. Well, guess what:

If you think that everything will be fine after all, take a look:

Given my ISP had part of its management infrastructure on OVH, they had been impacted by the incident.

As you can see from the highlight, the ticket number in three years changes very little (2k cases) and the date jumps from 2018 to 2021. On top of that, I have to mention I had opened several tickets the month before that disappeared. 

So either my ISP was very lucky and had very few cases in three years and sent all my tickets to /dev/null... or they have lost THREE YEARS of data.   

Let us go straight to the chase; they have lost …

Where x is >= 22

The Problem

There are few things your data does not like. One is water and another is fire. Well, guess what:

If you think that everything will be fine after all, take a look:

Given my ISP had part of its management infrastructure on OVH, they had been impacted by the incident.

As you can see from the highlight, the ticket number in three years changes very little (2k cases) and the date jumps from 2018 to 2021. On top of that, I have to mention I had opened several tickets the month before that disappeared. 

So either my ISP was very lucky and had very few cases in three years and sent all my tickets to /dev/null… or they have lost THREE YEARS of data.   

Let us go straight to the chase; they have lost their …

This blog provides high availability (HA) guidelines using group replication architecture and deployment recommendations in MySQL, based on our best practices.

Every architecture and deployment depends on the customer requirements and application demands for high availability and the estimated level of usage. For example, using high read or high write applications, or both, with a need for 99.999% availability.

Here, we give architecture and deployment recommendations along with a technical overview for a solution that provides a high level of high availability and assumes the usage of high read/write applications (20k or more queries per second).

Layout

Components

This architecture is composed of two main layers:

• Connection and distribution layer
• RDBMS …