Mysql安装/命令行操作/日志简介/主从同步

• Docker安装MYSQL

docker run -itd --name mysql-name --network net-bridge-name --network-alias mysql-net-alias-name -p 3306:3306 -e MYSQL_ROOT_PASSWORD=****** mysql

-i：(interactive mode): 保持STDIN开放，即使没有连接。这允许你与容器进行交互，例如通过命令行
-t：(分配一个伪终端或TTY): 为容器分配一个伪终端或终端，这样你可以像在常规终端中那样与容器进行交互。
-d：在后台运行容器，并打印出容器的ID或名称
–network：指定容器加入的docker网络
–network-alias：在bridge网络中定义的别名

进入容器名为mysql的容器命令：docker exec -it mysql /bin/bash

忘记mysql的密码可以通过以下方式

由于这里设置的root密码是通过环境变量所以执行命令：docker inspect 容器名(mysql) 可以看到容器的信息，找到节点Config.Env 就有配置的变量名

• 配置文件查看
  MySQL的配置文件一般叫 my.cnf 或 my.ini

查询配置文件路径,这里的 . 表示当前目录及其子目录
find . -name 'my.cnf'
只知道文件部分名，可以先查文件全名
ls -R . | grep 'my.cn'

• 数据库操作

登录mysql数据库
> mysql -u root -p
Enter password:

查询数据库表时，sql语句中需要指明数据库，且数据库需要用反引号标识,最后需要用分号结束
mysql> SELECT * FROM `database-name`.table_name;

查询数据库变量
mysql> SHOW VARIABLES;
mysql> SHOW BARIABLES LIKE 'log'; #模糊查询

• 日志
  部分日志可以在数据库表中查询

错误日志：记录所有MySQL服务器启动、运行或停止时出现的问题。
log_error = ‘/var/log/mysql/error.log’;

查询日志：general query log 记录所有MySQL服务器接收的客户端请求。
general_log = 1;
general_log_file = ‘/var/log/mysql/query.log’;

慢查询日志：slow query log
slow_query_log = 1;
slow_query_log_file = ‘/var/log/mysql/slow-query.log’;
设置慢查询阈值(秒)：SET GLOBAL long_query_time = 2;

二进制日志：binary log 记录影响数据库数据变更的所有操作，用于复制和数据恢复。
log_bin = ‘/var/log/mysql/binlog’;
设置二进制日志保留天数: expire_logs_days = 7;

回滚日志：undo log
innodb_log_files_in_group = 2
innodb_log_file_size = 50M

事务日志：redo log
innodb_log_files_in_group = 2
innodb_log_file_size = 50M

中继日志：relay log 在MySQL复制中，从服务器用来记录从主服务器接收的数据变更。
由mysql自动管理

• Mysql主从配置

主数据库

配置文件修改my.cnf或my.ini (my.cnf主要用于Linux和Unix系统,my.ini用于Windows系统)
#数据库服务器ID必须唯一与从库区分
server-id=1
#启用二进制日志，并指定日志前缀mysql-bin
log-bin=mysql-bin
# 日志数据格式推荐使用ROW格式，也可以选择MIXED或STATEMENT
binlog-format=ROW  

ROW：记录了每一行被修改的数据具体内容，包括修改前后的数据
优点：确保了数据的一致性
缺点：由于记录了每一行数据的变更，导致日志体量大、IO开销大

STATEMENT：只记录sql本身
优点：日志体量小
缺点：可能会导致数据不一致，如sql中存在时间函数和随机函数，在不同的环境下值存在不一致，导致主从数据不一致

‌MIXED：ROW和STATEMENT的结合，mysql根据sql语句的具体情况自动选择合适的ROW或STATEMENT模式，确定性的sql用STATEMENT,非确定性或复杂sql用ROW
优点：保证了数据一致性，又减小了日志体量和IO开销

问题：既然MIXED会自动选择合适的模式为何推荐使用ROW
解惑：(1) MIXED可能存在某些情况下选择了STATEMENT而导致了数据的不一致，(2) 由于MIXED需要在解析优化sql后做额外的逻辑判断用那种模式，这导致在高并发场景下就存在性能问题，而ROW不需要解析优化。(3) ROW模式下的日志格式简单易于调试和解读，MIXED相对会复杂些 （4）版本和工具对ROW模式更好的支持和兼容

为从库创建访问主库的账号并授权复制权限

-- 创建账号
mysql> CREATE USER 'new_user'@'%' IDENTIFIED BY 'request_password';
-- 复制授权: REPLICATION SLAVE
mysql> GRANT REPLICATION SLAVE ON database_name.* TO 'new_user'@'%';
-- 刷新权限
mysql> FLUSH PRIVILEGES;

new_user和request_password表示访问时的账号密码
%是通配符表示允许账号通过任何IP访问主库，这里需要将%替换为从库的IP，既是安全性的考虑，也减少主库压力防止其它不必要或恶意的访问
database_name.* 表示 database_name数据库下的所有表

从数据库

配置文件修改
#数据库服务器ID，区别于主库
server-id=2  
#设置从库中继日志前缀(可选)
relay-log=mysql-relay-bin 
#如果要将从服务器作为其他服务器的主服务器，则启用此选项,默认不启用，防止修改了从库，导致主从不一致
log-slave-updates=0 
#只允许从服务器接收复制的数据，不允许直接写入
read-only=1

连接主库并设置主从

mysql> CHANGE MASTER TO MASTER_HOST='主服务器IP',MASTER_USER='账号',MASTER_PASSWORD='密码',MASTER_LOG_FILE='mysql-bin.000001',MASTER_LOG_POS=123456;

其中MASTER_LOG_FILE和MASTER_LOG_POS指定主从开始同步的文件和位置，当不设置时会从主服务器的第一个binlog文件开始。
所以在故障恢复等情况下是很有必要的

从主库获取MASTER_LOG_FILE和MASTER_LOG_POS值

--锁定所有表，防止新的写入
mysql> FLUSH TABLES WITH READ LOCK; 
-- 获取当前的日志文件名和位置，对应的字段为File和Position
mysql> SHOW MASTER STATUS;  
-- 解锁表
mysql> UNLOCK TABLES;  

启动从库复制进程

mysql> START SLAVE;

检查从服务器状态

--  Slave_IO_Running 和 Slave_SQL_Running 都显示为 Yes，并且没有错误信息。
mysql> SHOW SLAVE STATUS\G