Tag: db

  • How I deleted 530 million records from a large MySQL database table hitting nearly 200GB

    Came across the need to perform maintenance on a MySQL database which holds millions of records, we needed to remove all data which was 2+ years old which involved deleting around 530 million records from a very large table, hitting nearly 200GB.

    Problem

    Due to the size of the database and transaction logs / table locking, it wasn’t possible to do a bulk delete such as

    This caused the database to become very unresponsive and after hours of running eventually failed with table locking issues. This is because DELETE operations are very costly due to all the checking and transactional logging involved.

    I tried creating a second duplicate table and inserting the data we wanted to keep into this table, however this involved turning the system offline during this process, after some testing locally, was going to take roughly 90 hours to complete, this was not an option.

    Solution

    I created a MySQL stored procedure, which allowed me to split the DELETE query into chunks, stored procedures are not handled as a single transaction, this allowed each delete operation to complete and move onto the next chunk, slowly deleting the data from the active table whilst the table is still in use.

    As it was costly to query against the table or use LIMIT & OFFSET, which would take around 10 minutes to return results, it was not possible to use these as part of the procedure if we wanted this process to complete in a timely manner.

    As the ID where incremental, I was able to query the table until I found the largest ID I was willing to delete up to, in my case it was 530,000,000.

    The below stored procedure is what I ended up using to solve the issue.

    It is recommended a professional under takes these actions, please always backup existing data / files / configs.

  • Laravel, time zones and carbon

    Laravel defaults to storing all dates in UTC format, this is highly recommended as UTC time never changes unlike other time zones which have daylight savings. It is best practice to store and read dates in UTC, and then convert UTC to your required time zone for the user interface.

    Great article below of a good way to implement time zones using Carbon within your Laravel app.

    https://andrew.cool/blog/49/Easy-timezones-in-Laravel-with-Carbon

  • Repairing damaged or crashed MySQL tables

    Always remember, regular backups of your databases are best practice, in the event the below fail, backups may be the only method you have to restore a working table or database.

    Damaged or crashed MySQL tables due to an unsafe server shut downs, disk space limits or general MySQL failures? You will normally see something along the lines of “marked as crashed and should be repaired when using LOCK TABLES” within your MySQL log files.

    MySQL has a number of tools to try and repair crashed / damaged tables. Log into your server as root and run the following commands. Replacing “/var/lib/mysql/” with the location of your DB files.

    Check what tables need repaired:

    myisamchk –check /var/lib/mysql/*/*.MYI

    Try a safe recovery:

    myisamchk –safe-recover /var/lib/mysql/*/*.MYI

    Try a normal recovery (if safe recovery fails):

    myisamchk –recover /var/lib/mysql/*/*.MYI

    Try a force recovery (as a final last step):

    myisamchk –safe-recover –extend-check –force /var/lib/mysql/*/*.MYI

    or:

    myisamchk –recover –extend-check –force /var/lib/mysql/*/*.MYI