Completely uninstall mysql-server

Posted June 21, 2020 111.2k views
MySQLUbuntu 20.04

Hi there, first of all I need to make some history to tell why am getting to this point.

A few days ago, making a multisite WordPress installation I lost access to database. This I solved it without breaking my head.

Yesterday I got notified that my WordPress was down, but what a surprise, my disk was full (25G). So I follow thees steps to solve that, then I saw that the problem was in /var/lib/mysql with a lot of files binlog.000000 ~100M size. So I delete them all with rm, I don’t know if that was the right way.

Then all the problems start. I try to enter to mysql console, but it is imposible, always get this massage: ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)

I’ve followed this tutorial and many others like this one, but nothing.

The directory /var/run/mysqld/ has owner and permissions drwxr-xr-x 2 mysql mysql 40 Jun 21 09:19. I’ve restarted mysql.service many times, but the mysqld.sock file is not created.

Last thing I did was uninstall mysql-service:

sudo apt remove --purge mysql-server
sudo apt purge mysql-server
sudo apt autoremove
sudo apt autoclean
sudo apt remove dbconfig-mysql

I’ve installed again, but when I try to access to mysql console get the same error again.

My droplet is SO Ubuntu 20.04 and MySQL version 8.0.20. I don’t know if there could be some issues in this latest versions of Ubuntu and MySQL.

I don’t care a lot to lose all my data, be cause it is a new droplet and I have almost nothing there, but I like to fix this problem in the right way.

Thank a lot for your help.

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

Submit an Answer
1 answer

Hi there @themingisprose,

Indeed deleting files directly from your MySQL folder is really not recommended. You can take a look at this guide here on how to delete old MySQL binary files here.

Regarding your current issue. In order to completely get rid of your MySQL installation you could run the following:

  • Make sure MySQL is not running:
  • sudo systemctl stop mysql
  • Then purge all of the MySQL packages:
sudo apt purge mysql-server mysql-client mysql-common mysql-server-core-* mysql-client-core-*
  • Then delete all of the MySQL files:
  • sudo rm -rf /etc/mysql /var/lib/mysql /var/log/mysql
  • Finally clean all packages that are not needed:
  • sudo apt autoremove
  • sudo apt autoclean

Another approach here would be to create a new Droplet and just upload your WordPress files to the new Droplet.

