对于 mysqldump --all-databases 导出后的 SQL(通常是 4~5 个 database)有几十 GB,各位目前在用的是怎样的方案?
此前用的单是 2 块 SSD+1 块 HDD,分别做主库+binlog(hdd)、从库。而且是基于 ESXi 的虚拟化。
服务器有 128G 内存,感觉物理机直接跑太浪费资源,所以一直犹豫。
但最近又考虑把各主库迁到 RAID10(HDD)的机器上(从库继续保留在原机器上),感觉这样比单块 Intel SSD 会保险一些( SSD 有时会掉盘,但重插拔、重启又会恢复)。可又担心即使做了 RAID10 的 HDD 的 I/O 还会成为瓶颈。
所以:
1、在犹豫应该使用物理机直接跑,还是 ESXi 虚拟化 vm 再去跑。两者的性能不知差别是否会大?
2、各位有什么方法、技巧去分析判断数据库 I/O 是否成为瓶颈的?
3、假设是你在做这样的方案,还会有哪些方面的考虑?能否分享一下?
4、各位用 MySQL 跑过的最大的数据库大概是多大?(指 mysqldump 后的单 database(约 10GB)、all-databases(约 40GB))。(不过好些年前搞 IDC,貌似印象中还有个客户论坛 mysqldump 后有 28GB,那时还是用的 5.1 左右的版本,未做主从)
完善补充: 刚才说的几十 GB 只是单组集群,但面对的是多组集群,所以才又想到用物理机 RAID10 直接跑 CentOS+MySQL。(换而言之:把多少组的集群主库迁到 RAID10 比较合适?假设以 40GB * N,其中的 N==集群数)
1
nandaye 2017-09-14 17:49:00 +08:00
1.虚拟化 VM 跑,MySQL 用物理机太奢侈了吧
2.插大量数据做对比测试? SSD 的话,I/O 应该不是问题吧,如果 I/O 还是有瓶颈,你有什么办法? 3.如果是生产,主从以外还需要热备机和异地容灾备机吧 以上是不负责胡说 |
2
defunct9 2017-09-14 22:28:12 +08:00
上 docker
|
3
wkl17 OP |
4
defunct9 2017-09-21 09:24:32 +08:00
认真回复下,上一条纯属胡说八道。
MySQL 现在绝对不要上 Docker,因为无论是进入容器的方式,还有启动 mysql 的方式,都会跳坑。 我们的数据库服务器是 Dell R730,128G 内存,Raid10,4×600GB,大概是 1TB 可用空间。 IO 和吞吐暂时都没遇到瓶颈,等到了再说。 |