apt 无法解决这个问题；dpkg 解决了这个问题。
请记住这一点，因为接下来我会讲述我最近尝试卸载 MariaDB 的经历。在反复尝试和重新配置 Galera 集群之后，我决定从头开始。
我自然而然地这么做了：
apt -y remove mariadb-server apt -y purge mariadb-server
但是，执行此操作后，我发现 /etc/mysql 中仍然残留许多文件。
以下是 apt-get(8) 手册页的内容：
消除 删除操作与安装操作相同，区别在于删除操作是移除软件包而不是安装软件包。 请注意，删除软件包后，其配置文件仍会保留在系统中。如果出现加号，则表示已删除软件包。 符号附加到软件包名称（中间没有空格），标识的软件包 将会安装而不是移除。 清除 purge 与 remove 的区别在于，purge 会移除并清除软件包（任何软件包）。 配置文件也会被删除）。
现在想象一下以下场景：
- 全新安装的 Debian 11
- 你安装了 mariadb-server，但没有修改任何配置文件，然后立即将其关闭。
- 您需要使用 apt remove 和 apt purge 命令清除服务器上所有与 MariaDB/MySQL 相关的软件包。
读完那段手册摘录后，你难道不会得出结论：按照这些步骤操作后，系统上所有与 MariaDB 相关的配置文件都会被删除吗？
并非如此。
更糟糕的是，在简单地删除 `/etc/mysql` 文件并执行 `apt-install mariadb-server` 之后，`/etc/mysql` 中许多重要的配置文件都丢失了，导致实例无法启动。我原本以为我的删除/清除/安装命令能让我回到最初状态，但结果并非如此——我最终进入了一个支离破碎的世界。
那么，如何彻底移除一个软件包，让 apt 知道你现在处于空环境，并在重新安装时自动安装配置文件呢？根据我的经验，仅仅依靠 apt 是不够的，你还需要借助一些更强大的工具。
以下是整个过程——或者如果您只想了解答案，可以直接跳到红色部分。
我们从创世之初开始
或者至少这是我第一次以 root 用户身份登录。我用的是Vultr 服务器（你或许可以免费获得一个），当然，操作系统之王是 Debian。需要说明的是，这是一个 Vultr 模板，而 Vultr 的服务商有时会出些小问题，不过 apt 设置是正常的。
所以，我在这台新安装的虚拟机上执行的第一个命令就是：
# dpkg -l | grep mariadb #
正如预期的那样，只是确认一下。现在：
# apt 更新 <yadda yadda> # cat /etc/debian_version 11.6
是的，我现在正在等 Bookworm 内核，不过我也试过直接运行 `as/bullseye/bookworm/g` 命令，重启后内核更新到新版本后运行正常。但我还没有进行全面的测试。
回到正题。Vultr 会在首次启动时执行 apt upgrade，所以无需这样做。接下来是 MariaDB：
# apt -y install mariadb-server <通常情况> # ls -l /etc/mysql/ 总共24 drwxr-xr-x 2 root root 4096 3月 18 19:51 conf.d -rw------- 1 root root 544 3月 18 19:51 debian.cnf -rwxr-xr-x 1 root root 1731 2022 年 2 月 18 日 debian-start -rw-r--r-- 1 root root 1126 Feb 18 2022 mariadb.cnf drwxr-xr-x 2 root root 4096 3月 18 19:51 mariadb.conf.d lrwxrwxrwx 1 root root 24 3月 18 19:51 my.cnf -> /etc/alternatives/my.cnf -rw-r--r-- 1 root root 839 2021年2月8日 my.cnf.fallback
这些是安装时的配置文件。MariaDB 会自动启动。我个人更喜欢 Debian 默认禁用 MariaDB。虽然可以使用 systemd 预设来阻止这种行为，但我们以后再讨论。这里我们只需：
systemctl stop mariadb
那么，都安装了哪些软件包呢？
# dpkg -l | grep maria ii libdbd-mariadb-perl 1.21-3 amd64 Perl5 MariaDB/MySQL 数据库接口 ii libmariadb3:amd64 1:10.5.18-0+deb11u1 amd64 MariaDB 数据库客户端库 ii mariadb-client-10.5 1:10.5.18-0+deb11u1 amd64 MariaDB 数据库客户端二进制文件 ii mariadb-client-core-10.5 1:10.5.18-0+deb11u1 amd64 MariaDB 数据库核心客户端二进制文件 ii mariadb-common 1:10.5.18-0+deb11u1 所有 MariaDB 通用配置文件 ii mariadb-server 1:10.5.18-0+deb11u1 所有 MariaDB 数据库服务器（取决于最新版本的元软件包） ii mariadb-server-10.5 1:10.5.18-0+deb11u1 amd64 MariaDB 数据库服务器二进制文件 ii mariadb-server-core-10.5 1:10.5.18-0+deb11u1 amd64 MariaDB 数据库核心服务器文件 # dpkg -l | grep mysql ii mysql-common 5.8+1.0.7 所有 MySQL 数据库公共文件，例如 /etc/mysql/my.cnf
好吧，让我们采取焦土政策：
apt -y remove mariadb-server mariadb-client mariadb-common mysql-common apt -y purge mariadb-server mariadb-client mariadb-common mysql-common
所以现在一切都干净得像山涧溪流一样了，对吧？已经全部移除和清除了？我们从未动过任何配置文件。
我们被骗了，被愚弄了，被蒙蔽了。
# ls -l /etc/mysql/ 总共12 -rw------- 1 root root 544 3月 18 19:51 debian.cnf -rwxr-xr-x 1 root root 1731 2022 年 2 月 18 日 debian-start drwxr-xr-x 2 root root 4096 3月 18 19:51 mariadb.conf.d
所以它保留了一些配置文件？dpkg 表示：
# dpkg -l | grep maria rc mariadb-client-10.5 1:10.5.18-0+deb11u1 amd64 MariaDB 数据库客户端二进制文件 rc mariadb-server-10.5 1:10.5.18-0+deb11u1 amd64 MariaDB 数据库服务器二进制文件 # dpkg -l | grep mysql #
rc = “已移除但配置文件仍然存在”。
所以，purge 命令也有不同的版本。apt勉强解决了这个问题；dpkg 则彻底解决了它。
# dpkg --purge mariadb-server-10.5
哦，现在事情变得真实起来了……
当然，这样做会删除您的数据库文件，如果您在意这些文件，请注意这一点。
请注意，使用 dpkg 时，需要使用包含版本号的完整软件包名称（“mariadb-server-10.5”）。
为了做到万无一失：
# dpkg --purge mariadb-client-10.5
现在：
# ls -l /etc/mysql ls：无法访问“/etc/mysql”：没有该文件或目录 # ls -l /var/lib/mysql ls：无法访问“/var/lib/mysql”：没有该文件或目录 # apt -y install mariadb-server <是啊，是啊，我们都看到了。> # ls -l /etc/mysql 总共24 drwxr-xr-x 2 root root 4096 3月 18 20:00 conf.d -rw------- 1 root root 544 3月 18 20:00 debian.cnf -rwxr-xr-x 1 root root 1731 2022 年 2 月 18 日 debian-start -rw-r--r-- 1 root root 1126 Feb 18 2022 mariadb.cnf drwxr-xr-x 2 root root 4096 3月 18日 20:00 mariadb.conf.d lrwxrwxrwx 1 root root 24 Mar 18 20:00 my.cnf -> /etc/alternatives/my.cnf -rw-r--r-- 1 root root 839 2021年2月8日 my.cnf.fallback
我不知道为什么事情会变成这样，但这就是彻底摧毁他们的办法。
