Showing entries 1 to 10 of 85
10 Older Entries »
Displaying posts with tag: ndb (reset)
MySQL NDB Cluster Installation Through Docker

In this post, we will see how to setup MySQL NDB Cluster from a docker image. I assume that the reader has some basic understanding of docker and its terminology.

Steps to install MySQL NDB Cluster:


Let's create a MySQL NDB Cluster with the following environment:

MySQL NDB Cluster version (Latest GA version)1 Management Node4 Data Nodes1 Mysqld ServerConfiguration slots for upto 4 additional API nodes 
Note: Docker software must be installed and running on the same host where we are planning to install MySQL NDB Cluster. Also make sure we have enough resources allocated to docker so that we shouldn’t face any issues later on.

Step 1: Get the MySQL NDB Cluster docker image on your host


Users can get the MySQL NDB Cluster image from github site (link). Then …

[Read more]
Table Partitioning In MySQL NDB Cluster And What’s New (Part IV)

Whats new in NDB Cluster 8.0 version (8.0.23)

With new configuration variables introduced in NDB cluster version 8.0.23, user now have more control in table partitioning. Below are the new config variables that can influence the table partitioning scheme:

  • PartitionsPerNode
  • ClassicFragmentation


PartitionsPerNode:


In earlier cluster versions, the default number of table partitions is based on the number of LDM threads running on a node multiplied by the number of data nodes in the cluster. User can not set any random values to MaxNoOfExecThreads (#LDM) rather the value should be less than or equal to NoOfFragmentLogParts. With cluster version 8.0.23, user can have many no of LDM threads assign to a data node.

The rationale is:

- Having many LDMs allows a data node to make good use of modern hardware.
- Having one …

[Read more]
Table partitioning in MySQL NDB Cluster and what’s new (Part III)

Whats new in NDB Cluster 7.5 version (Contd.)

In cluster 7.5 the READ_BACKUP and FULLY_REPLICATED table features were added. These features are both designed to improve read performance and scalability, and can be set on a per-table basis. These features are fully implemented inside MySQL Cluster, and tables using these features support all of the normal MySQL Cluster features - secondary unique and ordered indexes, foreign keys, disk resident columns, replication etc. The read performance improvements do not require any special effort to take advantage of – MySQL Cluster automatically chooses the most efficient way to execute reads, whether issued over NdbApi, or via SQL, executed in MySQLD or pushed down for parallel execution in the data nodes.

READ_BACKUP:

Prior to 7.5, all Committed Read operations were routed to a primary replica of the table or index fragment to be read. The …

[Read more]
Designing a Thread Pipeline for optimal database throughput with high IPC and low CPU cache misses

 There are a couple of questions about the blog post on automatic thread configuration in RonDB. Rather than providing an extensive answer in the comment section I thought it was better to answer the questions in a separate blog. In addition I performed a set of microbenchmarks to verify my expectations.


The first question was the following:


ScyllaDB also does something similar with execution stages for better instruction cache. Is this similar to what you're implementing for instruction cache on separating the threads?


The second question is:


I don't really get the functional separation of threads. To execute a query, your data will now go through a pipeline of …

[Read more]
Table Partitioning In MySQL NDB Cluster And What’s New (Part II)

Whats new in NDB Cluster 7.5 version

In this version, users have more flexible ways of table partitioning rather than the default way thru ldm. Now user can partition the table either by node or by ldm. There are 4 different ways of table partitioning supported, these are:

  • FOR_RP_BY_NODE
  • FOR_ RA_BY_NODE
  • FOR_RP_BY_LDM (Default)
  • FOR_RA_BY_LDM
    • FOR_RA_BY_LDM_X_2
    • FOR_RA_BY_LDM_X_3
    • FOR_RA_BY_LDM_X_4

From the above RA is for Read from any replica i.e either from Primary replica or backup replica and RP is for Read from Primary replica only. The above options user can give either thru create table or from alter table sql statement in the COMMENT section like below.

mysql> create table t1(col1 int unsigned not null primary key …

[Read more]
RonDB, automatic thread configuration


This blog introduces how RonDB handles automatic thread configuration. This blog is more technical and dives deeper under the surface of how RonDB operates. RonDB provides a configuration option, ThreadConfig, whereby the user can have full control over the assignment of threads to CPUs, how the CPU locking is to be performed and how the thread should be scheduled.

However for the absolute majority of users this is too advanced, thus the managed version of RonDB ensures that this thread configuration is based on best practices found over decades of testing. This means that every user of the managed version of RonDB will get access to a thread configuration that is optimised for their particular VM size.


In addition RonDB makes use of adaptive CPU spinning in a way that limits the power usage, but still provides very low latency in all database operations. …

[Read more]
Table Partitioning In MySQL NDB Cluster and What’s New (Part I)

This blog is about table partitioning in NDB Cluster. We will see how this feature has been enhanced from version to version. Also we will see which partitioning user should use under which scenario. Here I will assume that the user has some knowledge on NDB cluster.

Data distribution and table partitioning are usually coupled together. In NDB, when we talk about table partitioning, we mean ‘data distribution’ mainly as NDB doesn’t fully support RANGE, HASH or LIST partitioning. Most of the enhancements made to partitioning over the years are about ‘data distribution’ rather than supporting various partitioning schemes. The main goals of data distribution are:

- Balance: Avoid premature bottlenecks of memory, storage, cpu or network
- Scaling: Make use of all resources, add capacity with new resources
- Efficiency: Locality of access and minimal unnecessary data transfer

To …

[Read more]
Database Performance Archaeology

… an expedition to uncover (and fix) database performance issues!

© 2021 Tiago L. Alves. All rights reserved.

One of the worse things that can happen when upgrading to a newer database version is discovering that the performance is not as good as before. Despite the effort put into gate-keeping MySQL NDB Cluster’s strict performance requirements, one of our customers found a performance regression when upgrading from our 7.4 version to our 7.6 version. How did that happen when our automated performance test suite failed to show it? To answer that, and fix the issue we enrolled on a database performance archaeology expedition…

When your performance is not good enough

MySQL NDB Cluster is an open-source in-memory distributed database developed for high-availability (99.999% or more) and predictable query times. It can be found at the core of gaming, banking, telecommunication, and online services. …

[Read more]
MySQL NDB Cluster Backup & Restore In An Easy Way

In this post, we will see, how easily user can take NDB Cluster backup and then restore it. NDB cluster supports online backups, which are taken while transactions are modifying the data being backed up. In NDB Cluster, each backup captures all of the table content stored in the cluster.


User can take backup in the following states:


  • When the cluster is live and fully operational
  • When the cluster is live, but in a degraded state:
    • Some data nodes are down
    • Some data nodes are restarting
  • During read and write transactions

Users can restore backups in the following cluster environments:

  • Restore to the same physical cluster
  • Restore into a different physical cluster
  • Restore into a different configuration cluster i.e. backup …
[Read more]
MySQL Cluster Self Healing And No Single Point Of Failure Feature

In this post we will see the unique features of MySQL Cluster i.e. Self healing and no single point of failure.

MySQL Cluster No Single Point Of Failure:

As we know that in MySQL Cluster, data nodes are logically grouped into nodegroups. All data nodes in a nodegroup contain the same data, kept in sync at all times. Different nodegroups contain different data. So in a single nodegroup, MySQL Cluster can sustain multiple node shutdown at the same time but at least one node must live in that nodegroup. Lets demonstrate this feature with a 4 replicas cluster where each nodegroup have 4 data nodes.

Lets create a MySQL Cluster with below environment.

  • MySQL Cluster 8.0.22 version
  • 2 Management servers
  • 8 Data nodes servers
  • 2 Mysqld servers
  • 4 API nodes
  • OS: Ubuntu 20.04 LTS
  • NoOfReplicas = 4

[Read more]
Showing entries 1 to 10 of 85
10 Older Entries »