被取消的命令MySQL 之前提供了一个 rename database db_old to db_new 的命令来直接对数据库改名，可能由于实现的功能不完备（比如，这条命令可能是一个超大的事务，或者是由于之前的表很多还是 MyISAM 等），后来的版本直接取消了这条命令。更改数据库名大致上有以下几种方案：
成都创新互联拥有一支富有激情的企业网站制作团队，在互联网网站建设行业深耕10余年，专业且经验丰富。10余年网站优化营销经验，我们已为数千家中小企业提供了网站建设、成都做网站解决方案，按需规划网站，设计满意，售后服务无忧。所有客户皆提供一年免费网站维护!
一、mysqldump 导入导出要说最简单的方法，就是直接用 mysqldump 工具，在旧库导出再往新库导入（最原始、最慢、最容易想到）的方法：旧库 yttdb_old 导出（包含的对象：表、视图、触发器、事件、存储过程、存储函数）
二、改整库的表名利用 MySQL 更改表名的方法来批量把旧库的所有表依次遍历，改名为新库的表。这种方法比第一种要快很多倍，但是没有第一步操作起来那么顺滑，不能一步到位。比如，要把数据库 yttdb_old 改名为 yttdb_new，如果数据库 yttdb_old 里只有磁盘表，那很简单，直接改名即可。或者写个脚本来批量改，非常简单。但是一般旧库里不只有磁盘表，还包含其他各种对象。这时候可以先考虑把旧库的各种对象导出来，完了在逐一改完表名后导进去。
三、历史方案其实在 MySQL 早期还有一种方法。假设 MySQL 部署好了后，所有的 binlog 都有备份，并且二进制日志格式还是 statement 的话，那就可以简单搭建一台从机，让它慢慢追主机到新的库名，等确切要更改旧库的时候，再直接晋升从机为主机即可。这里只需要从机配置一个参数来把旧库指向为新库：replicate-rewrite-db=yttdb_old-yttdb_new不过这种局限性很大，不具备标准化，不推荐。
总结其实针对 MySQL 本身改库名，大致就这么几种方法：
如果数据量小，推荐第一种；
数据量大，则推荐第二种；
数据量巨大，那就非 MySQL 本身能解决的了。
可通过部署第三方 ETL 工具，通过解析 MySQL 二进制日志或其他的方式来把旧库数据直接读取到新库达到改名的目的等等。
数据库内均无数据，关闭主从库的iptables(chkconfig iptables off)。
1、主库配置
修改主库MySQL配置文件/ect/my.cnf：
[mysqld]
log-bin=mysql-bin
server-id=1
#skip-networking
#bind-address
server-id用来标识MySQL数据库，log-bin开启二进制日志，注释掉skip-networking和bind-address。 重启主库MySQL。
2、账号配置
在主库服务器上，新建一个用于同步的账号。
mysql create user 'user'@'%.domain.com' identified by 'password';
mysql grant repliction slave on *.* to 'user'@'%.domain.com';
新建的用户user@%.domain.com，赋予slave权限。
3、主库状态
mysql show master status;
+------------------+-----------+--------------+------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+-----------+--------------+------------------+
| mysql-bin.000009 | 480 | | |
+------------------+-----------+--------------+------------------+
1 row in set (0.00 sec)
记录下File和Position的值，之后暂时不要操作主库，防止主库状态发生变化。
4、从库配置
修改主库MySQL配置文件/ect/my.cnf：
[mysqld]
log-bin=mysql-bin
server-id=2
注意主从库的server-id不要相同。
将主库信息导入到从库中：
mysql CHANGE MASTER TO
- MASTER_HOST='192.168.3.11',
- MASTER_USER='usere',
- MASTER_PASSWORD='password',
- MASTER_LOG_FILE='mysql-bin.000009',
- MASTER_LOG_POS=480;
启动从库slave同步：
mysql start slvae;
5、从库状态
mysql show slave status;
查看 Slave_IO_Running | Slave_SQL_Running，如果出现的结果是Yes | Yes，说明mysql主从配置成功完成了。
6、验证同步
在主库新建数据库，导入sql脚本后，查看从库也做了相应的改变，说明mysql主从同步成功。
从库生成两个线程，一个I/O线程，一个SQL线程；
I/O线程去请求主库 的binlog，并将得到的binlog日志写到relay log（中继日志） 文件中；
主库会生成一个 log dump 线程，用来给从库 I/O线程传binlog；
SQL 线程，会读取relay log文件中的日志，并解析成具体操作，来实现主从的操作一致，而最终数据一致；
1、设置主/从服务器配置
2、创建主/从服务器容器
此处为尽量排除版本不一致导致各种未知问题，所以采用docker构建部署MySql
3、登录主服务器的mysql，查询master的状态
Slave_IO_State 提示：Waiting for master to send event 就是成功了，可在主库添加或修改数据，在到从库查看是否同步
Connecting to master 多半是网络连接不通，可查看日志文件确认
到此你已经可以实现主从同步了
温馨提示 ： 以上弱密码需自行修改
大致步骤如下：主MySQL服务器：192.168.3.1备MySQL服务器：192.168.3.2配置文件路径：/etc/my.cnfMySQL服务状态：停止-------------------------主服务器配置-------------------编辑配置文件：vi /etc/my.cnf找到[mysqld]在它下面添加内容：server-id=1log-bin=backuplogbinlog-do-db=test#如果有多个数据库需要同步，添加多行即可#binlog-do-db=test2保存my.cnf配置文件。启动mysql：service mysqld start用root登录mysql，为同步数据创建新帐号：grant file,select,replication slave on *.* to 'test'@'%' identified by '123456';------------------------备服务器配置-------------------------编辑配置文件：vi /etc/my.cnf在[mysqld]下加入：server-id=2master-host=192.168.3.1master-user=testmaster-password=123456master-port=3306#replicate-do-db=test #此配置项为设置仅同步的数据库名，其它数据库忽略（建议不设置此选项）保存并启动mysql即可。如果需要查看同步状态，可分别在主从服务器上用如下命令查看：主服务器：show master status;从服务器：show slave status\G------------------值得说明的两个文件-----------------备份服务器上的/var/lib/mysql/目录下有两个：master.info和relay-log.info它们记录了主服务器的配置信息和同步信息，如果出现备份服务器不能同步数据的问题，可尝试将这两个文件删除，让备服务器重新同步。备注：进行操作之前先备份下数据比较保险一点。 查看原帖
MySQL 主从一直是面试常客，里面的知识点虽然基础，但是能回答全的同学不多。
比如楼哥之前面试小米，就被问到过主从复制的原理，以及主从延迟的解决方案，因为回答的非常不错，给面试官留下非常好的印象。你之前面试，有遇到过哪些 MySQL 主从的问题呢？
所谓 MySQL 主从，就是建立两个完全一样的数据库，一个是主库，一个是从库， 主库对外提供读写的操作，从库对外提供读的操作 ，下面是一主一从模式：
对于数据库单机部署，在 4 核 8G 的机器上运行 MySQL 5.7 时，大概可以支撑 500 的 TPS 和 10000 的 QPS， 当遇到一些活动时，查询流量骤然，就需要进行主从分离。
大部分系统的访问模型是读多写少，读写请求量的差距可能达到几个数量级，所以我们可以通过一主多从的方式， 主库只负责写入和部分核心逻辑的查询，多个从库只负责查询，提升查询性能，降低主库压力。
MySQL 主从还能做到服务高可用，当主库宕机时，从库可以切成主库，保证服务的高可用，然后主库也可以做数据的容灾备份。
整体场景总结如下：
MySQL 的主从复制是依赖于 binlog 的，也就是记录 MySQL 上的所有变化并以二进制形式保存在磁盘上二进制日志文件。
主从复制就是将 binlog 中的数据从主库传输到从库上，一般这个过程是异步的，即主库上的操作不会等待 binlog 同步的完成。
详细流程如下：
当主库和从库数据同步时，突然中断怎么办？因为主库与从库之间维持了一个长链接，主库内部有一个线程，专门服务于从库的这个长链接的。
对于下面的情况，假如主库执行如下 SQL，其中 a 和 create_time 都是索引：
我们知道，数据选择了 a 索引和选择 create_time 索引，最后 limit 1 出来的数据一般是不一样的。
所以就会存在这种情况：在 binlog = statement 格式时，主库在执行这条 SQL 时，使用的是索引 a，而从库在执行这条 SQL 时，使用了索引 create_time，最后主从数据不一致了。
那么我们改如何解决呢？
可以把 binlog 格式修改为 row，row 格式的 binlog 日志记录的不是 SQL 原文，而是两个 event:Table_map 和 Delete_rows。
Table_map event 说明要操作的表，Delete_rows event用于定义要删除的行为，记录删除的具体行数。 row 格式的 binlog 记录的就是要删除的主键 ID 信息，因此不会出现主从不一致的问题。
但是如果 SQL 删除 10 万行数据，使用 row 格式就会很占空间的，10 万条数据都在 binlog 里面，写 binlog 的时候也很耗 IO。但是 statement 格式的 binlog 可能会导致数据不一致。
设计 MySQL 的大叔想了一个折中的方案，mixed 格式的 binlog，其实就是 row 和 statement 格式混合使用， 当 MySQL 判断可能数据不一致时，就用 row 格式，否则使用就用 statement 格式。
有时候我们遇到从数据库中获取不到信息的诡异问题时，会纠结于代码中是否有一些逻辑会把之前写入的内容删除，但是你又会发现，过了一段时间再去查询时又可以读到数据了，这基本上就是主从延迟在作怪。
主从延迟，其实就是“从库回放” 完成的时间，与 “主库写 binlog” 完成时间的差值， 会导致从库查询的数据，和主库的不一致 。
谈到 MySQL 数据库主从同步延迟原理，得从 MySQL 的主从复制原理说起：
总结一下主从延迟的主要原因 ：主从延迟主要是出现在 “relay log 回放” 这一步，当主库的 TPS 并发较高，产生的 DDL 数量超过从库一个 SQL 线程所能承受的范围，那么延时就产生了，当然还有就是可能与从库的大型 query 语句产生了锁等待。
我们一般会把从库落后的时间作为一个重点的数据库指标做监控和报警，正常的时间是在毫秒级别，一旦落后的时间达到了秒级别就需要告警了。
解决该问题的方法，除了缩短主从延迟的时间，还有一些其它的方法，基本原理都是尽量不查询从库。
具体解决方案如下：
在实际应用场景中，对于一些非常核心的场景，比如库存，支付订单等，需要直接查询从库，其它非核心场景，就不要去查主库了。
两台机器 A 和 B，A 为主库，负责读写，B 为从库，负责读数据。
如果 A 库发生故障，B 库成为主库负责读写，修复故障后，A 成为从库，主库 B 同步数据到从库 A。
一台主库多台从库，A 为主库，负责读写，B、C、D为从库，负责读数据。
如果 A 库发生故障，B 库成为主库负责读写，C、D负责读，修复故障后，A 也成为从库，主库 B 同步数据到从库 A。
把主数据库中的log-bin=C:\Program Files\MySQL\MySQL Server 5.5\log-bin.log 改成log-bin=mysql.bin 然后再启动从数据库看看，如果还不行，在主数据库中show master status;查看主数据库的设置是否正确。
