Mysql – Aurora Serverless alter table Error 1114 table is full

aws-auroraMySQLmysql-5.6

Using Aurora Serverless, when attempting to alter table mytable add column mynewcolumn decimal(10,3) after myoldcolumn I receive "ERROR 1114 (HY000): The Table 'mytable' is full". The table has hundreds of millions of rows. Normally this error results from a full partition, but since I'm using Aurora Serverless, I can't manually provision partition space. What should I do to avoid this error?

Best Answer

On the AWS Forums, LawrenceAtAWS said,

the amount of temporary storage space associated with Serverless increases linearly with the number of associated ACUs. If you're having issues running out of temporary storage space for large table mutations, you could temporarily scale the cluster up to a larger number of ACUs and then run the modify statement. This should increase the associated temporary storage an allow the statement to succeed.

The way to achieve this with the CLI is aws rds modify-current-db-cluster-capacity --db-cluster-identifier sample-cluster --capacity 64

Related Solutions

Mysql – ERROR 1114 (HY000) at line 6308 in file & The table user_analysis is full

You have set aside, 12000M for your InnoDB DataFiles (ibdata1...ibdata12). The only possible way for you to have this error is if all 12000M of InnoDB DataFiles have no more room to accommodate new rows into it. How is that possible?

There are four types of information that reside in InnoDB DataFiles

Table Data Pages
Table Index Pages
Table MetaData
MVCC Data

MVCC is Multiversion Concurrency Control. This facilitates ACID Compliance and Transaction Isolation for every SQL transaction, whether it is a single SQL statement or a block of SQL Statements. Whenever you run SQL against InnoDB Tables, that will definitely involve transaction control thus introducing new MVCC Data. Even if you do not execute START TRANSACTION...COMMIT/ROLLBACK paradigms in your application, AUTOCOMMIT is on by default. That will cause InnoDB to write MVCC Data around any data you are reading and/or writing. If there is enough MVCC in the InnoDB DataFiles, it could potentially block InnoDB row data of a certain length from being written.

You have three options to make this go away:

OPTION 1 : Add one or more InnoDB DataFiles to innodb_data_file_path

innodb_data_file_path=ibdata1:1000M;ibdata2:1000M;ibdata3:1000M;ibdata4:1000M;ibdata5:1000M;ibdata6:1000M;ibdata7:1000M;ibdata8:1000M;ibdata9:1000M;ibdata10:1000M;ibdata11:1000M;ibdata12:1000M;ibdata13:1000M;ibdata14:1000M

OPTION 2 : Add autoextend to the laste InnoDB DataFile in innodb_data_file_path

OPTION 3 : Cleanup the InnoDB Infrastructure

This would be the most enduring solution because there is an option to keep Table Data Pages and Table Index Pages from ever entering the InnoDB DataFiles. You would have to set this option in my.cnf

[mysqld]
innodb-file-per-table

This creates a separate tablespace (.ibd) file for each InnoDB table create after you restart mysql with this new option. Just putting in the option and restart mysql will not create the tablespace file. The added bonus for doing this is that you can collapse the innodb_data_file_path to the default:

[mysqld]
innodb_data_file_path=ibdata1:10M:autoextend

I wrote up instructions on StackOverflow on how to do this.

Mysql – Change MySQL’s temp directory

Searched a bit more and I found the solution:

[mysqld]

tmpdir=[other drive]:/tmp

Now it's writing to the tmp directory on the wanted drive.

Best Answer

Related Solutions

Mysql – ERROR 1114 (HY000) at line 6308 in file & The table user_analysis is full

Mysql – Change MySQL’s temp directory

Related Question