Hi @v-namac,
Checking the data you provided, we can find the information below:
Some users have a particularly big session_tokens metadata entry in "wpusermeta". Since the session_tokens rows are getting modified each time a user logs in/out, writing to a big row such as this one could consume lots of resources and could be the cause of your issues. You should check the user IDs (i.e. the user with id 186,922) and match them with the "wpusers" table to ensure, although unlikely, that the rows are not getting populated with malicious intent. Useful things to check: e-mail addresses authenticity, IP address locations (i.e. check if they are from China or other countries where hacks are usually originated from), etc. If so, consider blocking them.
It seems you have a plugin for exporting data to CVS. That specifically seems to occupy a big chunk of the "wpusermeta" table, probably close to 3GB of the 3.6GB table. Check whether this plugin is necessary, and consider disabling/removing it. You may need to manually need to remove the rows afterwards.
Similar to the session_tokens issues, it seems some users may be taking advantage of achievements ("badgeosachievements"), but it doesn't seem to as impactful as the previous case. Just in case, it would be a good idea if you investigate some of the users with the biggest "badgeosachievements" entries to avoid problems.
You have a very high amount of users, probably active users as well. Let's talk on this below.
In order to fix your issues, you should first investigate and fix possible bottlenecks in SQL requests with tools such as the WordPress QueryMonitor plugin. It is possible they are related to the the CSV plugin or problematic users like we mentioned earlier.
If you do encounter users with malicious intent, usually a user removal with an e-mail and IP block might be enough, but you should check the metadata gets removed anyways. Before removing data from the database, always create a backup to avoid possible issues.
Finally, once you identified bottlenecks with the database via tools such as WordPress QueryMonitor, it is still possible you find that your database is too big for your instance due to a high number of active connections. Bitnami autoconfigures MySQL up to 32GB of memory, so you might be able to scale your instance.
Note that we recommend separating the database to a different instance instead of scaling, ideally with a service such as Azure Managed MySQL or AWS RDS (to avoid having to manage them by yourself), but a separate MySQL instance would also be an option.
Instead of this command:
ln -s /opt/bitnami/bnsupport/bnsupport-linux-x64.run /opt/bitnami/bnsupport-tool
Please this:
rm -rf /opt/bitnami/bnsupport-tool
ln -sf /opt/bitnami/bnsupport/bnsupport-linux-x64.run /opt/bitnami/bnsupport-tool
/opt/bitnami/bnsupport-tool
Hopefully that should be enough to get it working. If not, you can execute it by directly running the binary:
/opt/bitnami/bnsupport/bnsupport-linux-x64.run
Unfortunately an upgrade with a Bitnami image requires a forced maintenance time window. Mainly because you need to migrate the database and files to the updated version.
You would need to spin up a new server. Once running, there are usually two simple options:
- Migrate All-in-One WP Migration or a similar plugin (simpler)
- Manual migration approach
For the manual approach, you would manually migrate the contents below using a tool such as "scp":
Once the content is copied, and verified to be working properly, just update the DNS for the domain so it points to the new server, but keeping the old one under maintenance. Using a static IP that you could map to the new instance is a good idea, as it would be the faster approach and avoid issues with DNS propagation.
If you were to use a managed MySQL/MariaDB service, you could avoid the database migration step and drastically reducing the time spent on maintenance, as you would only need to spin up a new WordPress+NGINX server, copy the needed files and update the DNS.
Let us know if you have any questions.
