How does Mysos handle the spin-up of new slaves? One of the pain points of our current Chef-driven environment is the provisioning of new slaves. We use Chef to install and configure MySQL but to get a slave up and running, we use xtrabackup to dump the master's DBs to disk, then rsync them to the slave, then use xtrabackup to restore the dump. Once that's done, we point the new slave at the master and start it slaving. It's totally manual and takes around 15 minutes each time. How does Mysos automate this?
Looking at to code, it pulls from a backup and restores the state. It manages the cluster slave and master states via zookeeper. When the master fails a slave is promoted.
So, in order to run this you need zookeeper, hdfs, and mesos. Its a great solution, but not for everyone.
How is HDFS quite nicely in small environments?
I mean a minimal HA deployment of HDFS contains at least 5 nodes.
2x Namenode, 3x Data Nodes. Sorry but for "starting out small" this is definitely too much.
Mysos follows similar steps, it just automates them for you. Mesos gives the scheduler abstracted resources and finds the box to launch the MySQL task. The task still needs to install MySQL (possibly pull the package from HDFS) and recover the state (also possibly pull from DHFS). These things are specific to the organization's workflow and the MySQL task's behavior can be customized by implementing interfaces for these steps. Mesos bridges the central scheduler and the MySQL instances distributed across the datacenter so it can monitor them, make centralized decisions and communicate with the instances reliably.
This is really interesting, specially if it really reduces the burden of running Mysql with failover or multiple slave databases. This is similar to what is currently available on AWS - RDS, but requires separate database instances and is very tricky to implement on development environments or local infrastructure.
I'd be interested in knowing if any of you have tried it or inspected the code in detail.
it's still relevant? I never suggest to people who are starting a project to use mysql. (even percona, although I know they do good work).
if there is a case for using mysql can someone explain it to me? it feels like a toy in comparison to postgresql, oracle or mssql.. and is too "warty" for small systems either (where sqlite dominates).
from what I can tell the only real advocates of mysql seem to be those unwilling to adopt new technology.. but this is all my experience and I'm genuinely curious if anyone sees it differently.
MySQL supports UPSERT, it supports a lot of partitioning types that Postgres doesn't (and it's first-class partitioning, rather than you having to hack it out of table inheritance). There really are features in MySQL that Postgres lacks, and I haven't even gotten into the world of replication yet. They're different databases with different features and tooling and communities and third-party software support. They should be evaluated on their merits.
I'm guessing you've not looked at MariaDB much. I used to feel the same way as you, but having recently looked at MariaDB 10, they've taken things to the next level. I highly recommend taking a look at it before writing MySQL off the way you are, it's 2015 and things have changed.
