数据库

最近尝试对博客进行转型，继续发硬核技术帖的同时，会增加一些贴地气的内容。如果说以前使用Hexo、Hugo本质上是为了解决穷的问题，那么现在换回了WordPress是为了解决数据运营的闭环问题。纯静态博客有很多的好处，但是内容和数据成了一个个孤岛，整合起来需要做一定的开发工作，从投入产出来看，换用WordPress是一个比较具有性价比的选择，虽然它很重，有些地方又很ugly，响应速度会慢一些，但是它的生态提供的扩展能力和业务连续性，目前找不到替代品。 ...

其实这已经是PowerDNS集群系统第二次落地了。第一次是在私有的混合云上部署，设计时采用了云上为主、边缘为辅的结构，结合BGP AnyCast+ECMP和PowerDNS官方推荐的架构解决了DNS的高可用、就近查询和负载均衡的问题，上线后一个季度运行正常，还算是挺稳定的。本次，PowerDNS的集群架构将在北京理工大学珠海学院条件装备处落地，为全校提供统一的DNS服务，替换掉老的勉强能用的DNS系统。 ...

坑有点多… 由于我是自己手动编译的zabbix，因此很多配置不能按照官方文档来，要进行一定修改 首先我的zabbix的路径为/usr/local/zabbix 按照官方给的文档的说法：https://www.zabbix.com/integrations/mysql，我需要把template_db_mysql.conf复制到zabbix_agentd.d目录中去，需要特别注意的是，配置文件默认是不引用这个目录中的配置文件的，要手动打开引用。 ...

使用Splunk作为日志分析平台，当Enterprise授权到期后将会没有用户管理功能，页面打开将会直接进入控制台，这无疑是比较操蛋的一个问题。针对这个问题，可以使用nginx进行反向代理加上验证解决 本文只讨论基础认证（用户名和密码），并且没有部署ssl证书，如有想用ssl证书做客户端验证，还请看我早一段时间发的文章 ...

