部署 Glusterfs 参考: glusterfs Kubernetes 通过 StorageClass 访问 heketi,heketi 负责管理 Glusterfs 集群 1 heketi1.1 安装1.1.1 配置 yum 源并安装1234567cat /etc/yum.repos.d/glusterfs.repo[glusterfs]name=glusterfsbaseurl=https://buildlogs.centos.org/centos/7/storage/x86_64/gluster-9/enabled=1gpgcheck=0yum install -y heketi heketi-client 1.1.2 配置文件 这个一般只需要修改用户名与 key 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354cat /etc/heketi/heketi.json{ "_port_comment& ...

1 创建一个 ceph pool 创建存储池1.1 ceph 集群请看这里：RookCeph安装123ceph osd pool create cephfs_data 128ceph osd pool set-quota cephfs_data max_bytes $((20 * 1024 * 1024 * 1024)) #20G的存储池cephfs pool init cephfs_data 1.2 查看集群状态123456789101112131415161718ceph -s cluster: id: xxxxxxxxx-xxxx-11ec-bfb9-67a0f564e0d6 health: HEALTH_OK services: mon: 3 daemons, quorum ceph01,ceph02,ceph03 (age 7d) mgr: ceph01.pjvndt(active, since 7d), standbys: ceph02.injlkl, ceph03.sulrio mds: 1/1 daemons up, 2 st ...

1 准备工作部署集群参考: RookCeph安装 1.1 创建一个 ceph pool 创建存储池123ceph osd pool create rbd 128ceph osd pool set-quota rbd max_bytes $((20 * 1024 * 1024 * 1024)) #20G的存储池rbd pool init rbd 1.1.1 查看集群状态 csi-config-map.yaml 会用到 123456789101112131415161718ceph -s cluster: id: xxxxxxx-67a0f564e0d6 health: HEALTH_OK services: mon: 3 daemons, quorum ceph01,ceph02,ceph03 (age 7d) mgr: ceph01.pjvndt(active, since 7d), standbys: ceph02.injlkl, ceph03.sulrio mds: 1/1 daemons up, 2 standby osd: 8 ...

1 sqlite3系统自带的版本太低需要升级 1.1 编译12345wget https://sqlite.org/2022/sqlite-autoconf-3380000.tar.gztar -zxvf sqlite-autoconf-3380000.tar.gzcd sqlite-autoconf-3380000./configure --prefix=/usr/localmake && make install 1.2 替换1234567mv /usr/bin/sqlite3 /usr/bin/sqlite3_oldln -s /usr/local/bin/sqlite3 /usr/bin/sqlite3echo "/usr/local/lib" > /etc/ld.so.conf.d/sqlite3.confldconfigsqlite3 -version3.38.0 2022-02-22 18:58:40 40fa792d359f84c3b9e9d6623743e1a59826274e221df1bde8f47086968a1bab ...

一、优化文件打开数 为了防止失控的进程破坏系统的性能，Unix和Linux会跟踪进程使用的大部分资源，会对用户及系统管理员进行资源限制，例如控制某个用户打开文件最大数、对某个用户打开进程数进行限制等，一般限制手段包括：软限制和硬限制，一般这两者的值都是设置相等的。 12345678910# 每个用户打开文件的数量,"*"表示所有用户。如果改成root就表示对root用户的限制。cat /etc/security/limits.conf......... 末尾添加* soft noproc 65535* hard noproc 65535* soft nofile 65535* hard nofile 65535# 整个系统打开文件对数量cat /proc/sys/fs/file-max2621440 二、内核参数优化 Linux /proc/sys目录下存放着多数内核的参数，并且可以在系统运行时进行更改，一般重新启动机器就会失效,/proc/sys下内核文件与配置文件/etc&#x ...

