DevOps Technology Stack

Keepalived 日志默认只输出到 /var/log/messages 文件中。由于 /var/log/messages 中记录了系统中其他服务的相关日志，日志内容刷新比较快，不便于观察，这里修改日志存储到一个单独文件中。 注意：修改keepalived日志输出路劲涉及到了重启keepalived服务，线上环境建请合理安排重启时间。 1.配置Keepalived日志输出信息修改 /etc/sysconfig/keepalived 配置文件，把 KEEPALIVED_OPTIONS="-D" 修改为： KEEPALIVED_OPTIONS="-D -d -S 0" 。 $ cat /etc/sysconfig/keepalived # Options for keepalived. See `keepalived --help' output and keepalived(8) and# keepalived.conf(5) man pages for a list of all options. Here are the mos ...

新建 MySQL 用户创建用于刷新日志的 MySQL 账号，并对账号权限加以限制。 > GRANT RELOAD ON *.* TO 'flushlogs_user'@'localhost' IDENTIFIED BY '123456';> FLUSH PRIVILEGES; 刷新 MySQL 慢日志刷新MySQL慢查询日志，慢查询日志类型为 slow # 方式一$ mysqladmin -u$DBUser -P$DBPass -S /data/server/mysql/tmp/mysql.sock flush-logs slow# 方式二$ mysqladmin -u$DBUser -P$DBPass -h $DBHost -P $DBPort flush-logs slow 注意： 在刷新 slow log 前，需要先把文件重命名，否则mysql不会生成新的 slow log 文件。 由于在Linux系统中存在“文件描述符”的概念，即使重命名了 slow log 文件，mysql进程依然会把新产生的 ...

操作场景对于自建数据库 MySQL，在误操作造成数据损坏时，进行数据修复相对来说是比较麻烦的。在公有云上的云数据 MySQL，基本上都会提供数据回档的功能，只需要在控制台简单操作即可。 这里参考了腾讯云数据库的回档方案，结合公司当数据库集群架构以及数据库备份方案制定了较为简单、安全的 MySQL 的回档方案： 此回档方案只支持对数据库或表进行回档操作，回档是基于 数据备份 + 日志备份（binlog），可进行实时数据回档。 自建数据库 MySQL 回档通过定期全量物理热备（这里使用XtraBackup工具进行全备）和 binlog 日志重建，将数据库或表回档到指定时间，期间原有数据库或表的访问不受影响，回档操作会产生新的数据库或表至原实例中。回档完后，在原实例中可以看到原来的数据库或表，以及新建的数据库或表。 XtraBackup 工具使用请参考：《MySQL 备份与恢复》 功能原理回档基于最近一次备份文件 + 对应的 binlog回档到指定时间点。 备份系统每天会从 MySQL 备机导出数据到备份系统。 回档时，首先需要新建一台回档实例，然后从备份系统导出备份数据并导入临时实例（ ...

问题描述由于部署环境有诸多限制，只能在纯内网（无法跟公网互通）环境下安装软件，所以需要把软件包下载下来放在服务器本地进行安装。 系统版本为 CentOS 8.2，使用 createrepo 命令创建 repodata 后，在进行部分软件安装时，会出现 Error: No available modular metadata for modular package 报错，详情如下图： 为解决以上问题，需要安装 modulemd-tools 等软件来生成 modular metadata。所以可以在有网络的相同系统版本的服务器下进行操作，最后将生成好的 repo package 目录打包压缩上传到此服务器，最后配置好repo源即可。   安装 modular metadata 生成工具安装相关依赖$ sudo dnf install gcc gcc-c++ python3 python3-devel python3-createrepo_c python3-libdnf python3-libmodulemd libmodulemd 下载 modulemd-tools 源码包 ...

背景说明在上篇文章 K8S 中使用 Prometheus 监控 JVM (一) 中，我们基于 Kubernetes 的 Service 实现了监控 Pod 中java应用的 JVM 信息。但其实这并不适用于所有的环境，因为在实际环境中并不是所有的 Pod（微服务）都会有自己对应的 Service，所以那些没有使用到 Service 的 Pod 就无法通过上篇文章那种实现来监控 JVM 信息了。现在我们就来解决这个问题。 本篇文章会基于 Pod 控制器的方式来实现 JVM 信息的监控，下面以 Deployment 控制器为例。   操作步骤使用 JMX Exporter 暴露 JVM 监控指标使用 JVM 进程内启动（in-process）方式，启动 JVM 需指定 JMX Exporter 的 jar 包文件和配置文件。jar 包为二进制文件，不便通过 ConfigMap 挂载，建议直接将 JMX Exporter 的 jar 包和配置文件都打包到业务容器镜像中。 这里为了方便演示，jar 包就简单用 hostPath 的方式直接挂载进容器里，配置文件使用 ConfigMap ...

