MySQL Relational Database Server and Its Tools
View All Tags
ERROR 3888: Failed to set up SSL with Unable to get private key means MySQL couldn't use the files you asked it to load. The good news is in the manual: a failed reload changes nothing, and the old certificate keeps running until you fix it.
Connections using insecure transport are prohibited while --require_secure_transport=ON means the server refuses anything unencrypted, and this connection is. Turn TLS on in the client: it's usually one option.
Access denied for user 'inventory_app'@'localhost'. Account is locked. is unusually clear: the password isn't the problem, the account is switched off. One thing I didn't expect: sessions that were already connected kept working.
Authentication requires secure connection comes from how MySQL's default sign-in works: the first time it checks a password, it needs an encrypted connection to do it safely. Connecting over TCP with TLS turned off gets you this error, and the same command worked a minute later, which threw me at first.
Your password does not satisfy the current policy requirements means the validate_password component is on, and it doesn't like this password. The message doesn't say why, but the rules are one query away.
User 'inventory_app' has exceeded the 'max_user_connections' resource (current value: 2) means that one account has as many connections open as it's allowed. The number is in the message, so the question is who has them, and whether the limit is right.
ERROR 1142 (42000): DROP command denied to user means the account you're signed in with doesn't have that right on that table. If the account belongs to an app, that's often exactly what you want. And TRUNCATE gives the same message, which surprised me.
docker compose up printed Recreate when I'd changed nothing, and then root's password stopped working. I had two projects open, and I'd exported one project's .env into my shell. Compose prefers the shell's variables over the .env file, so the other project's container got the wrong values.
Part 3 changed one row at a time. Real work changes several: take the stock, record why, create the order. In this part, those become one unit, you'll watch what MySQL's row locks do when two people buy the last item, and the API learns to survive deadlocks, a MySQL restart and a dropped connection. Some of it surprised me: with Oracle's provider, the retries from Part 1 retry nothing, and a short CommandTimeout can make a request hang for good.
Two people cancel the same order at once. Each one reads Placed, and each one puts the stock back, so you've restocked twice. Put the status in the UPDATE's WHERE, and only one of them can change it. The other one finds out and stops.
