Hexo的NexT主题可以天然支持友链，即在NexT主题的配置文件_config.yml中有一个# Blog rolls块，可以添加友链，然后在左边栏的底端会显示它们。但这样的问题在于边栏的空间有限，友链比较多的话会影响布局，而且分散主题。于是考虑单独创建一个友链页面，搜索发现已经有成型的方案，大体思路与
# Hexo添加自定义分类菜单项并定制页面布局
一样，增加菜单项和友链模版，再修改主页模板。这样做可以解决问题，但是不够优雅，属于侵入式的定制（直接修改了主题文件模板），但绝大多数人都采用了这种方案 :-)。
最近一直想简化每篇博客的永久链接，现在的永久链接大概长这样：
/2021/03/21/migrateopsmanager.en/
希望能把中间的日期去掉，变成这样：
/migrateopsmanager.en/
原因在于短链接更作为标识更为合理，而URL上带有日期字符串并没有实际的用处，除非重名的博客太多。但这不可能发生，因为所有博客都写在source/_post文件夹，博客重名会引起文件名冲突。
生产环境有个SQL Server云数据库，花钱不少，性能却很差。最近发现跑一些并不太复杂的存储过程却需要好几分钟。其中一个常用的存储过程是将几张表通过一个键值关联并返回结果，这几张表都在千万级大小。分析了下执行计划，发现index seek花去了90%以上的时间，进而发现这些表的索引碎片化都极为严重。由于这个老DB几经易手，没人知道这些表和存储过程是做什么的，于是需要手动分析这些表的schema和存储过程所依赖的表。基于这些结果再对索引重建提升性能。下面就是用来分析DB的一些重要Query。
.NET中使用MongoDB非常简单，一般来说可以直接使用BsonDocument，也可以使用定义好的数据类型对文档进行CRUD操作。本文通过实例对比一下两种方式的优劣，通常，通过强类型Collection对文档进行操作更为便捷。
MongoDB事务是个很好的功能，但对于高并发场景下的多文档事务，写冲突难以避免。一个写冲突的实例:
Exception: Command update failed: Encountered error from mongodb.svc.cluster.local:27017 during a transaction :: caused by :: WriteConflict error: this operation conflicted with another operation. Please retry your operation or multi-document transaction..
在一个分片MongoDB集群上并发执行transaction时遇到许多MongoCommandException错误: code 251, codename NoSuchTransaction:
Command find failed: cannot continue txnId 4 for session 38604515-2584-45a5-a17a-5eb5d34ea6c4 - = with txnId 5. Command find failed: cannot continue txnId 4 for session 38604515-2584-45a5-a17a-5eb5d34ea6c4 - = with txnId 6. Command insert failed: cannot continue txnId 31 for session 3ed7ea61-eae1-440f-8d95-b6e066b35b69 - = with txnId 34.
Sharded cluster是MongoDB部署中最复杂的形式，因为Sharded cluster的组件较多，部署步骤也更为繁琐。在实际部署中还有几个部署ReplicaSet时没遇到的证书和TLS问题。阅读本文前，强烈建议先阅读 创建用户数据库(replicaset) 作为基础。
本文为系列第五部分，用生成的自签名证书打开userdb的TLS和AUTH，并且完成userdb的公网域名访问。
整个系列：
开始之前，先解释下部署中不同层面的TLS加密：Secure Connections to Ops Manager, Secure Connections to Application Database, Secure Connections to MongoDB Deployments，我们需要的是最后一个，Enable TLS to MongoDB Deployments。而且这个配置不能直接通过界面完成，因为需要将生成的自签名证书“上传”到userdb的每个server上，然后才能配置这些证书所在的路径。
本文为系列第四部分，相对独立，先生成一个自签名CA证书，然后生成MongoDB各个server证书。
整个系列：
自签名证书不推荐在生产环境使用，虽然它可以保证通信过程中的加密，但不能避免中间人攻击。Public Key Infrastructure (PKI)相关的内容也不在本文的讨论范围，这里假设读者对PKI已有基本的认识。
本文为系列第三部分，使用第二部分创建好的userdb可以从公网访问，方法是通过Kubernetes Service暴露userdb pod到公网上。
本文为系列第二部分，使用第一部分安装好的MongoDB Ops Manager创建用户数据库。
整个系列：
所谓的Application Database是MongoDB Ops Manager的后端DB，并不能用来存放用户数据，所以我们需要用Ops Manager创建用户数据库。使用Ops Manager创建的MongoDB叫做Deployment，注意此Deployment是MongoDB Deployment，与kubernetes的Deployment不是一码事。
MongoDB的入门配置门槛（单机）很低，但如果想达到生产环境的要求则有些技术含量。生产环境的配置要求包括Replica Set、Sharding、Scale up/down、数据备份、通信加密TLS和指标实时监控等。配置这些功能比较繁琐，有不少坑要踩。那么有没有好用的工具帮我们配置和管理呢？
如果你按官方文档 Configure mongod and mongos for TLS/SSL 配置MongoDB证书，可能会遇到如下问题：
| |
or
最近遇到个数据库表设计的问题，一张账号表，业务逻辑存在一列唯一accountId，是否还要在数据库表中加一列自增int作为主键？这应该是实践中普遍存在的问题，于是研究了下推荐做法。
对一个DBA来说监控mysql服务器的性能指标是非常重要的。我们可以通过mysqlbench中的Server Status来轻松监测服务器最近一段时间的状态。但是这些指标具体代表了什么含义？比如，Selects per second 和Innodb reads per second的区别是什么？如何评估服务器当前写入的性能？
博客越写越多，将markdown源文件备份到github变得非常重要。github pages要求免费账户的username.github.io必须是public repository。网上主要有两种方案，一个是用hexo-git-backup插件，另一个是在username.github.io上创建另一个分支进行备份。
BBR 是Google 2016年提出的TCP 拥塞控制算法，可以显著地提升Server的吞吐率并降低延迟。在VPS上实测效果非常明显，将VPS的下载速度由10Mbps左右提升至约50Mbps，自动视频质量也由240p升至1080p。
2020-11-28更新： 经过四个多月的肌肉练习（引体向上，核心肌群训练，跑步，羽毛球），肩颈疼痛症状显著缓解，坚持锻炼两个月后，落枕、脖子活动受限的情况基本就没再发生过，现在的情况就更好了。全身性的肌肉训练效果还是很好的，亲测推荐！
硬盘虽然并不值钱，但对于一个强迫症来说，看到莫名其妙地内容占据了好些空间也非常不爽。记录下在Linux中如何发现空间占用大户，以及可以删除什么以缩减使用空间。
为了精简hexo安装的npm modules，用rm -rf node_modules/删除了已安装的包，再npm install把package.json中定义的包安装一遍。结果hexo自动从4.0.0升级到了4.2.1，hexo g时失败。node.js除了hexo外基本不用，npm自然不熟，有些配置是直接抄来的并不知其所以然。而hexo的插件都是由npm管理的，稍微研究了下如何查看这些插件的最新版本和升级它们。