直接贴service cat > /etc/systemd/system/etcd.service <<EOF [Unit] Description=etcd After=network.target [Service] User=etcd Group=etcd ExecStart=/data/etcd/etcd-v3.3.18-linux-amd64/etcd -name bs-etcd -data-dir /data/etcd/db -listen-peer-urls "http://192.168.100.133:2379" -advertise-client-urls "http://192.168.100.133:2380" ExecStartPre=/usr/bin/chown etcd:etcd /data/etcd -R PermissionsStartOnly=true Type=notify Restart=on-failure RestartSec=20 # file size LimitFSIZE=infinity # cpu time LimitCPU=infinity # virtual memory size LimitAS=infinity # open files LimitNOFILE=64000 # processes/threads LimitNPROC=64000 # locked memory LimitMEMLOCK=infinity # total threads (user+kernel) TasksMax=infinity TasksAccounting=false [Install] WantedBy=multi-user.target EOF 目录位置和结构如下 [root@BS-OTHSER etcd]# pwd /data/etcd [root@BS-OTHSER etcd]# tree -a . ├── db │ └── member │ ├── snap │ │ └── db │ └── wal │ └── 0000000000000000-0000000000000000.wal ├── etc ├── etcd-v3.3.18-linux-amd64 │ ├── Documentation │ │ ├── benchmarks │ │ │ ├── etcd-2-1-0-alpha-benchmarks.md │ │ │ ├── etcd-2-2-0-benchmarks.md │ │ │ ├── etcd-2-2-0-rc-benchmarks.md │ │ │ ├── etcd-2-2-0-rc-memory-benchmarks.md │ │ │ ├── etcd-3-demo-benchmarks.md │ │ │ ├── etcd-3-watch-memory-benchmark.md │ │ │ ├── etcd-storage-memory-benchmark.md │ │ │ └── _index.md │ │ ├── branch_management.md │ │ ├── demo.md │ │ ├── dev-guide │ │ │ ├── api_concurrency_reference_v3.md │ │ │ ├── api_grpc_gateway.md │ │ │ ├── api_reference_v3.md │ │ │ ├── apispec │ │ │ │ └── swagger │ │ │ │ ├── rpc.swagger.json │ │ │ │ ├── v3election.swagger.json │ │ │ │ └── v3lock.swagger.json │ │ │ ├── experimental_apis.md │ │ │ ├── grpc_naming.md │ │ │ ├── _index.md │ │ │ ├── interacting_v3.md │ │ │ ├── limit.md │ │ │ └── local_cluster.md │ │ ├── dev-internal │ │ │ ├── discovery_protocol.md │ │ │ ├── logging.md │ │ │ └── release.md │ │ ├── dl_build.md │ │ ├── faq.md │ │ ├── _index.md │ │ ├── integrations.md │ │ ├── learning │ │ │ ├── api_guarantees.md │ │ │ ├── api.md │ │ │ ├── auth_design.md │ │ │ ├── client-architecture.md │ │ │ ├── client-feature-matrix.md │ │ │ ├── data_model.md │ │ │ ├── glossary.md │ │ │ ├── _index.md │ │ │ ├── learner.md │ │ │ └── why.md │ │ ├── metrics.md │ │ ├── op-guide │ │ │ ├── authentication.md │ │ │ ├── clustering.md │ │ │ ├── configuration.md │ │ │ ├── container.md │ │ │ ├── etcd3_alert.rules │ │ │ ├── etcd3_alert.rules.yml │ │ │ ├── etcd-sample-grafana.png │ │ │ ├── failures.md │ │ │ ├── gateway.md │ │ │ ├── grafana.json │ │ │ ├── grpc_proxy.md │ │ │ ├── hardware.md │ │ │ ├── _index.md │ │ │ ├── maintenance.md │ │ │ ├── monitoring.md │ │ │ ├── performance.md │ │ │ ├── recovery.md │ │ │ ├── runtime-configuration.md │ │ │ ├── runtime-reconf-design.md │ │ │ ├── security.md │ │ │ ├── supported-platform.md │ │ │ ├── v2-migration.md │ │ │ └── versioning.md │ │ ├── platforms │ │ │ ├── aws.md │ │ │ ├── container-linux-systemd.md │ │ │ ├── freebsd.md │ │ │ └── _index.md │ │ ├── production-users.md │ │ ├── README.md -> docs.md │ │ ├── reporting_bugs.md │ │ ├── rfc │ │ │ └── _index.md │ │ ├── tuning.md │ │ └── upgrades │ │ ├── _index.md │ │ ├── upgrade_3_0.md │ │ ├── upgrade_3_1.md │ │ ├── upgrade_3_2.md │ │ ├── upgrade_3_3.md │ │ ├── upgrade_3_5.md │ │ └── upgrading-etcd.md │ ├── etcd │ ├── etcdctl │ ├── README-etcdctl.md │ ├── README.md │ └── READMEv2-etcdctl.md └── etcd-v3.3.18-linux-amd64.tar.gz 17 directories, 87 files 新建用户 ...

业务需要，数据库使用了MongoDB集群，集群状态全部正常，但是压测发现总是有一些问题，需要特别关注问题所在 集群当前总共有4个节点，同机房内1主1副1仲裁，跨机房还有1个冷备节点。昨天进行压力测试时发现主节点直接出现死机的情况，还好做压力测试时对所有终端的数据进行了同步录屏，相关记录还可以重新回放出来继续看 ...

重配节点权重，从而设置最低权重的节点为冷备节点（跨机房同步使用，要避免切成主节点），而配置读写分离可以加快某一节点上的数据查询速度~ 本篇文章分为两部分，分别为节点权重和读写分离 注意 新增新节点到副本集中需要先在各个节点增加hosts记录，私有dns域的除外~ ...

研发需要，部署MongoDB的一主一副一仲裁集群，用于解锁对事务的支持，顺带提供高可用。同时，还会一同部署一备份节点和一内存缓存节点，备份节点为数据提供冷备，使用LUN快照，保障数据异常时还有机会进行回滚；内存节点用于加速查询速度。 ...

嗯，正如标题中所讲的一样 前言 作为强迫症的我并不喜欢用Repo中的东西，于是我决定手动编译MariaDB以进行集群（一主一从）。此处我直接将MariaDB编译安装在容器（Fedora 30）中，完成编译后commit再复制出一个新的实例部署从数据库（相当于热备，应该也可以用作异地容灾）。 ...