0
votes

Edit: the answer to the first question is that the application calls the reader instance of the cluster. I can reproduce the problem with workbench if I execute the procedure on the reader instance.

I have a stored procedure with a temporary table. I am using Amazon AWS RDS (Aurora) MySql. I create the temporary table like:

create temporary table if not exists tmpResources(
 pkKey varchar(50) NOT NULL, PRIMARY KEY(resource), UNIQUE KEY(resource), 
 ...
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

When I call the procedure from MySql workbench it executes fine. When I call it from my application, I receive the following error:

The 'InnoDB' feature is disabled; you need MySQL built with 'InnoDB' to have it working

I have an asp.net web application, using the Oracle c# drivers version 8.0.20. AWS RDS is currently MySql version 5.7.12.

There are 2 very perplexing questions: 1. Why does it work differently when called from workbench? The error seems to be coming from server side. 2. Why do I get this error about InnoDB disabled, when it is clearly not disabled?

Thanks for any insight...

1

1 Answers

0
votes

Edit: I verified this with AWS technical support - temp tables on reader clusters are MyISAM. My initial problem involves indices on MyISAM databases, but I will post that as its own question. The response from AWS RDS/Aurora team follows:

this is by design in Aurora, and it is because when a temporary table or a system generated internal temp table is created on writer with InnoDB, it needs to go to underlying storage for readers in the cluster, but when you create temporary table on the reader, it is just for that particular reader instance and does not populate to other nodes, hence by default reader instances will pick up MyISAM engine. This behavior is attributed to the fact that the value of the variable “innodb_read_only” is set as ON for readers and OFF for writers, thus restricting the creation of InnoDB tables on the reader instances

Initial response: It appears the issue is with readers. Temporary tables on stored procedures in the reader RDS instances are not InnoDB, even though this is not documented anywhere and the instance type/price is the same for readers as for the writer. What they are exactly I don't know, I have a question to AWS about it. If they respond I'll post here.