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개 답변
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년 전

로그인하지 않았습니다. 로그인해야 답변을 게시할 수 있습니다.

좋은 답변은 질문에 명확하게 답하고 건설적인 피드백을 제공하며 질문자의 전문적인 성장을 장려합니다.

질문 답변하기에 대한 가이드라인