Linux 系统调优
一、优化文件打开数 为了防止失控的进程破坏系统的性能，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...
使用MinIO当blog图床
自从写博客后发现 markdown 图片处理困难，存到本地每次存个文档都得建个目录，云厂商的对象存储收费，后来研究了下 MinIO，感觉当图床不错 1 部署 minio wget http://dl.minio.org.cn/server/minio/release/linux-amd64/minio chmod +x minio mv 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`--...
如何优雅的使用PostgreSQL主从
此文档以进程方式部署 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 安装 PostgreSQL 12sudo yuminstall -y...
如何优雅的使用MySQL主从
主从同步分析参考: 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 搭建 mysql 125.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-10.noarch.rpm 这里注意下,mysql 版本 5.6: I/O thread...
MySQL主从同步分析
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...
Orchestrator与MySQL的高可用
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...
如何优雅的备份MySQL数据
1 备份锁分析 XtraBackup 备份的时候出现锁问题，然后查文档有以下几个方案，每种方案都有优势与不足，根据需求选择，我们使用的是 kill 其他阻塞线程方案 1.1 死锁现象及原因: 1.2 Flush table with read lock XtraBackup 可以实现 Innodb 表的无锁备份，但是一个数据库中，即使所有的业务表都是 innodb 表，但是还存在一些 MySQL 系统库下的 user 表等，均是 myisam 表（MySQL 8.0 均替换为 InnoDB），同时备份过程需要获取 Binlog 文件名和位置，也要保证表定义文件的一致性，所以从整个实例的角度，即使用 XtraBackup 还是有一段时间需要执行 Flush table with read lock 全局锁的，会对用户访问产生影响，同时由于 Flush table with read lock 的一些特殊性，如果稍不注意，可能会对用户访问数据库产生致命影响。 1.3 使用 MTS： slave_preserve_commit_order=1 时，relay-log...
MariaDB生产级别高可用
此方案只适合 mariadb,MySQL 请不要使用此方案 此方案实现功能 自动故障转移 自动故障恢复,如 master 宕掉后重启自动加入集群成为 slave 读写分离 binlog 日志备份与解析 1 环境规划 ip 端口 名称 binlog 路径 10.0.16.12 10.2.41 11 Master /var/log/mysql 10.0.16.12 10.2.41 12 Slave1 /var/log/mysql 10.0.16.12 10.2.41 13 Slave2 /var/log/mysql 10.0.16.12 10.2.41 14 Slave3 /var/log/mysql 10.0.16.12 6.1.4-1 5506 maxscale /data/maxscale1_binlog 10.0.16.12 6.1.4-1 5507 maxscale /data/maxscale2_binlog 10.0.16.12 1.20.2 3306 nginx 2 简单部署 mariadb 2.1...
ingress常用配置
发现大部分架构都是 nginx 代理后端，挂载前端提供服务。但是放到 k8s 还得单独启动个 nginx 部署前端，这就造成两个问题。 1：配置复杂，每加有新的服务调用，不仅要改 ingress，web 服务的 nginx 配置文件也需要修改。 2：访问复杂，变成了 dns>ingress>web>后端 经过修改，我们的架构图 1 正常需要添加的参数 123456789nginx.ingress.kubernetes.io/client-body-buffer-size: 2mnginx.ingress.kubernetes.io/enable-access-log: 'true'nginx.ingress.kubernetes.io/enable-cors: 'true'nginx.ingress.kubernetes.io/proxy-body-size: 10mnginx.ingress.kubernetes.io/proxy-buffer-size:...
Nginx Ingress常用配置
发现大部分架构都是 nginx 代理后端，挂载前端提供服务。但是放到 k8s 还得单独启动个 nginx 部署前端，这就造成两个问题。 1：配置复杂，每加有新的服务调用，不仅要改 ingress，web 服务的 nginx 配置文件也需要修改。 2：访问复杂，变成了 dns>ingress>web>后端 经过修改，我们的架构图 1 正常需要添加的参数 123456789nginx.ingress.kubernetes.io/client-body-buffer-size: 2mnginx.ingress.kubernetes.io/enable-access-log: 'true'nginx.ingress.kubernetes.io/enable-cors: 'true'nginx.ingress.kubernetes.io/proxy-body-size: 10mnginx.ingress.kubernetes.io/proxy-buffer-size:...
