AWS Aurora's replication is more akin to Always On Availability Group. The primary pushes storage changes to other replicas. You don't get to make schema changes on the subscriber.
More details are available in several re:Invent deep dive sessions.
Have you established what you are bottlenecked on in your import? If you are CPU bottlenecked, there is a very limited amount you can do other than put CPUs with faster single-thread performance into your private cloud instance.
A few things that will help:
innodb_io_capacity=<approximate amount of ...
here are two ideas that can be tried..
Run a script or other little app in the background that scans through the killing connections that do not match the established rules
it fires off every few seconds ..
Or create a system event trigger that fires off checks the user IP address and any other information that needs to be checked when the connection is ...
That must be because you don't have permission to see these user's activities.
Statements can contain sensitive data, so they are only visible to superusers by default.
Some rows in pg_stat_activity also contain many NULLs because they belong to background processes.
What solved it for me was setting the min and max instance count higher than before (forcing aurora to scale up, for example from min 2 ACU to min 4 ACU), and after scaling restoring the scaling settings.
I used 'Force scaling the capacity to the specified values when the timeout is reached' and 'Apply immediately'.
It also solved another issue we had, the ...
Those are probably bogus.
If you have more than a few dozen connections, they will be stumbling over each other and everyone will progress very slowly. Keep the number of threads to a realistic number.
autocommit=0 should be outlawed. It begs the programmer to forget to issue COMMIT. Without COMMIT, a disconnect (or certain other things) will lead to a ...