这事儿得从一次深夜加班说起。那天凌晨两点，客户电话打进来，说系统突然卡死，所有通话记录都报错。我登录 FreeSWITCH 后台一看，日志里全是数据库连接超时的提示。那一刻我意识到，用默认的 SQLite 存配置，就像用纸箱装火药——省事是真省事，但随时可能炸得你满地找牙。后来我把数据库换成 PostgreSQL，整个系统才算真正站稳了脚跟。今天就跟大家聊聊，为什么要给 FreeSWITCH 配个正经数据库，以及具体怎么操作。
先说为什么要换数据库。FreeSWITCH 默认用的 SQLite 是文件型数据库，所有数据都保存在一个 .db 文件里。这玩意儿对小规模测试没问题，但一旦并发上来，比如同时处理几百个通话，SQLite 的锁机制就成了瓶颈。写操作排队，读操作也排队，整个系统就像堵在早高峰的二环上。而且 SQLite 不支持网络访问，想远程管理配置、做实时分析？门儿都没有。换成 MySQL 或者 PostgreSQL，这些问题就迎刃而解：多线程并发读写、主从复制、数据备份恢复，甚至可以和你的 Web 系统无缝对接。我见过一个呼叫中心，原来每天凌晨三点死机，换了数据库后，一年没重启过。
接下来要选数据库。FreeSWITCH 官方文档推荐 MySQL 和 PostgreSQL，我个人更倾向 PostgreSQL。原因有三：一是 PostgreSQL 对 JSON 的支持更原生，FreeSWITCH 的配置数据很多是键值对，用 JSON 字段管理起来特别顺手；二是 PostgreSQL 的并发控制比 MySQL 更成熟，高负载下不容易出现死锁；三是 PostgreSQL 自带强大的全文搜索功能，以后想分析通话记录、做报表，直接一条 SQL 就能搞定。当然，MySQL 也不差，如果团队里熟悉 MySQL，完全可以使用。但别再用 SQLite，那是个坑，踩过的人都懂。
配置过程其实不复杂。假设你已经装好了 PostgreSQL，先创建一个数据库和用户。登录到 PostgreSQL 命令行，执行：然后打开 FreeSWITCH 的配置文件，找到 ，里面有个 ，改成：。注意，FreeSWITCH 默认使用 ODBC 驱动，所以需要先装好 psqlODBC。装完驱动后，在 ODBC 配置里添加一个数据源，指向刚才创建的库。随后重启 FreeSWITCH，查看日志里是否出现 “Connected to database successfully”。如果报错，多半是驱动未装好或密码写错了。
数据迁移这一步很关键。FreeSWITCH 的默认 SQLite 文件叫 ，里面存了用户信息、分机配置、路由规则等核心数据。手动重建这些数据几乎不可能，所以要用工具把数据导出来。小技巧是：先停掉 FreeSWITCH，拷贝一份 ，然后用 SQLite 命令行导成 SQL 文件：接着把这个 SQL 文件导入到 PostgreSQL：但要注意，SQLite 和 PostgreSQL 的语法有细微差别，例如自增字段、布尔值的处理等。建议先在测试环境跑一遍，看看有没有报错。如果有，需要手动修改 SQL 文件里的对应语句。比如 SQLite 的 要改成 PostgreSQL 的 或 。这个过程可能需要反复调试，但做一次之后，以后就一劳永逸了。
配置完数据库后，别忘了调整 FreeSWITCH 的参数。数据库连接池大小、超时时间、最大连接数都需要根据业务量来设定。打开 ，找到 ，默认是 20，如果并发高可以调到 50 或 100。还有 ，默认是 300 毫秒（30 秒），建议改成 600，防止慢查询导致连接断开。另外，建议在 PostgreSQL 里使用连接池，例如 PgBouncer，这样能有效管理连接，避免 FreeSWITCH 频繁创建和销毁连接。我见过一个客户，没做连接池，系统跑了一个月后 PostgreSQL 的连接数飙到上千，直接把服务器拖垮了。
日常维护也要跟上。PostgreSQL 不像 SQLite 那么省心，需要定期做 和 来清理死元组、更新统计信息。FreeSWITCH 的日志和 CDR（通话详细记录）表增长很快，建议写个定时脚本，每天凌晨执行一次 ，并把超过 30 天的 CDR 数据归档到历史表。监控方面，可以使用 Prometheus + Grafana 对 PostgreSQL 进行监控，重点关注连接数、查询延迟、死锁次数。一旦发现异常，例如查询延迟超过 100 毫秒，立刻排查。曾经我发现某个表出现全表扫描，原因是 FreeSWITCH 的模块没有加索引，添加索引后查询速度提升了十倍。
说个踩坑经验。有次把数据库从 SQLite 迁到 PostgreSQL 后，发现呼入电话有时会报 “User not found”。排查半天后发现是 FreeSWITCH 的缓存机制在捣鬼。它默认把数据库里的用户信息缓存到内存，缓存过期时间是 3600 秒，也就是说修改 PostgreSQL 中的用户数据后，需要等一个小时才会刷新缓存。解决办法有两种：在 dialplan 中加一行 ，或者手动执行 和 。更彻底的做法是，在用户变更后，通过 Event Socket 向 FreeSWITCH 发送 命令。听起来麻烦，但实际只要写个几十行的脚本就能搞定。
总的来看，给 FreeSWITCH 配上正经数据库，前期多花两三天进行配置和迁移，后期省下的运维时间能翻十倍。别图省事用默认的 SQLite，那玩意儿就像骑自行车上下班——短途没问题，但要跑长途、跑业务，还是得换辆四轮车。PostgreSQL 也好，MySQL 也罢，选一个你熟悉的，认真配置并定期维护。这样 FreeSWITCH 就会像老黄牛一样稳健，你再也不用半夜被电话吵醒了。