自从写博客后发现 markdown 图片处理困难，存到本地每次存个文档都得建个目录，云厂商的对象存储收费，后来研究了下 MinIO，感觉当图床不错 1 部署 miniowget http://dl.minio.org.cn/server/minio/release/linux-amd64/miniochmod +x miniomv minio /usr/bin 1.1 编写启动脚本cat /opt/minio/start.sh 1234#!/bin/shexport MINIO_ACCESS_KEY=用户名export MINIO_SECRET_KEY=密码nohup /usr/bin/minio server /mnt/data --address "域名:9000" --console-address ":9001" > /opt/minio/minio.log 2>&1 & 1.2 添加证书,名字不能改tree /root/.minio 12345/root/.minio`-- certs |-- ...

主从同步分析参考: MySQL 主从同步分析 | 云原生基站 因为我们环境 MySQL 是 5.6 的,主从同步还是会有延迟的,5.7 会解决这问题 1 环境规划 ip 端口 名称 10.1.1.1 5.6.51 3306 Master /var/lib/mysql/binlog/ 10.1.1.2 5.6.51 3306 Slave1 /var/lib/mysql/binlog/ 10.1.1.3 5.6.51 3306 Slave2 /var/lib/mysql/binlog/ 2 搭建 mysql125.6yum源:rpm -Uvh http://dev.mysql.com/get/mysql-community-release-el7-5.noarch.rpm5.7yum源:rpm -Uvh http://dev.mysql.com/get/mysql57-community-release-el7- ...

此文档以进程方式部署 docker 或 k8s 参考PostDock 单节点安装1 docker 安装1docker run -d --name=postgres13 -p 5432:5432 -v /data/postgres-data/postgres13:/var/lib/postgresql/data -e POSTGRES_PASSWORD=qweasd postgres:13.9 -c shared_buffers=2560MB -c max_connections=5000 2 yum 源12# 最新命令参考: https://www.postgresql.org/download/linux/redhat/sudo yum install -y https://download.postgresql.org/pub/repos/yum/reporpms/EL-7-x86_64/pgdg-redhat-repo-latest.noarch.rpm 3 安装 PostgreSQL12sudo yuminstall -y postgresql13-server 4 ...

1 同步原理 slave 从 master 节点复制数据主要有 4 个步骤 1,master 对所有 DDL 和 DML 产生的日志写入 binlog 2, Slave 的 IO Thread 线程从主库中 bin log 中读取取日志。类似 tailf 命令 3, Slave 的 IO Thread 线程把读取的日志放到 relay-bin 文件里,如果不放到文件里,SQL Thread 线程重放过慢的会导致丢数据 4, Slave 的 SQL Thread 线程将主库的 DDL 和 DML 操作事件在 slave 中重放 1,2,3 步骤都是顺序读写,在不考虑网络延迟的情况下,slave 不会产生延迟.但是第 4 步 DML 和 DDL 的 IO 操作是随即的,不是顺序的.不考虑硬件,主从复制延迟主要在这里 1.1 随机读写与顺序读写区别如下是内存块,每个块最大存 4k 1k 2k 4k 3k 3k 我如果删除 1k 这个块的数据再加个 2k 的块的数据 如果是顺序读写 1k 的数据删除掉之后就丢掉,新加数据直接在后面的块添加数据 2k 4k ...

1 方案设计 参考文档(GitHub 的 MySQL 高可用性实践分享), 技术细节: 当主库宕掉的时候,orchestrator 不仅会每隔 InstancePollSeconds(默认五秒)监测主库，也会检测从库(通过 select round(absolute_lag) from meta.heartbeat_view”检查,配置文件里自定义语句)。比如，要诊断出主库挂了的情况，必须满足以下两个条件：orchestrator 联系不到主库。登录到主库对应的从库，从库也连不上主库。 使用伪 GTID 的时候需要建一个表专门存放 orchestrator 生成的 GTID,每次写入 binlog 的话会把这个表的 GTID 写进去,如下图 orchestrator 没有将错误按时间来进行分类，而是按复制拓扑服务器本身进行分类。当所有的从库都连不上主库的时候，说明复制拓扑被破坏，进行故障转移。 通过 show slave hosts;命令发现实例,然后根据 host:port 访问实例 高可用有两种方式,一直是多个实例一个数据库,只有数据库没宕掉就能正常使用.一直是奇数实例 ...