Mariadb 服务器如果只看这几个字可能有人觉得它就是装个数据库而已但实际上真上手做的时候坑一点不少从二进制包怎么选、root密码怎么设、字符集时区怎么配到国产操作系统上服务怎么拉起来、忘了密码怎么救每一步都可能卡住半天。这篇就把我在Linux服务器上部署MariaDB的整套流程、踩过的坑、用下来的心得一次性倒出来希望能帮你少走点弯路。1. 为什么选MariaDB从MySQL到MariaDB的演进与定位在开始动手之前先花两分钟聊清楚为什么是MariaDB这个决定会影响后面所有的配置思路。MariaDB是MySQL的一个分支由MySQL的创始人Monty Widenius主导开发目的是保持MySQL的开源精神同时提供更强的性能和更多的存储引擎选择。它完全兼容MySQL的协议和SQL语法所以你在MySQL上写的SQL、用的驱动、做的备份脚本迁移到MariaDB几乎不用改。很多人问MySQL和MariaDB到底选哪个我个人的判断标准很简单如果是全新项目又没有强绑定Oracle生态的依赖直接用MariaDB是更省心的选择——它是Linux各主流发行版默认带的数据库CentOS、Ubuntu、银河麒麟这些系统的软件源里都有现成的包安装方便再者它的社区版就是完全开源的没有MySQL那种企业版收费、社区版阉割的纠结。尤其是你在做国产化适配或者云服务器选型的时候MariaDB在ARM架构下的编译和兼容性往往比MySQL更顺滑。从技术演进上看MariaDB 10.5之后把原来的MyISAM引擎彻底换成了Aria崩溃恢复能力强了不少10.6之后还引入了Oracle兼容模式能把一些PL/SQL语法跑起来。这些特性对实际业务来说意味着更稳的写性能和更少的数据损坏风险。我建议的搭配是中小型业务、日志系统、内部的CMS后台直接用MariaDB如果你需要复杂窗口函数、JSON操作、地理空间查询这些高级特性MariaDB 10.5也都能扛住。选型定了之后接下来就要进入正题怎么把服务器上的MariaDB装好、配好、跑起来。2. 安装部署方案二进制安装与系统包管理的取舍2.1 二进制安装从源码包到可运行的完整步骤很多场景下你会遇到这台机器是内网的、连不了外网yum源或者需要指定版本、不想用系统源里的旧版本这时候二进制包就是最稳的方式。所谓的二进制安装就是官方已经帮你把编译好的可执行文件打成tar.gz包你只需要解压、初始化、启动就行不需要自己编译源码省去了gcc、make这些依赖的折腾。官网下载页面会有很多版本选的时候注意三个点一是系统架构x86_64还是aarch64二是glibc版本一般选glibc_2.17这种兼容性最好的三是存储引擎默认的打包就带InnoDB、Aria、MyRocks这些不用专门选。我习惯把包解压到 /opt/mariadb 底下目录结构干净后续升级也好处理# 创建数据库专用用户 groupadd mysql useradd -r -g mysql -s /sbin/nologin mysql # 解压到指定目录 mkdir -p /opt tar -zxvf mariadb-10.11.6-linux-systemd-x86_64.tar.gz -C /opt mv /opt/mariadb-10.11.6-linux-systemd-x86_64 /opt/mariadb # 创建数据目录和日志目录 mkdir -p /opt/mariadb/data chown -R mysql:mysql /opt/mariadb这里有两个细节容易出错一是一定要建独立的系统用户跑数据库绝对不能用root。数据库进程用root启动的话一旦有漏洞被利用黑客直接就是root权限风险太大了。二是数据目录不要建在 /opt 底下生产环境我会挂一块独立的磁盘到 /data/mysql避免系统盘满了导致数据库直接挂掉。如果服务器上只有一块盘那至少也要把数据目录放在父级目录权限控制更严格的位置。解压完成之后还不能直接启动需要先初始化系统数据库这一步会创建mysql.user权限表、系统表等元数据cd /opt/mariadb ./scripts/mariadb-install-db --usermysql --basedir/opt/mariadb --datadir/data/mysql如果执行时提示缺少libaio依赖直接安装yum install -y libaio # CentOS/麒麟系列 apt install -y libaio1 # Ubuntu/Debian系列初始化成功后数据目录下会生成mysql、performance_schema等子目录这时候就可以准备启动了。不过在启动之前推荐先建好配置文件。2.2 系统包管理yum/apt/麒麟的快速装法如果你的机器能联网我其实更推荐用系统自带的包管理器装省事且后续yum update能自动升级。CentOS系默认的yum源已经包含MariaDB直接yum install -y mariadb-server mariadb-clientUbuntu底细的系统apt update apt install -y mariadb-server mariadb-client做国产化适配的时候经常碰到银河麒麟系统它分ARM版和x86版底层是基于CentOS或者Debian的我自己碰过的麒麟V10CentOS系直接用yum就能装麒麟V10Debian系则用apt两个都验证过。如果你在麒麟系统上出现装上了但起不来的情况后面第4章我会专门讲排查思路。这里要特别提醒用包管理器装好的MariaDB会自动注册systemd服务服务名叫mariadb。二进制包装好后systemd服务要自己写后面章节我会给出模板。装完之后先不要急着start先看配置文件确认路径和参数再拉起来。2.3 配置文件规划my.cnf的核心参数逻辑安装方式不同配置文件路径也会不一样。yum/apt装的默认配置文件在 /etc/my.cnf里面通常会引入 /etc/my.cnf.d/ 目录下的所有cnf文件二进制包则建议直接在 /opt/mariadb/my.cnf 写一份并指定启动参数。我习惯把所有自定义配置集中在 /etc/my.cnf.d/server.cnf 里方便管理。一个初始可跑的最小配置是这样的[mysqld] datadir/data/mysql socket/var/lib/mysql/mysql.sock port3306 character-set-serverutf8mb4 collation-serverutf8mb4_unicode_ci innodb_buffer_pool_size1G max_connections300 explicit_defaults_for_timestamptrue字符集这块一定要提前设好。如果启动之后再改字符集已经创建的表结构不会自动变很容易出现中文乱码。utf8mb4不是UTF-8的超集MySQL/MariaDB当年那个utf8实际是utf8mb3最多3字节emoji存不进去所以新项目无脑用utf8mb4就行。innodb_buffer_pool_size 这个参数是InnoDB缓存池大小建议设置为服务器物理内存的50%~70%左右。如果是4G内存的云服务器设2G没问题如果是16G内存设8~10G。设太大会导致内存不足触发OOM设太小则性能上不来这个参数值得我们花时间根据机器规格去调整。3. 初始化配置从root密码到生产级参数调优3.1 root密码设置三条不同路径的取舍逻辑MariaDB刚装好的状态root用户通常只有本机能连而且默认是空密码或者用unix_socket插件认证也就是说你在Linux的root用户下直接执行mysql就能进入。这个状态在内部测试时很爽但只要是台正经服务器第一步就必须给root设置强密码。第一条路径用官方安全脚本。yum安装后直接执行mariadb-secure-installation脚本会一路问你设置root密码是否删除匿名用户是否禁止root远程登录是否删除test数据库全部选y就行。这条路径最省事适合快速初始化。第二条路径手动SQL修改。如果你用二进制包装的脚本不一定带那就直接进数据库改ALTER USER rootlocalhost IDENTIFIED BY StrongPssw0rd123; FLUSH PRIVILEGES;第三条路径重置密码。把密码忘了的情况需要用skip-grant-tables模式跳过权限验证启动这个放到第4章详细讲因为操作起来有顺序要求搞错了会把自己锁在门外。密码强度我的建议是至少12位包含大小写字母、数字、符号且不要用生日、公司名这类容易被猜的词。服务器上其他业务账号不要复用root密码权限也尽量按最小化原则给——比如某个应用只需要操作一个库就只给这个库的增删改查权限而不要甩手一个all privileges。3.2 用户与访问控制本地访问和远程访问的边界数据库搭好了总不能让业务程序也去用root连这时候就要建业务专用账号。创建账号和授权分开两条SQLCREATE USER app_userlocalhost IDENTIFIED BY AppUserPass2024; CREATE USER app_user192.168.10.% IDENTIFIED BY AppUserPass2024; GRANT SELECT, INSERT, UPDATE, DELETE ON myapp_db.* TO app_userlocalhost; GRANT SELECT, INSERT, UPDATE, DELETE ON myapp_db.* TO app_user192.168.10.%; FLUSH PRIVILEGES;注意这里的 host 部分localhost 表示只能从本机连192.168.10.% 表示允许192.168.10网段的机器连。如果你图省事把 host 写成 % 表示允许所有IP连那相当于把数据库暴露在公网上风险极高绝对不建议在公网服务器上这么干。访问控制方面还有两个地方容易栽跟头一是 bind-address 参数默认MariaDB只监听127.0.0.1也就是说外部机器根本ping不通3306端口需要改为 0.0.0.0 才能对外提供数据库服务二是防火墙云服务器在安全组规则里要放行3306端口本机防火墙用firewall-cmd --add-port3306/tcp --permanent或者 ufw allow 3306/tcp 放行。这两个地方是远程连接失败的三大元凶之一。3.3 时区设置服务器时间不对带来的连锁问题热搜词里专门有服务器时区数据库和服务器时区不统一最直接的后果就是程序写入的时间和你本地看到的时间差了几个小时尤其是做订单、日志、定时任务的时候时间错乱会直接导致数据不可信。Linux系统层面先把时区改成Asia/Shanghaitimedatectl set-timezone Asia/Shanghai然后在数据库配置里显式指定[mysqld] default-time-zone08:00改完配置记得重启数据库。这里有个细节MariaDB启动时读系统时区如果系统时区没改对就算default-time-zone设了08:00某些时间函数依然会返回UTC时间。我建议系统时区、数据库时区、应用代码时区三者都改成同一套不要想着我数据库用UTC程序里再转这种思路只会带来无休止的换算麻烦。4. 启动管理、日常运维与常见问题排查4.1 systemd 服务管理与开机自启配置yum装的系统会自动帮你生成systemd服务文件直接就能用systemctl start mariadb systemctl enable mariadb systemctl status mariadb如果你用的是二进制包那就需要自己手动写service文件。在 /etc/systemd/system/mariadb.service 里填入[Unit] DescriptionMariaDB database server Afternetwork.target [Service] Typesimple Usermysql Groupmysql ExecStart/opt/mariadb/bin/mariadbd --defaults-file/opt/mariadb/my.cnf Restarton-failure LimitNOFILE65535 [Install] WantedBymulti-user.target写完后执行systemctl daemon-reload systemctl start mariadb systemctl enable mariadb注意ExecStart那一行这里指定了--defaults-file参数否则mariadbd起来后会去读系统默认路径的配置文件很可能找不到我们自定义的datadir路径导致启动报错。LimitNOFILE这个参数也很关键默认进程文件描述符限制是1024数据库连接一多就不够用了还要在配置文件里加上 open_files_limit65535 配合。启动验证这一步别偷懒直接跑一个查询看看版本和当前时间mysql -uroot -p -e SELECT VERSION(); SELECT NOW();如果输出的版本是你想要的当前时间也是本地时区说明服务状态基本正常。接下来就可以去建业务库导数据了。4.2 启动失败的常见原因排查速查我把这段时间运维中实际遇到过的启动问题整理成一张表按概率从高到低排每个都附解决方案现象根本原因解决方法启动后立即退出日志报Permission denied数据目录属主不对chown -R mysql:mysql /data/mysql启动超时日志报Address already in use3306端口被占用netstat -tlnp | grep 3306释放端口或改配置初始化时报Cant open file mysqllibaio动态库缺失yum install -y libaio连接时报Cant connect through socketsocket文件路径不一致确认配置文件里socket路径与客户端访问路径一致systemctl start卡住不动磁盘IO异常或数据目录损坏检查 dmesg 日志、磁盘空间必要时从备份恢复麒麟系统下yum装完启动失败SELinux拦截或依赖冲突设setenforce 0临时测试确认后调整SELinux策略排查的统一入口是日志文件。MariaDB的日志默认输出到数据目录下的*.err文件比如 /data/mysql/db-server.err也可以关注 /var/log/mariadb/mariadb.log看具体配置。遇到启动失败第一步永远是tail -50 /data/mysql/*.err日志会直接告诉你哪个环节出了错比瞎猜有效率得多。4.3 忘记root密码的急救流程这个场景迟早会遇到尤其是服务器移交或者长时间没维护之后。救急原理是跳过权限验证启动数据库然后进系统把密码改回来。步骤一以skip-grant-tables模式启动。systemctl stop mariadb然后直接手动前台启动sudo -u mysql /opt/mariadb/bin/mariadbd --datadir/data/mysql --skip-grant-tables 网络上这个例子有更精细的最新变体但从原理上讲只要能进入跳过权限检查的数据库进程即可。注意这里必须加上 --skip-networking 参数防止远程也绕过权限登录sudo -u mysql /opt/mariadb/bin/mariadbd --datadir/data/mysql --skip-grant-tables --skip-networking 步骤二无密码连接并重设root密码。mysql -uroot成功进入后执行FLUSH PRIVILEGES; ALTER USER rootlocalhost IDENTIFIED BY NewStrongPass123; FLUSH PRIVILEGES;步骤三杀掉手动启动的进程然后恢复正常模式启动。mysqladmin -uroot -p shutdown systemctl start mariadb这里有个血泪教训如果你不执行第一步的FLUSH PRIVILEGES就直接去ALTER USER会出现Table mysql.user is corrupted之类的报错。原因是在skip-grant-tables模式下权限表是直接读取的没有加载到内存必须先手动刷新一次才能正常修改。4.4 连接数打满与性能瓶颈的快速定位服务器跑业务一段时间后最常出现的一个问题是连接数过多。MariaDB默认 max_connections151一旦应用连接池配置不当或者有慢SQL长时间占用连接就会报 Too many connections 错误。排查思路我建议从两步走。第一步看当前连接情况SHOW PROCESSLIST;这个命令会列出所有活跃连接重点关注 Time 特别久的、State 为 Locked 的会话多半是有什么SQL卡住了。第二步看连接来源统计SELECT user, host, db, COUNT(*) FROM information_schema.processlist GROUP BY user, host, db;如果是单个应用连接数过多检查应用连接池的最大大小设置不要盲目调大数据库端的max_connections因为MAX值不设上限的话Tomcat或Java应用真的能把你服务器内存打穿。合理的策略是应用连接池上限设置40~50左右数据库端max_connections调成300左右二者留出余量就够了。慢SQL是导致连接被打满的另一个常见原因。开启慢查询日志定位那些执行时间超过1秒的查询[mysqld] slow_query_log1 slow_query_log_file/data/mysql/slow-query.log long_query_time1日志文件会越来越大线上就需要用日志清理工具或定期truncate建议配置轮转计划或者交给日志系统统一收集。慢SQL一旦定位出来常规手段是加索引、改写SQL、拆分事务这些都值得专门开一篇来写。5. 备份恢复、监控告警与安全加固要点5.1 逻辑备份与物理备份的组合策略数据库运行起来之后备份就不是一个可以拖延的计划了。我个人常用的备份方案是两种互补逻辑备份做定期的全量数据导出物理备份做周期性的文件快照或者二进制日志增量。逻辑备份用mariadb-dump旧称mysqldumpmariadb-dump -uroot -p --single-transaction --routines --triggers --events myapp_db myapp_db_$(date %F).sql--single-transaction 是InnoDB表必须加的它可以保证备份期间数据一致性不会锁表业务不用停顿。每天凌晨做一次保留最近7天备份。物理备份比逻辑备份更重量级适合做时间点恢复PITR。具体做法是定期将数据目录打成tar包同时确保binlog日志开启并定期归档[mysqld] log_bin/data/mysql/bin_log/binlog binlog_formatrowbinlog是增量恢复的关键。比如说昨天晚上12点做完全量备份今天下午3点数据库误删了一张表你能把备份恢复到昨晚12点的状态再通过binlog把12点到3点之间的事务重放到误删操作之前那一刻数据损失几乎为零。这一步需要你理解binlog文件和时间戳用法理论容错率高但误删恢复从来都是一个综合工程很难保证100%覆盖所有场景。5.2 日常监控看哪些指标才不会惊慌监控数据库不需要一上来就上Prometheus那套重型全家桶先把最核心的指标盯住就够了。我用一条SQL就能看到服务器当前的健康状态SHOW GLOBAL STATUS LIKE Threads_connected; SHOW GLOBAL STATUS LIKE Innodb_buffer_pool_reads; SHOW GLOBAL STATUS LIKE Innodb_buffer_pool_read_requests; SHOW GLOBAL STATUS LIKE Max_used_connections;Threads_connected 对应当前连接数Max_used_connections 是历史最大连接数Innodb_buffer_pool_read_requests 是在缓冲池中读到的次数Innodb_buffer_pool_reads 是磁盘读次数。两个buffer指标一除就能算出缓冲池命中率低于95%说明 buffer pool 太小要调大。磁盘空间监控也很重要数据目录所在的磁盘分区如果满了整个数据库会变成只读状态业务直接瘫痪。我用系统定时任务每分钟检查一次df -h /data | awk NR2 {if ($50 85) print disk warning} | mail -s DB Disk opsexample.com当然正规运维更建议接入Zabbix或者PrometheusAlertmanager给CPU、内存、磁盘、连接数分别设置告警阈值。数据库这东西等你发现慢的时候通常已经快挂了能早一分钟告警就早一分钟止损。5.3 安全加固最小权限、网络隔离和SSL连接安全配置应该从安装那一天就开始做而不是等出了事再补。具体的加固项可以从下面几个思路入手。第一清理默认账号和过度授权DELETE FROM mysql.user WHERE user IN (, root) AND host NOT IN (localhost, 127.0.0.1, ::1); FLUSH PRIVILEGES;匿名用户和允许root从外部连接这两个安全隐患通常安全脚本会自动处理但手动安装场景容易漏掉。第二开启SSL加密连接。公网直连数据库的场景传输的数据是明文还是密文差别很大。生成自签名证书然后在配置里开启[mysqld] ssl-ca/etc/mysql/ssl/ca.pem ssl-cert/etc/mysql/ssl/server-cert.pem ssl-key/etc/mysql/ssl/server-key.pem require_secure_transportON开启后客户端连接地址就要加上ssl参数mysql -uroot -p --ssl-modeREQUIRED。走内网的时候机房内部流量倒是可以不强制SSL毕竟硬件链路是可控的。第三网络层隔离比什么防护都有效。应用服务器和数据库服务器应该放到同一个内网网段数据库的3306端口不要暴露在公网IP上。云环境里就用安全组物理环境就用防火墙规则。如果一定要公网访问那就必须配IP白名单和SSL这两样缺一不可。补充开源运维组件与脚本化的联动思路热搜词里还有开源的服务器维护软件数据库运维这块我亲身验证过一套免费又稳定的组合Prometheus mysqld_exporter Grafana。mysqld_exporter 是开源的数据库指标采集器用正常的监控账号连接数据库不断读取状态变量Prometheus负责存储和告警规则Grafana里导入现成的MySQL Dashboard面板就能看到漂亮的实时图表。整套东西从零到部署完成熟练的话一个下午就能搞定。监控账号不需要太多权限给 PROCESS、REPLICATION CLIENT、SELECT 这三个全局权限就够了CREATE USER monitorlocalhost IDENTIFIED BY MonitorOnlyPass123; GRANT PROCESS, REPLICATION CLIENT, SELECT ON *.* TO monitorlocalhost; FLUSH PRIVILEGES;这套联动思路的好处是数据库连接数突然飙升、缓冲池命中率跌破阈值、主从复制延迟超过10秒都会自动触发告警推送到钉钉或者企业微信。服务器时代的运维拼的就是早发现、早处理告警推送这个环节绝对是投产比最高的投入。把MariaDB跑稳的一点心得文章写到这里核心的部署、配置、排障流程都过了一遍。最后分享一条我自己的原则数据库不要折腾要稳定。 这句话展开讲就是能用发行版自带版本就别自己编译源码能用系统标准路径就别搞花里胡哨的自定义目录能用InnoDB默认隔离级别就跑业务别为了性能去调成READ-COMMITTED之外的东西。MariaDB本身是个非常成熟的软件绝大多数问题都是使用者自己引入的不必要的复杂性造成的。安装方式也好、参数配置也好这篇文章里的每一项选择背后都有一个理由——安全考虑、性能考量或者可维护性的平衡。你在实际操作中完全可以按照自己服务器的资源和使用场景再调整。但有一条是不变的数据库上线前备份恢复演练至少做一遍密码和权限配置至少按最小权限来一遍时区和字符集这种基础项至少确认一遍。这三遍做完你的MariaDB服务器基本上就稳了。踩过几次坑之后我越来越觉得数据库服务器运维不是说要用多高深的技术而是把基础的事情做扎实权限收敛、时区统一、备份落地、日志可查。能把这些基本功全部做到位已经要比很多线上事故频发的环境好出一大截了。
