之后使用 “systemctl start mysql” 重启服务器，报错
Job for mysql.service failed because the control process exited with error code. See "systemctl status mysql.service" and "journalctl -xe" for details. 解决方法：在设置 log-bin 的时候同时需要设置 server-id 变量，即在配置文件中添加：
[mysqld] log-bin=mysql server-id=1然后再次重启即可
补充知识 装mysql,运行一段时间后，在mysql目录下出现一堆类似mysql-bin.000***，从mysql-bin.000001开始一直排列下来，而且占用了大量硬盘空间，高达几十个G. 对于这些超大空间占用量的文件我们应该怎么办呢? 那么mysql数据库文件夹中的mysql-bin.00001是什么文件？ mysql-bin.000001、mysql-bin.000002等文件是数据库的操作日志，例如UPDATE一个表，或者DELETE一些数据，即使该语句没有匹配的数据，这个命令也会存储到日志文件中，还包括每个语句执行的时间，也会记录进去的。 这些形如mysql-bin.00001的文件主要是用来做什么的呢? 1：数据恢复 如果你的数据库出问题了，而你之前有过备份，那么可以看日志文件，找出是哪个命令导致你的数据库出问题了，想办法挽回损失。 2：主从服务器之间同步数据 主服务器上所有的操作都在记录日志中，从服务器可以根据该日志来进行，以确保两个同步。 如果不想要这些文件应该怎么做呢? 1：只有一个mysql服务器，那么可以简单的注释掉这个选项就行了。 vi /etc/my.cnf把里面的 log-bin 这一行注释掉，重启mysql服务即可。 2：如果你的环境是主从服务器，那么就需要做以下操作了。 A：在每个从属服务器上，使用SHOW SLAVE STATUS来检查它正在读取哪个日志。 B：使用SHOW MASTER LOGS获得主服务器上的一系列日志。 C：在所有的从属服务器中判定最早的日志，这个是目标日志，如果所有的从属服务器是更新的，就是清单上的最后一个日志。 D：清理所有的日志，但是不包括目标日志，因为从服务器还要跟它同步。 简单地说,这些MySQL目录下的形如mysql-bin.000***的文件时MySQL的事务日志。 删除复制服务器已经拿走的binlog是安全的，一般来说网络状况好的时候，保留最新的那一个足以。再次执行之前的备份命令，即可成功被封mc_orderdb数据库下的所有表，我们可以查询一下备份的SQL文件中是否包含所有表
[root@localhost db_backup]# grep "CREATE TABLE" mc_orderdb.sql CREATE TABLE `order_cart` ( CREATE TABLE `order_customer_addr` ( CREATE TABLE `order_detail` ( CREATE TABLE `order_master` ( CREATE TABLE `region_info` ( CREATE TABLE `shipping_info` ( CREATE TABLE `warehouse_info` ( CREATE TABLE `warehouse_proudct` ( [root@localhost db_backup]#通过上面结果可以看出我们的几个表都在其中
备份某个数据库下的某个表 [root@localhost db_backup]# mysqldump -ubackup -p --master-data=2 --single-transaction --routines --triggers --events mc_orderdb order_master > order_master.sql Enter password: [root@localhost db_backup]# ls mc_orderdb.sql order_master.sql 备份MySQL实例下的所有数据库 [root@localhost db_backup]# mysqldump -ubackup -p --master-data=1 --single-transaction --routines --triggers --events --all-databases > mc.sql Enter password: [root@localhost db_backup]# ls mc_orderdb.sql mc.sql order_master.sql