> I'm reading and trying to figure out how crazy > is using Ceph for all of the above targets [MySQL] Not crazy at all, it just depends on your performance needs. 16K I/O is not the best Ceph use case, but the snapshot/qcow2 features may justify it. The biggest problem I have with MySQL is that each connection uses a single CPU core. Combine this with poor 16K performance, and it's tough to get good performance unless there are a lot of users. Mass loading of data is particularly agonizing on MySQL, especially on Ceph. The last time I had to do a mass import, it was much faster to copy the rbd to a local drive partition and run my VM there for the import and then copy the block device back to the rbd. This is because you can use qemu-img to copy the block device with a large block size and up to 16 threads which can move multiple terabytes an hour. My MySQL database is almost always CPU bound and never more than ~20% iowait, so it can run on Ceph fairly well. Mark On Tue, Jun 14, 2022 at 8:14 AM Kostadin Bukov <kostadin.bukov@xxxxxxxxxxxx> wrote: > > Greetings to all great people from Ceph community, > I'm currently digging and trying to collect pros and cons of using CEPH for > below purposes: > > - for MySQL server datastore (InnoDB) using Cephfs or rbd. Let's say we > have 1 running Mysql server (active) and in case it fails the same InnoDB > datastore is accessed from a MySQL server 2 (started, access the InnoDB > from MySQL server 1 and become the new active). Or better to use old-school > 2 MySQL servers with replication and avoid Ceph at all)? > - storing application log files from different nodes (something like a > central place for logs from different bare-metal servers or VMs or > containers). By the way our applications under heavy load could generate > gigabytes of log files per hour... > - for configuration files (for different applications) > - for etcd > - for storing backup files from different nodes > > I'm reading and trying to figure out how crazy is using Ceph for all of the > above targets. > Kindly can you share your opinions if you think this is too complex and I > can end up with a lot of troubles if Ceph cluster goes down. > The applications and MySQL server are for production/critical platform > which might high-availability, redundancy and performance (sometimes apps > and MySQL are quite hungry when writing to the disk) > Log files and backup files are not so critical so maybe putting them on > Ceph with replica x3 would just generate unnecessary ceph traffic between > the ceph nodes. > Application configurations are needed only when start/restart application. > The most critical data from the whole is the MySQL InnoDB data > > Would be interesting to me if you share your thoughts/experience or I > should look elsewhere.... > > Regards, > Kosta > _______________________________________________ > ceph-users mailing list -- ceph-users@xxxxxxx > To unsubscribe send an email to ceph-users-leave@xxxxxxx _______________________________________________ ceph-users mailing list -- ceph-users@xxxxxxx To unsubscribe send an email to ceph-users-leave@xxxxxxx
 |