Does MySql support for cluster environment? Whether Community edition support for clustering?
I want to know more details about it. Please guide me where can I get details?
You can read everything about MySQL Cluster (which is a different version than MySQL Community, but you can get both for free) on the MySQL website:
http://www.mysql.com/products/database/cluster/
MySQL Community edition can be set up to do master-slaves replication, but that's not as cool and effective as what MySQl Cluster can do.
Yes, MySQL Cluster does support clustering. If you have a Amazon EC2 account, I recommend this tool/website for setting up a MySQL Cluster quickly for testing: http://support.severalnines.com/entries/20916823-installing-on-amazon-ec2
MySQL Cluster is apparently the only MySQL solution right now from Oracle (outside of Percona and others) that allows for 99.999% availability (HA).
From my initial tests, MySQL Cluster is really fast at writes, but slightly slower at reads, though it aggressively caches reads after the first read. I'm still studying it myself.
Also, MySQL Cluster community edition should suffice for most use cases. I think the Carrier Grade edition is only for real heavy-duty uses.
You can get straight to the community (GPL) download for MySQL Cluster at http://dev.mysql.com/downloads/cluster/ (or the commercial version from Oracle e-Delivery - the functionality and underlying code base is the same).
An alternative to MySQL Cluster is SchoonerSQL, a cluster based on MySQL but uses the standard InnoDB storage engine rather than NDB. It supports 99.999% availability and has a very simple GUI management console. Go to SchoonerInfoTechcom
Related
We use RDS MySQL with a micro service architecture. Each service has its own database and we have been slowly moving them into their own instances for load management and whatnot.
We have a replica still attached to the primary instance (where most of the databases still reside) but it is missing the databases that are on their own instances. We would like to have a single read replica that sources from all of the instances so that we can run sanity checks on the data without needing to move data between instances.
Does RDS support a multi source read replica? Or will we need to manage our own MySQL install in order to accomplish this?
As far as I know, you will have to operate MySQL yourself on EC2 to get the multi-source replication feature. You may like to contact your AWS support representative to confirm this.
AWS RDS does not support multi-source replication. Configuring replication from an external master is limited because you have to configure it using a stored procedure provided by AWS. It does not have any support for configuring multiple replication channels. Each replica has exactly one master.
AWS Aurora 2.x (API-compatible with MySQL 5.7) also does not support multi-source replication. As of Aurora 2.07.x, they list multi-source replication among features of MySQL 5.7 they do not support. See https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Updates.2070.html
AWS Aurora 1.x (API-compatible with MySQL 5.6) has something they call multi-master cluster, where all the nodes in a cluster can be writers. I have not used this, and I don't know how reliable it is. See https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-multi-master.html for details.
It's weird that they seem to have lost functionality between Aurora 1.x and 2.x. My understanding is that they sort of "started over" with Aurora 2.x, and some features haven't been implemented in the new version yet.
This is my understanding as of December 2019. Of course future versions may add such features.
Please forgive my ignorance but I do not have a ton of experience with MySQL. I am a web developer but overall I have pretty much just installed MySQL or spun up an RDS instance, connected to it and everything just works. However I am currently being tasked with creating a complete backup of our primary server (essentially high availability with a load balancer etc). So I thought now might be a good time to change how I haver our MySQL setup to take advantage of having 2 servers. Currently our MySQL lives on our primary servers and that will probably stay that way for now, however my goal with this new setup is to have 2 identical servers, both running the application and both having the exact same MySQL data structure / data. I want to be able to essentially open up the web application on one server, make a change, see it on the other or vica versa.
From my research it looks like what I want is called "Master-Master Replication" however it seems as if this is an older / more outdated approach? Every article I read is from ~2010-2012 and most people say it is depreciated and I should use Percona XtraDB Cluster, MySQL Group Replication, or Galera Cluster etc. I basically have no idea what any of that means and I am looking for the easiest way to get Master-Master type setup working. On top of that even if I wanted to use regular Master-Master replication it seems as if this is something specific to MySQL and not Percona which is what I actually use.
I know plenty about dev ops and can get everything but the MySQL up and running in no time but I would love some insight on the best way to do this. Currently servers are running Centos 7, Percona 5.7, Apache 2.4.
The easiest way to start is to setup a percona xtradb cluster with proxysql.
Percona xtradb cluster handles all the problems that are present in basic MySQL Master-Master Replication.
Both Galera and Percona Xtradb CLuster are same, as they use the same galera plugin, Only that Percona has customized it and added some extra features like in built proxysql( kind of load balancer for database).
Let's clear up one thing first. Percona is MySQL. If a feature is available on Oracle MySQL (the community version is what I am referring to here), then it is also available on Percona. Think of the two like a cake: MySQL is the base "cake" and Percona is the frosting/sprinkles/etc that go on top.
That being said you can absolutely do Master/Master using Percona MySQL. The standard/best practice is to configure this in active/hot-standby. Meaning, do not write to both nodes at the same time. Your application, or your middleware/proxy, must isolate writes to only one node. This will save you insane headaches when/if replication breaks.
ProxySQL is not a Percona product, but we do support it 100%. You can place ProxySQL in front of your M/M and setup the correct query rules to only route to one MySQL.
You are correct that the most modern solution here, and in my opinion, an easier solution, is to set up a 3-node Percona XtraDB Cluster (PXC). Again, Galera MySQL is the "cake" and PXC is all the extras on top. Group Replication is pie (just to continue the analogy.)
We consider a 3-node PXC fronted with ProxySQL to be one of the best HA solutions out there for MySQL. It is still best practice to only write to one node, and utilize the other 2 for read-only queries. If the primary node goes down, each of the other two have an up-to-the-transaction copy of the data. Again, ProxySQL helps route the traffic if primary goes down.
Backups can be taken from any PXC node using Percona XtraBackup in a non-blocking/hot fashion.
At my company we are considering the possibility to migrate our MySQL dbs to AWS Aurora.
AWS documentation states:
What does "MySQL compatible" mean?
It means that most of the code, applications, drivers and tools you already use today with your MySQL databases can be used with Aurora with little or no change. The Amazon Aurora database engine is designed to be wire-compatible with MySQL 5.6 using the InnoDB storage engine. Certain MySQL features like the MyISAM storage engine are not available with Amazon Aurora.
I haven't been able to find a documentation exhaustively listing which MySQL features are not available with Amazon Aurora, and what kind of "little change" we might have to do if we decide to migrate.
What kind of non-BC change should we expect to encounter if we switch (appart from the non-support of the MyISAM storage engine)?
You should not expect any change. Most of the innovations of Amazon Aurora are in the storage and replication tiers, the query engine should behave exactly the same and code run unaltered.
However, MySQL is a completely separate development and organization, so it is quite challenging and risky to put compatibility in more precise terms than what you have found. Feel free to ask if there is any feature compatibility in specific you'd like to know more about.
We have some (10-) MySQL server nodes and we want them to be replicated in a way that if one goes down the rest never get affected.
I know MySQL provides Master/Slave (not good for us) and Multi-Master replication.
Does MySQL Multi-Master replication work like a mesh? I mean all nodes can get updated from all other nodes?
Is it true that even in Multi-Master replication (MySQL) each node can only get the data from one master???
So if the native MySQL replication features can not fulfill our requirement, do you know any tool that can do this? Our preference is the built-in MySql replication.
The answer to your problem is simple yet very technical aswell. Traditional MYSQL tools cannot help so you need help of Galera cache from codership. Some features are synchronous replication which MYSQL do not offer, and it works as a cluster if you have a galera MYSQL cluster setup, one goes down rest keeps on going.
I personally use Percona xtradb cluster for this, percona xtradb cluster is patched version of MYSQL and galera embeded together. All servers can take reads and writes.
I have written an article on installing this but cannot post here as stack overflow may consider as link building.
DO some research on Galera, as you use normal MYSQL in a cluster environemnt, FULL HA and HS.
If you need some more info feel free to discuss it with me.
Thanks...
I've been researching this as well. MySQL seems to offer multi-master replication. It's explained here: http://www.onlamp.com/pub/a/onlamp/2006/04/20/advanced-mysql-replication.html
and a more complex example with masters and slaves here: http://capttofu.livejournal.com/1752.html.
There are 3rd party tools as well and the one that seems to come up often is Tungsten: http://code.google.com/p/tungsten-replicator/
And here's an excellent article on multi-master replication with MySQL: http://scale-out-blog.blogspot.com/2012/04/if-you-must-deploy-multi-master.html
As most of you know, Sun acquired MySQL (and later Oracle acquired Sun), and during these acquisitions, there were a lot of FUD in MySQL community which resulted in creation of various forks.
Today we have MySQL from MySQL, Percona (XtraDB) MySQL, OurDelta MySQL, MariaDB, Drizzle to name a few. Which brings us to the source of the problem.
We are in the process of upgrading our databases (hardware/software) and I would like to know which one of the forks should I go with. Each has their own set of pros/cons. We are currently using MySQL 5.0.x from MySQL/Linux on an 8-core machine. Our new hardware is a monster with 32 cores and 32GB of memory connecting to a fast NetApp Storage via FC.
I would like to stick with MySQL from MySQL but I have heard horror stories on how badly MySQL 5.1 performs on many cores. I have also heard that MySQL 5.4 performs better on multi-core machines but that's still not production ready. In addition, I have also heard a lot of good things about Percona builds.
This is what I know so far:
MySQL 5.1 from MySQL: Reliable choice, but doesn't scale well on a big machine
Percona: Scales well, good backing company. I don't have much experience with it
MariaDB: Don't know much about it besides that it was founded by Original MySQL developers (including Monty)
OurDelta: Don't know much
Drizzle: Mostly optimized for cloud computing
I would like to know what's the general notion about this problem. Which build/version should I go with? How are you guys picking your builds/versions?
Thanks!
All of the 'forks' you mentioned (except Drizzle) re-base off newer official releases of MySQL. I think that the word fork can lead you down the wrong path - since the intention is just to provide after market modifications. I wrote about this here:
http://mtocker.livejournal.com/50931.html
Since they re-base of MySQL, and MySQL 5.0 is in "extended maintenance", only major vulnerabilities are to be fixed. This means you want to be moving to 5.1. If we work with this assumption, then it cuts OurDelta out from your decisions - since they are just the 5.1 MariaDB build/packaging partners.
I think you can also rule out Drizzle, since it is currently pre-beta. They're planning a beta by the end of the summer - but it's still much earlier than what you'll want. I really don't think you use a database not ready for production, so this rules out MySQL 5.5 as well.
So this leaves Percona Server, Official MySQL 5.1 and MariaDB. It's true that 5.1 has some poor scalability with many cores, but if you enable the InnoDB plugin it is better.
The rest of my response from here on in is biased - I work for Percona:
Percona XtraDB has additional CPU scalability fixes than MySQL 5.1+InnoDB plugin. The ones that are going to matter are covered here:
http://www.percona.com/docs/wiki/percona-xtradb:features:start
One I can comment on in particular that will matter is this one:
http://www.percona.com/docs/wiki/percona-xtradb:patch:innodb_split_buf_pool_mutex
Personally, I think that everyone who needs to set up a new MySQL installation today should be using MariaDB. MariaDB is based on the latest MySQL 5.1, actively maintained (including fixes for bugs reported against MySQL) and packages Percona XtraDB / InnoDB plugin.
I don't even know if "fork" accurately describes Maria, since they are committed to keeping up with current releases of MySQL.
In short: MariaDB 5.1 = MySQL 5.1 + Percona XtraDB + additional useful patches + active development and maintenance
Update late 2011- May 2012: I switched from MariaDB to Percona Server to get to MySQL 5.5 but I intend on switching back once the Maria team has a stable 5.5 based release. I think that everyone who needs to set up a new MySQL installation today should be running Percona Server. If you are using SSDs, you *must* run Percona Server.
2013-2018: Happily ran Percona server 5.6 this whole time.
2018: upgraded to Percona server 5.7 and then almost immediately to MySQL 8.0. [ At this point, I am not knowledgable enough to talk about the differences between MySQL 8, Percona Server 5.7 and MariaDB 10 and I can't say why you might want to choose one over the others ]
Use MariaDB. They've just released a version lately. Maria engine is also much better than MyISAM. With opensource project, you go where the founder go.
Just an update on this. We chose to go with Percona and we can't be happier. Percona guys definitely know their stuff and keep up with the new technologies. Just checkout http://www.mysqlperformanceblog.com/ Top notch software plus top notch people and great support, you can't go wrong.
I think it's still too early to write off MySQL entirely. I'm not enthusiastic about Sun/Oracle gaining the reins, but I don't have a clear idea what direction they'll take with it. Regardless, I'd wait another year before seriously thinking of switching to a fork. Time will tell which project has the resources and motivation to survive, or if a fork is even necessary.
Google has a memory library patch out that supposedly improves performance on multi-thread / core mysql installations. Supposedly, the performance bottleneck was in the memory allocation routines, and would manifest itself starting at 4 cores. I'm currently running a dual proc box with 4 cores each, and am having no problems with 5.1.x without the memory library patch.
My biggest suggestion to you would be to install 5.4 and run a benchmark suite against it. If it does the job, go with it. The fragmentation of the various forks does suck, but maybe it will be for the best. At least the founders have money now to fund their own direction... I wouldn't take the advice to follow them blindly though... It took a lot of time and efffort to set up the mysql infrastructure initially, and while it wouldn't hurt to support the team that did it the first time, there is no guarantee they will succeed the second time. So... support them, but don't rely on them until you know you can rely on them.
If you're upgrading your databases anyway, you should consider other FOSS DBMSes, or data management software systems as well, not just MySQL.
For example, if your DB workload is analytics more than transactions, and data is mostly added in batches, you should consider using MonetDB, a columnar DBMSes which is about 1.5-2 orders of magnitude faster than MySQL when doing analytics-only.
Another option is PostgreSQL. It's more transaction-oriented - like MySQL; in fact, they're similar enough to be proper competitors. There are arguments for preferring PostgreSQL and arguments for preferring a MySQL variant.
On DB-engines.com you can find other potentially-relevant DBMSes, FOSS and closed-source/commercial.