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

質問済み 6年前5252ビュー
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

回答済み 6年前
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

回答済み 6年前
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.

回答済み 6年前
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年前

ログインしていません。 ログイン 回答を投稿する。

優れた回答とは、質問に明確に答え、建設的なフィードバックを提供し、質問者の専門分野におけるスキルの向上を促すものです。

質問に答えるためのガイドライン