Seems from the documentation that the procedure doesn't support specifying which file within a .bak you're actually trying to restore. The native RESTORE DATABASE command allows you to specify this using FILE = .
I think the solution in your case is to always back up any database to a single .bak file (name the backup file uniquely, and always use WITH INIT ...
They're differences in the minor/patch versions of Aurora.
If you spin up an instance of Aurora (MySQL)-5.7.12, then run:
SELECT @@aurora_version; -- Returns 2.02.5
It's essentially the first version of MySQL 5.7 compatible Aurora.
You need to find the columns with that type outside of information_schema. Information_schema is not user tables, they are system tables.
join pg_class on attrelid=oid
join pg_namespace on relnamespace=pg_namespace.oid
WHERE atttypid::regtype::text like '%sql_identifier'
Your session is in idle state, not the query.
Sessions that are idle are not a problem. It simply means the backend is waiting for the client to send a SQL query.
The number of sessions is a little bit on the high side though. You will need to have a really powerful server to cope with that, once all of them start doing something.
Sessions that are idle in ...
Write your own bash script and schedule Incremental Load Job to sync Prod and reporting server/DWH DB,
Step 1: Does a mysqldump on Prod (without lock) to fetch records from tables (Where updated_at between Previous_Day_Start and Previous_Day_End)
Step2: Restore the backed up SQL file into reporting/dwh instance, (Delta DB - create your staging DB here)