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?
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 wrote some functions that work with SQL. I test the functions using testthat and an in memory SQLite database. However, some functions cannot be tested using SQLite because SQLite does not support the ALTER TABLE command.
Is there some way to simulate a mySQL database in memory the same way that one can simulate a SQLite?
> DBI::dbConnect(RSQLite::SQLite(), ":memory:")
<SQLiteConnection>
Path: :memory:
Extensions: TRUE
> DBI::dbConnect(RMySQL::MySQL(), ":memory:")
Error in .local(drv, ...) :
Failed to connect to database: Error: Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2)
If not, how does one write automatic tests for mySQL functions?
You can't make a whole MySQL instance run in memory like the SQLite :memory: option. MySQL is designed to be a persistent database server, not an ephemeral embedded database like SQLite.
However, you can use MySQL's MEMORY Storage Engine for individual tables:
CREATE TABLE MyTable ( ...whatever... ) ENGINE=MEMORY;
The equivalent in RMySQL seems to be the dbWriteTable() method, but as far as I can tell from documentation, you can't specify the ENGINE when creating a table with this method. You'll have to create the table manually in the MySQL client if you want to use the MEMORY engine.
But you should be aware that every storage engine has some subtle different behavior. If any of your tests depend on features of InnoDB, you won't be able to simulate them with the MEMORY storage engine (e.g. row-level locking, foreign keys, fulltext search).
Read the manual on the MEMORY storage engine: https://dev.mysql.com/doc/refman/5.7/en/memory-storage-engine.html
P.S.: Ignore the suggestions on that manual page to use NDB Cluster. It may be faster, but it requires multiple servers and special database design to achieve that performance. It's much harder to set up.
I'm developing a application that needs two diferent databases, this is because one of this databases is per client and the other one is a generic database.
I'm thinking in make a MySQL NDB Cluster and i need to know if it's possible to uses some Federated tables in the Cluster or all must use ndbcluster engine.
If this is not posible, how can i make joins with tables that are in other host using ndbcluster?
Please forget about, why i need this schema (one databse per client and one generic database) because i spent a lot of time thinking which should be the best schema for my application i choosed this one.
Thanks in for your help!!!
MySQL Cluster uses a full version of mysqld (slightly modified), which includes all storage engines included on a standalone version. So the question for your answer is YES, you can have some tables in FEDERATED storage engine, or any other storage engine.
However, only tables with storage engine=ndbcluster will be replicated to all the api nodes connected to the cluster.
The federated approach with a cluster of two api nodes could work, but keep in mind that only those tables with the same storage engine can have referential integrity (FK) between them.
Which version of MySQL Cluster are you using? It is recommended using always the latest GA release (now 7.4.12)
Regards
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.