I have been reading about MySQL scaling and I found out that MySQL supports two type of architectures :
Master - Slave - Since updates from master to slave are asychronous then it is possible to have incosistent reads in case a slave is not updated ( due to latency or any other reason). So this system is highly available but not very consistent.
NDB Clustering - So MySQL can use NDB engine to deploy a cluster like NoSQL databases where sharding is also involved. I have two doubts in this that let's say I have 3 data nodes then how NDB engine performs JOIN queries because some of data can reside on Node 1 while other can be on Node2. Also does NDB cluster supports replication of data node? And if it supports replication then replication will be done to same data node or any other node?
Related
I want to do synchronous and asynchronous replication, synchronize for some databases, and asynchrony for others.
Asynchronous I am doing it through MariaDB, through the traditional system that has replication.
But I want to implement synchronous replication also with Mysql / MariaDB.
The problem is that I do not know if Mysql Cluster also does that work, or if it is not necessary to have Mysql installed only or MariaDb and only use Mysql Cluster for both.
Thank you.
Disclosure: I am working for the MySQL Cluster team - "MySQL Cluster" as in NDB Cluster.
MySQL NDB Cluster always uses synchronous replication between its nodes. You can still use asynchronous replication to other MySQL instances or MySQL Clusters.
AFAIK only MySQL offers NDB and as open source.
Due to the usual network limitations synchronous replication is better suited for high availability in the local data center. It gives you an always consistent view of your data, two or more active instances and makes programing against it much easier.
Asynchronous is more for replication between data centers or availability zones where you can live with temporary inconsistencies in the data and have your programming model set up accordingly.
"MySQL Cluster" has more than one meaning, so I will avoid it.
"Galera" is the underlying cluster technology in MariaDB, PXC, and (if you do the installation yourself), MySQL.
Galera provides essentially-synchronous among (typically) 3 nodes. Meanwhile, each node can have any number of asynchronous Slaves hanging off it.
Also, one Galera cluster can asynchronously replicate to another such cluster. This is sometimes done with a cluster in each of two datacenters.
Mixing sync and async at the database level is quite unusual, and seems strange. The general principle of Replication is that all servers will have exactly the same (barring delays) data. Please elaborate on what you want to do. Also, think out of the box when it comes to topologies.
According to the MySQL 5.7 Reference Manual, "MySQL Cluster is a technology that enables clustering of in-memory databases in a shared-nothing system", and "MySQL Cluster tables are normally stored completely in memory rather than on disk".
Does this mean that MySQL Cluster is not suitable for a persistent data storage solution?
Is there any specific reason for not able to use slave parallel workers while working with lower version of master which not supports parallel workers and higher version of slave which supports parallel workers.
Here i am trying MASTER ( 5.5.28 ) and slave (5.6.19)
See this presentation MySQL Replication High Performance: Multi-Threaded Slaves and
Group Commit
It is stated with respect to the multi threaded replica (MTS):
Row Based Replication is supported even if replicating from a Master without MTS knowledge (e.g., from a 5.5 MySQL master).
Statement Based Replication requires a 5.6 master.
Re questions from #vidyadhar:
I don't know if replica performance will be worse if the master is 5.5. I haven't tried that. I don't mean to sound flippant, but if performance is so important to you, why wouldn't you upgrade to 5.6?
Regarding statement based replication and multi-threaded replica, I have not tested that combination. But I have not read any requirement to use row based binlog format for MTS. I assume it would work fine, because the MTS delegates events to replica worker threads based on the database, and every event in the binlog identifies the default database for the event, whether the event is in row based or statement based format.
Is it possible to configure slave in-memory database?
Master db is common, slave for read only operation could suit well into in-memory storage.
If it is not possible with MySQL, what are other database to use such scheme?
It might work for 'simple' slave, such as data size and replication, as well as tolerate lots of limits with the in-memory storage engine.
mysql-cluster-expert-5.1 document mentioned that:
"MySQL Cluster tables in MySQL 5.1 are normally stored completely in memory rather than on disk (this is why we refer to MySQL cluster as an in-memory database)"
which means mysql cluster is a distributed memory database, so has anybody ever done a comparison of mysql cluster & redis on speed?
I don't think redis does anything remotely similar to MySQL cluster, so you can't compare them.
MySQL cluster is a high-availability, fuly durable SQL cluster with fully synchronous replication. Redis is not. As far as I understand, redis supports neither synchronous replication, nor SQL.
MySQL cluster means that when you can COMMIT TRANSACTION**, if you lose any cluster member permanently 1ms later, your data are still safe. MySQL cluster query nodes (which are the clients) automatically fail-over in a very short time (typically < 5 seconds).
Redis does absolutely none of this. It is a non-SQL based data store which has master-slave replication (failover? You'd better implement it yourself)
You may as well ask if a motorbike is faster than an ocean liner.
** I don't think redis supports transactions, so that notion is rubbish as well.