Mysql 高可用部署实践
mysql主从是如何备份的?
在MySQL主从复制架构下，备份通常需要在主库和从库上分别进行。
- 主库备份：
在主库上进行备份时，可以使用mysqldump等命令生成SQL文件，并将其保存到本地或者远程服务器上。备份过程中需要注意以下几点：
- 备份前需要对正在进行的写操作加锁，以保证数据一致性。
- 如果需要备份所有数据库，可以使用--all-databases选项；如果只需要备份特定的数据库，则需要指定相应的数据库名。
- 备份完成后需要释放加锁。
- 从库备份：
在从库上进行备份时，需要先暂停复制进程，然后再进行备份。备份过程中需要注意以下几点：
- 在备份过程中需要停止复制进程，以避免备份数据出现不一致的情况。
- 同样可以使用mysqldump等命令生成SQL文件，并将其保存到本地或者远程服务器上。
- 备份完成后需要重新启动复制进程，以保证数据同步正常。
需要注意的是，在备份过程中需要保证数据的一致性和完整性。另外，建议采用定期备份和增量备份相结合的方式，以保证数据的及时性和有效性。
mysql主从是如何同步的？
MySQL 主从同步的实现是依赖于二进制日志（binlog）的。主数据库会将所有写操作记录在二进制日志中，这些日志包含了数据库执行的所有操作，包括创建、修改和删除数据等操作。然后从库连接到主库并请求复制二进制日志，主库将二进制日志发送给从库，从库解析这些日志并在本地重放相应的操作。
在主从同步中，主库生成的二进制日志包含了对数据的所有修改，而从库则使用这些日志来更新自己的数据。通过使用二进制日志，从库可以保证它的数据与主库的数据保持一致，并且在主库出现故障时可以快速切换到从库。
因此，binlog 是 MySQL 主从同步的核心机制。当然，在 MySQL 5.7 之后引入的 GTID 技术也可以用于主从同步，并能够更加准确地追踪和处理重复的数据。但是，无论是否使用 GTID，都离不开 binlog 的支持。
mysql redolog：用于事务回滚,
MySQL 中的 redo log（重做日志）是一种用于数据恢复和保护数据的机制。它记录了在事务提交之前对数据库所做的更改操作，以便可以在系统崩溃或意外断电等故障发生时恢复更改。
具体来说，当一个事务执行更新操作时，MySQL 会将这些更新操作写入 redo log 中。redo log 是一个循环性的、固定大小的文件，它采用追加方式记录每个事务的所有修改操作。当事务提交时，redo log 中的更新就被应用到磁盘上的表中，从而实现了数据的持久化。
在 MySQL 中，redo log 的主要作用有两个：
-
数据恢复：如果 MySQL 在执行事务期间崩溃，那么在重新启动时，通过 redo log 中记录的事务操作，MySQL 可以恢复到崩溃前的状态。
-
提高性能：因为将数据从内存写到磁盘是非常耗时的，所以 MySQL 通常会将多个操作合并成一个大的写操作，从而减少磁盘 I/O 操作的次数。redo log 可以帮助 MySQL 实现这一点，因为在事务提交之前，MySQL 可以将多个更新操作写入 redo log 中，然后再批量地写入磁盘，从而提高了性能。
总的来说，redo log 是 MySQL 中非常重要的一个机制，它可以帮助保证数据的安全性和可靠性，并提高系统的性能。
mysql undolog：用于mvc。rc隔离级别，同一事物下每个读都会生成一个reader view。 rr隔离级别，同一事物下每个读都是同一个readerview
MySQL 中的 undo log（回滚日志）是一种用于实现事务的原子性和隔离性的机制。当一个事务更新了数据库中的某些数据，但由于某种原因需要回滚事务时，MySQL 就会用到 undo log。
undo log 记录了在事务执行期间所做的所有修改操作的逆操作，以便可以在撤销事务时恢复原始状态。当一个事务开始时，MySQL 会为这个事务分配一个 undo log，然后在执行每个更新操作时将对应的逆操作写入这个 undo log 中。
在 MySQL 中，undo log 的主要作用有两个：
-
回滚事务：如果事务执行失败或者被回滚，MySQL 就会使用 undo log 恢复数据库的原始状态，保证事务的原子性。
-
实现多版本并发控制：MySQL 支持多版本并发控制（MVCC）机制，其中 undo log 扮演着重要角色。通过 MVCC，MySQL 可以让多个用户同时访问同一张表，而不会相互干扰。当一个用户查询数据时，MySQL 会根据该用户的事务视图（Transaction View）来确定哪些数据是可见的。而事务视图则基于各个事务的 undo log 来构建。
总的来说，undo log 是 MySQL 中非常重要的一个机制，它可以帮助实现事务的原子性和隔离性，支持多版本并发控制，并提高了系统的可靠性和性能。
mysql undolog 和 redolog的区别
MySQL 中的 undo log 和 redo log 是两个不同的日志文件，它们都是 InnoDB 存储引擎实现事务机制所必需的组成部分，但它们的作用和内容有所不同。
- Undo Log（回滚日志）
Undo Log 记录了事务发生之前数据的旧值（“撤销”操作），以便在事务回滚或者系统崩溃时恢复数据。因为 InnoDB 存储引擎使用多版本并发控制（MVCC）来提高并发性能，所以 Undo Log 记录的不仅是事务对数据的修改，还包括数据修改之前的旧值，这些旧值会被用来构建各个事务的视图，以决定哪些数据可以被读取。
- Redo Log（重做日志）
Redo Log 记录了事务对数据的修改（“重放”操作），以便在系统崩溃时可以重新执行这些修改操作，从而保证数据的一致性。InnoDB 存储引擎在执行事务时，会将事务对数据的修改记录在内存中的 Redo Log 缓冲区中，然后定期将缓冲区中的记录刷新到磁盘上的 Redo Log 文件中。如果系统崩溃，MySQL 可以通过 Redo Log 文件恢复到最近一次提交的事务状态，并重新执行 Redo Log 中记录的修改操作，从而保证数据的完整性。
因此，Undo Log 记录了事务之前的状态，用于回滚和 MVCC；而 Redo Log 记录了事务对数据的修改操作，用于恢复数据的一致性。两者都是 MySQL 实现事务机制所必需的组成部分，但它们的作用和内容有所不同。
如图部署主从？
1、主从
2、串联主从
3、多主多从+延时从(做恢复)
如何做到高可用？
如果挂了，通过脚本可以重启或切换mysql实例，但是ip变了，我们还需要动态修改配置，怎么解决呢？比如主从切换
vip ： 虚拟ip