Tag Info

New answers tagged

1

Not sure if you found a solution to this but for us it seems to be related to the size of data leaving the VPC. If you run a query with a small result set: show collation like '%utf8_swedish%'; The result returns fine, but if you take away the like and get a large result set back it fails. We're still investigating the problem but not sure you found a ...


0

By definition, "replication" means an exact copy. So the data type of your ID (primary key) columns is irrelevant. Whatever data is written into the master database gets written into the replicants be it integers, UUIDs, or text. Think "Xerox copies of each invoice as written", not "writing new fresh separate invoices". If you are exchanging data between ...


-1

I apologise if I misunderstood (I don't use Amazon RDS). But can you use: SET SESSION SQL_LOG_BIN = 0; -- DO STUFF HERE SET SESSION SQL_LOG_BIN = 1; After setting it to 0, it will prevent everything in your current session being written to the Binary logs. Setting it back to 1 will resume writing to be binary logs. Everything else continues as per ...


1

Your question is about troubleshooting, not about 'fixing' the CPU issue. Nearly all CPU issues can be traced to bad/missing indexes or poorly written queries. Do you have the slowlog turned on? With long_query_time = 2? Can you run pt-query-digest? Well, probably you said no to all of those. Pursue them for future use. Can you do SHOW FULL ...


0

It was a combination of making too many transactions and too many functions. After combining statements into the same transactions and removing the functions, the CPU hasn't risen past an average of 5%.



Top 50 recent answers are included