当前位置：首页 > news >正文

作图网站都有哪些如何卸载和安装wordpress

news 2025/10/12 3:15:40

作图网站都有哪些,如何卸载和安装wordpress,苏州网站建设托管,长安公司网站制作Binlog（Binary Log） Binlog（Binary Log）是 MySQL 数据库的核心日志之一，用于记录数据库的逻辑操作。简单来说，它像一台摄像机，忠实记录所有对数据库进行修改的 SQL 语句（如 INSERT/…

Binlog（Binary Log）

Binlog（Binary Log）是 MySQL 数据库的核心日志之一，用于记录数据库的逻辑操作。简单来说，它像一台摄像机，忠实记录所有对数据库进行修改的 SQL 语句（如 INSERT/UPDATE/DELETE）或表结构变更（如 CREATE/ALTER）等操作。

核心特性

逻辑日志

记录的是 SQL 语句的原始逻辑（例如：UPDATE users SET age=20 WHERE id=1;），而非底层数据页的物理修改细节（这是 redo log 的特性）。

持久化存储

Binlog 以文件形式存储在磁盘中，不会随数据库重启而丢失，生命周期由配置决定（可长期保存）。

可追溯性

通过解析 binlog 文件，可以精确还原数据库的历史变更过程。

核心用途

主从复制（Replication）

主库将 binlog 发送给从库，从库重放这些日志以实现数据同步，是 MySQL 高可用架构的基础。

数据恢复

当误删数据或数据库故障时，可通过 binlog + 定期备份实现时间点恢复（Point-in-Time Recovery）。

Binlog 格式（3种类型）

格式	特点	示例
STATEMENT	记录原始 SQL 语句	UPDATE orders SET create_time = NOW() WHERE status = 'unpaid';
ROW	记录每行数据的变化细节（如修改前后的整行数据	记录每行数据修改前后的完整值（例如：id=1 的用户 balance 从 500 → 400）
MIXED	混合模式，根据 SQL 语句自动选择 STATEMENT 或 ROW 格式	对于 INSERT INTO payments VALUES (UUID(), 100); MIXED 模式会自动切到 ROW 格式，避免主键冲突。

二、主从复制

是数据库系统中实现数据高可用、读写分离、负载均衡的核心技术。其核心思想是通过将主库（Master）的数据变更异步/同步复制到从库（Slave），使从库与主库保持数据一致。

核心原理

主库（Master）

记录所有数据变更到 Binlog（二进制日志）
通过 Binlog Dump 线程向从库发送日志事件

从库（Slave）

I/O 线程：连接主库，接收 Binlog 并写入本地 Relay Log（中继日志）
SQL 线程：读取 Relay Log，重放 SQL 事件，实现数据同步

配置步骤（以 MySQL 为例）

1. 主库配置


# my.cnf
[mysqld]
server_id = 1               # 唯一ID
log_bin = mysql-bin         # 开启Binlog
binlog_format = ROW         # 推荐ROW模式

2. 创建复制账号

CREATE USER 'repl'@'%' IDENTIFIED BY 'your_password';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';

3. 从库配置

# my.cnf
[mysqld]
server_id = 2               # 唯一ID，不能与主库冲突
relay_log = mysql-relay-bin # 开启Relay Log
read_only = ON              # 从库设为只读（防误操作）

4. 启动复制

-- 从库执行
CHANGE MASTER TOMASTER_HOST = '主库IP',MASTER_USER = 'repl',MASTER_PASSWORD = 'your_password',MASTER_LOG_FILE = 'mysql-bin.000001', -- 主库当前Binlog文件名MASTER_LOG_POS = 154;                 -- 主库当前Binlog位置START SLAVE;  -- 启动复制

三、GTID

GTID（全局事务标识符）是 MySQL 主从复制中用于唯一标识事务的机制，它解决了传统复制依赖 binlog 文件名和位置的痛点。

GTID 核心组成

每个 GTID 格式为： GTID = source_id:transaction_id

- source_id：产生事务的服务器唯一标识（通常是 server_uuid）
- transaction_id：事务序列号，单调递增（如 1-100 表示第1到第100个事务）

示例： 3E11FA47-71CA-11E1-9E33-C80AA9429562:1-5 表示该事务来自 server_uuid 为 3E11FA47... 的服务器，事务序列号为1到5。

GTID 核心优势

传统复制痛点	GTID 解决方案
主从切换需手动指定 binlog 位置	自动追踪事务，无需关心文件位置
难以确定事务是否在所有从库执行	通过 GTID 集合全局唯一标识事务状态
级联复制拓扑管理复杂	事务路径清晰，支持任意拓扑结构

GTID 启用配置

修改 my.cnf

   [mysqld]gtid_mode = ON                 # 启用 GTIDenforce_gtid_consistency = ON  # 强制 GTID 一致性log_bin = mysql-bin            # 必须开启 binlogserver_id = 1                  # 服务器唯一 ID