Posts

My Journey Upgrading MySQL 5.7 to 8.4 – and the Foreign Key Surprise

I recently had a project where I needed to upgrade a database from MySQL 5.7 to MySQL 8.4 . As with most MySQL upgrades, I had two options in front of me: Do an in-place upgrade , swapping the binaries and running mysql_upgrade . Go with a logical upgrade , using mysqldump to export everything and then import it into the new version. I decided to take the logical path . It felt safer for this use case, since it gives you a fresh environment and avoids any messy leftovers from the old version. So far, so good. I dumped my 5.7 database and began the import into MySQL 8.4. That’s when things went sideways. The Error That Stopped Everything The import was moving along nicely until I hit this: ERROR 6125 (HY000): Failed to add the foreign key constraint . Missing unique key for constraint 'my_foriegn_FK1' in the referenced table 'my_parent_table' . My first thought was: “Wait… what? This schema has been running in production for years without a p...

Resolving "Access Denied for user 'xxxx'@'xxx.xx.xxx.x' (Using password: YES)" in MySQL

Image
  When managing a MySQL database, it's common to encounter the "Access Denied for user 'xxxx'@'xxx.xx.xxx.x' (Using password: YES)" error. This issue typically arises when a MySQL user’s host does not have the necessary permissions to access the database from a remote machine. Understanding the Error This error is triggered when the MySQL server refuses a connection attempt from a user due to host restrictions. The error message usually looks like this: ERROR 1045 (28000): Access denied for user 'xxxx'@'xxx.xx.xxx.x' (using password: YES) If you encounter this issue, it could be because the MySQL user is restricted to accessing the database only from specific IP addresses.   Error:     To resolve this issue, you can modify the MySQL user’s host settings, allowing access from different remote machines. Here's a step-by-step guide on how to change the MySQL user host. Solution: 1.       Log into the MySQL console   ...

PURGE BINARY LOGS IN MYSQL

Managing the binary logs in MySQL is a critical aspect of database administration, especially for those who oversee replication or large-scale data modifications. The PURGE BINARY LOGS statement is an essential tool that helps maintain the health of your MySQL server by removing unnecessary binary log files, freeing up disk space, and ensuring smooth operations. What are Binary Logs? Binary logs in MySQL are files that store information about data modifications, such as INSERT , UPDATE , DELETE , and even structural changes like CREATE TABLE . These logs are vital for replication and data recovery, but they can accumulate over time, leading to performance issues or excessive disk usage. The PURGE BINARY LOGS command helps manage these files efficiently. The PURGE BINARY LOGS Statement The PURGE BINARY LOGS statement allows you to delete old binary logs that are no longer needed. It offers two options: TO 'log_name' : This option deletes all binary logs up to,...

Troubleshooting ORA-01111, ORA-01110, and ORA-01157 Errors in Oracle Standby Database

Error Description: During the recovery process on the standby database, you encounter errors such as: ORA-01111 : Name for data file is unknown. ORA-01110 : Data file is missing. ORA-01157 : Cannot identify/lock data file. These errors typically occur when a data file is created as "UNNAMED" in the $ORACLE_HOME/dbs directory, causing the Managed Recovery Process (MRP) to fail. Error Log: Errors in file /home/app/diag/rdbms/sandy04/SANDY/trace/SANDY_ora_59972.trc: ORA-01111: name for data file 30 is unknown - rename to correct file ORA-01110: data file 30: '/home/app/product/11.2.0/db_1/dbs/UNNAMED00030' ORA-01157: cannot identify/lock data file 30 - see DBWR trace file ORA-01111: name for data file 30 is unknown - rename to correct file ORA-01110: data file 30: '/home/app/product/11.2.0/db_1/dbs/UNNAMED00030' Completed standby crash recovery. Reason: The issue arises because the MRP process, while applying archives, creates an unnamed fi...