What is the largest amount of data do you store in MySQL ?

15tb… painful to manage

We got 16TB and the hardest part is backups. Xtrabackup works good. But incrementals do not work with compressed Xtrabackups. We had a bug open for this. (We have Percona Gold support).

So, if we can get: (a) compressed xtrabackup, (b) compressed incrementals and (c) parallel recovery (or to put it more simply a simple way to parallelize the restore such that the entire io capacity of the disk sub system is utilized — we’d be much happier.

Thanks,
AD

A few other pain points with large Mysql DBs (16TB):

– Large DBs imply large tables — so DDLs are too slow. We are using Percona 5.1.6x builds. So, online index additions would be ideal. Not sure if 5.5.x or 5.6.x already addresses this.

– Large DBs also come with large buffer pool sizes. And that implies very slow shutdown and start (we have fast-shutdown disabled — all that seems to do is just shift the slowness from shutdown to starting up) – I am thinking there is no easy solution here

– A simpler way to distribute some DBs to a different mount point. We have to use symlinks to point some DBs to other places. Instead, if we could do “create database new_db using db_file_space ‘/new_mount_point/mysql_data_dir’;” — would be nice.

– Backport crash-safe replication to 5.1.6x 🙂 — yes we want to get to 5.5 — but now that 5.6.x is round the corner, have put 5.5.x migration on hold and are planning to go straight to 5.6.x

Thanks,
AD

Our main pain point is that we have a single table that has ~12+tb. This data is a rolling 90 days worth of data, write mostly, but needs to be available for immediate queries if the need presents itself. This is an innodb table. The main issue is that with a table this large any table changes are out of the question, as are backups, etc. We write at a rate of 30k+ rows / sec into this table.

If DDL statements were able to be run in a multithreaded fashion through some sort of divide and conquer methodology that would help immensely. It’s just near impossible to run any sord of DDL on a table with 180b rows. When each row needs to be managed sequentially.

I once had five minutes of stress, when I couldn’t boot up ~30TB MySQL instance, errors were way too cryptic 😉
I don’t think we’re using that configuration any more, with regular ~2-3TB machines serving the workload nowadays.

With MySQL one must shard/partition/whatnot large tables because of index locking, so I don’t even people running single huge table 😉

It were, if it worked properly. Hive and Hadoop have their share of problems, but in general handle this amount of data orders of magnitude better.

Currently we have a new 300G instance (a new internal-analytics instance) that is growing daily by 3G.
This is the entry instance for raw data from ETL scripts.

The machine is a 16GB-RAM, Quad-Core Xeon with HT, 2 x 3TB HDD (Software-RAID 1).
It’s on a CentOS 6.3 and I’m using MariaDB Server 5.5.27.

On the same instance there is also:
– an instance replicating our website prod database (too small to count – also MariaDB),
– a TokuDB instance that is computing data from the ETL instance (under 2G on permanent data)

The oddest thing is the size of computed data: 250MB… so far.

Our MySQL 5.5.28-1~dotdeb.0-log on Debian64 6 for our Minecraft is running 2.9GB large database of 71 tables where most tables are InnoDB. Works fine AFA I’ve conffed it, and I’m not awesome in that.

Currently we are storing nearly 1TB of data on mysql instance. Is it possible to store 10TB on a single instance without impacting the performance?

2 TB innodb on percona mysql 5.5 and still growing. No big problem for now. Just to use mysqldump is almost impossible. I hope noone wants to get new key on it. I am using innobackupex for backup.