incompatible-restore: your MySql memory setting is inappropriate for the us

0

Hi, we've been unable to use create-db-instance-read-replica in our main RDS MySQL 5.6.39 database for a few days.

We've used it reliably for years and do it weekly, but starting this week it has consistently failed to produce a replica. The instance created by the API call lands on the "incompatible-restore" state. This is what we see:

  • Summary > Info
    • Incompatible-restore
  • Logs & Events > Recent events
    • Database instance put into incompatible-restore. Your MySql memory setting is inappropriate for the usages

We haven't found anyone reporting this specific scenario, only a thread mentioning "memory setting is inappropriate" for Aurora, but with "incompatible-parameters", not "incompatible-restore."

We found this thread https://forums.aws.amazon.com/thread.jspa?messageID=537144 for a different "incompatible-restore" scenario with pointers to:

  • Temporary tables: We don't have any long-running sessions that could be clinging on to temporary tables (from querying sys.session) nor any MEMORY tables listed in information_schema.TABLES.
  • MyISAM: We don't have any MyISAM tables outside the mysql/information_schema Table Schemas

Someone also jumped in there to say they managed to clone some time later, but we've been trying for 3 days with no success.

I'd love some help understanding what's happening or pointers into how I could dig further and solve this problem.

ps: the instance is temp-staging-reports-replica

Edited by: julianobsnri on Mar 29, 2019 12:24 PM

已提问 5 年前4242 查看次数
5 回答
0
已接受的回答

Hello julianonri,

Can you please attempt another read replica creation and send me a private message if it fails? We recently deployed a change that should allow you to create read replicas again without the instance being placed into incompatible-restore due to memory settings.

Regards,
Jaime

已回答 5 年前
0

Having exactly the same problem. In one account where we had this issue the first time it started working somehow after a few days/tries. Setting up a secondary account now with the same setup and issues are back.

Did you by any chance create the RDS and removed it again, then recreated it? The Logs&Events tab show some DB info from days before even though I just created the database. Also changing the name makes it deploy with no issues. Seems that the replica technology does not clean up well.

Also, see this post over at stackexchange:

https://dba.stackexchange.com/questions/233717/mysql-rds-incompatible-restore-while-creating-read-replica

已回答 5 年前
0

Did you by any chance create the RDS and removed it again, then recreated it?

Yeah, we do this every week and have been doing so for more than a year.

Also, see this post over at stackexchange:

Thanks, I will test different params later this week. I hope they don't have to be set on the primary because doing that for our scenario is pretty risky.

已回答 5 年前
0

I can confirm we can successfully create read replicas again =]

已回答 5 年前
0

Hello, could this issue be back? just few mintues before I've had the same problem on RDS MySQL read replica, then I've set sort_buffer_size back to the default value and re-created replica - error was not there any more, I've bring back my original sort_buffer_size and it was successfully applied - read replica is in healthy status as well.asdasd

已回答 2 年前

您未登录。 登录 发布回答。

一个好的回答可以清楚地解答问题和提供建设性反馈,并能促进提问者的职业发展。

回答问题的准则