SSL/TLS 握手是在服务器和网站之间建立安全连接的过程。SSL 证书或数字证书因其对网络用户、网站所有者和发布者的安全性而变得流行。他们利用公钥密码术对客户端和网络服务器之间的数据传输进行编码。有各种类型的数字证书，但都服务于相同的过程，为客户端和网络所有者提供安全性。 Web 所有者经常使用SSL 证书来防止黑客入侵。要开始安全连接，客户端和服务器都首先进行 SSL 握手过程，包括身份验证、密钥交换过程等。让我们先从 SSL/TLS 证书开始，了解它们的工作过程。然后我们将解释整个TLS握手过程。   什么是 SSL/TLS？SSL（安全套接字层）是一种标准安全协议，广泛用于保护 Internet 上的通信。SSL 使用非对称加密来保护信息不受攻击者的影响。SSL 证书由受信任的证书颁发机构颁发，以确保没有人（没有正确的编码/解码密钥）可以读取用户和服务器之间共享的数据。 SSL 证书在两个密钥的帮助下进行加密和解密的过程。一个是任何试图与站点建立安全连接的人都可以使用的公钥。另一个密钥是由 Web 服务器隐藏的私钥，用于解密从客户端收到的消息。通过这种方式，在服务器和 ...

操作场景Prometheus 社区开发了 JMX Exporter 用于导出 JVM 的监控指标，以便使用 Prometheus 来采集监控数据。当您的 Java 业务容器化至 Kubernetes 后，可通过本文了解如何使用 Prometheus 与 JMX Exporter 来监控 Java 应用。   JMX Exporter 简介Java Management Extensions，JMX 是管理 Java 的一种扩展框架，JMX Exporter 基于此框架读取 JVM 的运行时状态。JMX Exporter 利用 Java 的 JMX 机制来读取 JVM 运行时的监控数据，然后将其转换为 Prometheus 可辨识的 metrics 格式，以便让 Prometheus 对其进行监控采集。 JMX Exporter 提供启动独立进程及 JVM 进程内启动（in-process）两种方式暴露 JVM 监控指标： 启动独立进程JVM 启动时指定参数，暴露 JMX 的 RMI 接口。JMX Exporter 调用 RMI 获取 JVM 运行时状态数据，转换为 Prom ...

一、环境准备1.1 安装RPM打包、测试必备开发工具$ yum install -y rpm-build rpmlint rpmdevtools 1.2 安装打包、编译所需的依赖软件$ yum install -y gcc gcc-c++ make perl perl-WWW-Curl 二、制作 OpenSSL 的 RPM 包 注意： 切记！不要使用 root 用户来执行打包操作。因为这十分危险，所有二进制文件都会在打包前安装至系统中，因此您应该以普通用户身份打包，以防止系统被破坏。 2.1 配置 rpmbuild 工作目录$ mkdir -p ~/rpmbuild/{BUILD,BUILDROOT,RPMS,SOURCES,SPECS,SRPMS}$ echo "%_topdir %{getenv:HOME}/rpmbuild" > ~/.rpmmacros 2.2 下载源码包到 ~/rpmbuild/SOURCES 目录$ wget -O ~/rpmbuild/SOURCES/openssl-1.1. ...

事故背景​ 线上环境有一个MongoDB副本集，由于是部署在客户那边本地机房，客户误操作把部署副本集的另外2个节点的 VM 给删除了（并且VM已经无法恢复了）。所幸的是还有一个节点存活，登录节点后发现这个节点是 SECONDARY，所以可能会有一部分数据丢失，而且此时已经无法对应用提供读写服务。此时只能停服维护，并对集群进行恢复。 ​ 基于以上问题，下面对副本集恢复操作步鄹进行了记录。 处理思路 对mongodb数据进行备份（防止恢复集群时出现意外导致数据丢失）。 把仅存的 SECONDARY 节点提升为 PRIMARY，删除集群中另外2个不存活的节点，然后重新配置MongoDB副本集。 新部署2个MongoDB节点，并加入到集群中。 等待 PRIMARY 节点数据同步到另外2个新节点后，进行数据验证，结束生产环境维护。 注意： 由于原先的集群中只存有 SECONDARY 节点，PRIMARY 节点已经丢失，所以存在部署数据没同步到 SECONDARY 的可能。但由于PRIMARY节点的VM已经被删，这部分未同步的数据的丢失在所难免，想恢复这部分数据只能 ...

前言Percona XtraBackup（简称PXB）是 Percona 公司开发的一个用于 MySQL 数据库物理热备的备份工具，支持 MySQl（Oracle）、Percona Server 和 MariaDB，并且全部开源，真可谓是业界良心。我们 RDS MySQL 的物理备份就是基于这个工具做的。 项目的 blueprint 和 bug 讨论放在 Launchpad，代码之前也放在 Launchpad，现在已经迁移到 Github 啦，项目更新发布非常快，感兴趣的可以关注 :-) 本文会介绍下备份工具的工作原理，希望对大家有所帮助。   工具集软件包安装完后一共有4个可执行文件，如下： usr├── bin│ ├── innobackupex│ ├── xbcrypt│ ├── xbstream│ └── xtrabackup 其中最主要的是 innobackupex 和 xtrabackup，前者是一个 perl 脚本，后者是 C/C++ 编译的二进制。 xtrabackup 是用来备份 InnoDB 表的，不能备份非 InnoDB 表，和 mys ...