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.
Related
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?
I have two kubernetes cluster and I want to make master-master replication for Mysql database. As I read vitess documentation, that is convenient, but I don't know how to do that?
the data is more than 500G in mysql and maybe need sharding. how can I use vitess as Mysql cluster to have zero down time on database layer?
Vitess does not support master-master replication: https://vitess.io/docs/overview/scalability-philosophy/#no-active-active-replication
If zero downtime is your primary concern, then I recommend looking to Percona Xtradb Cluster or Mysql Group Replication, but these require very reliable network between cluster nodes and can easily cause more issues then solve if used incorrectly.
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.
On Galera Mysql Cluster (either Percona or MariaDB) limitation refers that XA transactions are not supported, cause of cluster nature, which is perfectly understand. My question: (i am not a developer so please show some mercy on me) is there any mechanism that replies an OK if the statement has been committed to majority of nodes - something like MongoDB write concern?
Galera replication is synchronous and when a write query gets back to you, the data is on every node in the cluster. If for any reason a node cannot apply the transaction, it will kill itself to maintain the integrity of data throughout the cluster.
I'm trying to test the performance of using memcached on a MySQL server to improve performance.
I want to be able to use the normal MySQL command line, but I can't seem to get it to connect to memcached, even when I specify the right port.
I'm running the MySQL command on the same machine as both the memcached process and the MySQL server.
I've looked around online, but I can't seem to find anything about using memcached other than with program APIs. Any ideas?
Memcached has its own protocol. The MySQL client cannot connect directly to a memcached server.
You may be thinking of the MySQL 5.6 feature that allows MySQL server to respond to connections using a memcached-compatible protocol, and read and write directly to InnoDB tables. See http://dev.mysql.com/doc/refman/5.6/en/innodb-memcached.html
But this does not allow MySQL clients to connect to memcached -- it's the opposite, allowing memcached clients to connect to mysqld.
Re your comment:
The InnoDB memcached interface is not really a caching solution per se, it's a solution for using a familiar key/value API for persistent data in InnoDB tables. InnoDB does do transparent caching of data pages in its buffer pool, but this is no different from conventional data reads with SQL. InnoDB also commits all changes to its transaction log synchronously on commit.
Here's a blog from my colleague at Percona. He tested whether the MySQL 5.6 memcached API could be used as a caching layer, and found that actually using memcached is still superior.
http://www.mysqlperformanceblog.com/2013/03/29/mysql-5-6-innodb-memcached-plugin-as-a-caching-layer/
Here's one conclusion from that blog:
As expected, there is a slowdown for write operations when using the InnoDB version. But there is also a slight increase in the average fetch time.