0

We are planning to Expand our Database from 1 Tb to 2 Tb. what must be the corresponding configurations of the CPU and RAM for this.

6
  • Have you read the installation guide? dev.mysql.com/doc/mysql-installation-excerpt/5.7/en Oct 7 at 11:01
  • @GerardH.Pille sir please provide the neccessory configurations ..
    – adil khan
    Oct 7 at 11:24
  • 1
    Size of your database does not directly correlate to CPU and RAM, so I don't think anyone can provide you an answer. More important factors to this question is your current workload, the use cases that create that workload, and metrics on how much utilization those hardware components are typically under. Long story short, only you would know if you need to increase the CPU and RAM by monitoring, measuring, and comparing after the change.
    – J.D.
    Oct 7 at 11:49
  • @J.D. Thanks for your suggestion, we want to increase our CPU currently we are using 8 Core - 16 Thread CPU and want to upgrade to 24 core - 64 Thread CPU what steps must be taken and what should be our configurations according to this.
    – adil khan
    Oct 7 at 17:28
  • @GerardH.Pille Thanks Gerald , we want to increase our CPU currently we are using 8 Core - 16 Thread CPU and want to upgrade to 24 core - 64 Thread CPU what steps must be taken and what should be our configurations according to this
    – adil khan
    Oct 7 at 17:31
1

It is a rare MySQL server that needs to increase CPU. What is the "load average" now (typically)? How many Cores are you using now? If you are running out of cores now, then I would strongly encourage you to look into optimizing the slowest queries. That is more likely to be beneficial than adding more cores.

Increasing RAM may or may not be necessary as the disk footprint increases. It mostly depends on the "working set". This is a nebulous concept; there is no good way to measure it.

If you are doing a lot of table scans, again I say that working on the query and/or indexes is the way to go. That will help I/O, RAM, and CPU. At some RAM threshold, the I/O (and elapsed time) for a query will jump. Fix the query, if possible, rather than throwing hardware at it.

A common source of table scans is summarizing "data warehouse" type data. That can be very efficiently remedied (CPU, RAM, and IOPS) by building and maintaining a "summary table". (Ask for help if relevant.)

If you have years worth of data, but you only look at "recent" data (and use a suitable Where clause), then the working set is probably very small, and increasing RAM is a waste of money.

Primary settings to change:

  • When changing the disk from HDD to SSD, some settings should be changed.

  • When enlarging the disk, no settings need be changed. (Ask if relevant.)

  • When increasing RAM, the main change to make is increasing innodb_buffer_pool_size to 70% of RAM. (We need a lot more details to help with any less-important settings.)

  • When increasing the number of cores, no settings need to change.

Further steps:

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.