There's definitely better alternative way to mitigate accident, this way only applies in my specific circumtances, thus not scalable for other cases.

Things to keep in mind

If you want to inspect and alter the production database directly, it's a good idea to duplicate it first and clone the database to local development, even if the purposes is not debugging or testing, it's reduce the risk of being stupid and accidently perform an error.

To keep it synced, you must cut all connection to the database and make your app in maintainance mode before duplicate the database.

duplicate it with: mysqldump -u <user> -p <db_name> > /path/to/snapshot/<year>-<month>-<date>-db_backup.sql

and to clone it to local, I recommend to compress it and use scp to pull it out to your local machine.

compress it with xz: xz -v --keep -9 2024-11-08-db_backup.sql, the extreme option (-9) only suitable for larger file. it will take a while and you can compare the size with xz -l <file.xz> to show original, decompressed size and du <file.xz> to show compressed size.

If you have enough memory and powerful CPU, using xzcat is preferred to decompress the file and pipe it to the mariadb: xzcat -v --keep <file.xz> | mariadb -u <user> -p <db_name>, the benefits are free your disk space and reduce unnecessary I/O ( = ⩊ = )

side note: it seems the tmpfs will use disk if you allocate more than available ram or the ram is not sufficient enough (?)

The point is, Always take care to proceed with caution.