Hope that this helps!

  • Finally it works, thanks a lot. Now I have to do that about binary logs, but what happened that my disk got full in just ten days?

    One more time thanks for your help.

    • Hey @themingisprose,

      No problem at all! Happy to hear that it is all working now.

      Regarding the binary logs, those should only appear if you have MySQL replication configured, is this the case for you?

      If you are using MySQL 5.x, and if you are using MySQL replication, then I would recommend reducing the expire_logs_days value in MySQL.

      If you are using Percona, you could adjust the max_binlog_files number instead.

      Hope that this helps!

      • Hi @bobbyiliev

        About my MySQL configuration, I’ve been following thees steeps, not mush else. I’m a bit new to all of this.

        So, following your tutorial, I found that expire_logs_days is deprecated, but the error message guided me through out the right way.

        mysql> SET GLOBAL expire_logs_days = 3;
        ERROR 3683 (HY000): The option expire_logs_days and binlog_expire_logs_seconds cannot be used together. Please use binlog_expire_logs_seconds to set the expire time (expire_logs_days is deprecated)
        mysql> SET GLOBAL binlog_expire_logs_seconds = 259000;
        Query OK, 0 rows affected (0.00 sec)

        Then added this to my /etc/mysql/my.cnf file. (I don’t have the /etc/my.cnf file):

        binlog_expire_logs_seconds = 259000

        Now on I’ll keep an eye on these files, hopefully they will not cause troubles anymore :)


        by Erika Heidi
        A “LAMP” stack is a group of open-source software that is typically installed together to enable a server to host dynamic websites and web apps. This term is actually an acronym which represents the Linux operating system, with the Apache web server. The site data is stored in a MySQL database, and dynamic content is processed by PHP. In this guide, we will install a LAMP stack on an Ubuntu 20.04 server.
  • Hi @bobbyiliev, @themingisprose
    I’m facing the same issue after received notice of the full disk.

    Instead of reinstalling the MySQL server, is there any other way to fix this error?
    Because I want to keep my database.

    • Hello,

      You can follow the steps on how to delete old binary logs here:

      The mechanisms for cleaning out the binlogs in conjunction with mysql-bin.[index] are:

      • Run the following query to delete specific binary log:
      PURGE BINARY LOGS TO 'binlogname';
      • Or to delete all logs before a specific date:
      PURGE BINARY LOGS BEFORE 'datetimestamp';

      These will clear all binary logs before the binlog or timestamp you just specified.

      For example, if you run

      PURGE BINARY LOGS TO `mysql-bin.000223`;

      This will erase all binary logs before mysql-bin.000223.

      The following will erase all binary logs before midnight 3 days ago:


      If you want to have binlog rotated away automatically and keep 3 days worth, simply set this:

      mysql> SET GLOBAL expire_logs_days = 3;

      Then add this to the MySQL config file:


      And MySQL will delete them logs for you.


      • @bobbyiliev
        Sorry, to be able to run the above queries, the mysql.service must be running. But my mysql.service can not start or restart.
        And, I got a log:

        2021-07-15T05:22:18.515671Z 1 [ERROR] [MY-013183] [InnoDB] Assertion failure: == (file->size * phy_page_size) thread 140570509756160
        InnoDB: We intentionally generate a memory trap.
        InnoDB: Submit a detailed bug report to
        InnoDB: If you get repeated assertion failures or crashes, even
        InnoDB: immediately after the mysqld startup, there may be
        InnoDB: corruption in the InnoDB tablespace. Please refer to
        InnoDB: about forcing recovery.
        05:22:18 UTC - mysqld got signal 6 ;
        Most likely, you have hit a bug, but this error can also be caused by malfunctioning hardware.
        Thread pointer: 0x5592359774f0
        Attempting backtrace. You can use the following information to find out
        where mysqld died. If you see no messages after this, something went
        terribly wrong...
        stack_bottom = 7fd91f4cbd20 thread_stack 0x46000
        /usr/sbin/mysqld(my_print_stacktrace(unsigned char const*, unsigned long)+0x41) [0x55923013b681]
        /usr/sbin/mysqld(handle_fatal_signal+0x31b) [0x55922ef8bf6b]
        /lib/x86_64-linux-gnu/ [0x7fd92c32d3c0]
        /lib/x86_64-linux-gnu/ [0x7fd92b98a18b]
        /lib/x86_64-linux-gnu/ [0x7fd92b969859]
        /usr/sbin/mysqld(+0xea257e) [0x55922ecb557e]
        /usr/sbin/mysqld(fil_tablespace_redo_extend(unsigned char*, unsigned char const*, page_id_t const&, unsigned long, bool)+0x510) [0x5592305ca7f0]
        /usr/sbin/mysqld(+0x24e30e9) [0x5592302f60e9]
        /usr/sbin/mysqld(+0x24e6d7e) [0x5592302f9d7e]
        /usr/sbin/mysqld(recv_recovery_from_checkpoint_start(log_t&, unsigned long)+0x271d) [0x5592302ff9ad]
        /usr/sbin/mysqld(srv_start(bool)+0x206e) [0x55923040166e]
        /usr/sbin/mysqld(+0x2428a9f) [0x55923023ba9f]
        /usr/sbin/mysqld(dd::bootstrap::DDSE_dict_init(THD*, dict_init_mode_t, unsigned int)+0x9e) [0x55922feca17e]
        /usr/sbin/mysqld(dd::upgrade_57::do_pre_checks_and_initialize_dd(THD*)+0x1a9) [0x55923010e8a9]
        /usr/sbin/mysqld(+0x1234016) [0x55922f047016]
        /usr/sbin/mysqld(+0x28dfefa) [0x5592306f2efa]
        /lib/x86_64-linux-gnu/ [0x7fd92c321609]
        /lib/x86_64-linux-gnu/ [0x7fd92ba66293]
        Trying to get some variables.
        Some pointers may be invalid and cause the dump to abort.
        Query (0): is an invalid pointer
        Connection ID (thread ID): 1
        Status: NOT_KILLED
        The manual page at contains
        information that should help you find out what is causing the crash.
        2021-07-15T05:22:19.132303Z 0 [System] [MY-010116] [Server] /usr/sbin/mysqld (mysqld 8.0.25-0ubuntu0.20.04.1) starting as process 978073
        2021-07-15T05:22:19.143788Z 1 [System] [MY-013576] [InnoDB] InnoDB initialization has started.