有没有用os x 10.11装MySQL 5.7.11的大神，初始密码死活修改不了

1.用系统管理员登陆系统。

2.停止MySQL的服务。

3.进入命令窗口，然后进入MySQL的安装目录，比如我的安装目录是c:\mysql,进入C:\mysql\bin

4.跳过权限检查启动MySQL，

c:\mysql\bin>mysqld-nt --skip-grant-tables

5.重新打开一个窗口，进入c:\mysql\bin目录，设置root的新密码

c:\mysql\bin>mysqladmin -u root flush-privileges password "newpassword"

c:\mysql\bin>mysqladmin -u root -p shutdown

将newpassword替换为你要用的root的密码，第二个命令会提示你输入新密码，重复第一个命令输入的密码。

1、解压MySQL压缩包

将下载的MySQL压缩包解压到自定义目录下,解压目录是:

"D:\Program Files\mysql-5.7.11-winx64"

将解压目录下默认文件 my-default.ini 拷贝一份，改名 my.ini

复制下面的配置信息到 my.ini 保存

#如果没有my-default.ini,可新建my.ini或者从其他地方中获取

[client]

port=3306

default-character-set=utf8

[mysqld]

port=3306

character_set_server=utf8

#解压目录

basedir=D:\Program Files\mysql-5.7.11-winx64

#解压目录下data目录

datadir=D:\Program Files\mysql-5.7.11-winx64\data

sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES

[WinMySQLAdmin]

D:\Program Files\mysql-5.7.11-winx64\bin\mysqld.exe

2、添加环境变量

*** 作如下：

1）右键单击我的电脑->属性->高级系统设置(高级)->环境变量

点击系统变量下的新建按钮

输入变量名：MYSQL_HOME

输入变量值：D:\Program Files\mysql-5.7.11-winx64

#即为mysql的自定义解压目录。

2）选择系统变量中的Path

点击编辑按钮

在变量值中添加变量值：%MYSQL_HOME%\bin

注意是在原有变量值后面加上这个变量，用隔开，不能删除原来的变量值

3、 1）从控制台进入到MySQL解压目录下的 bin 目录下：

2）输入服务安装命令：

1. mysqld --console

2. mysqld --initialize

3. mysqld install

安装成功后会提示服务安装成功。

#注： #执行这几步，是因为在MySQL5.7.9中没有data文件夹，需要用这几个命令产生data文件夹

#移除服务命令为：mysqld remove

4、启动MySQL服务

方法一：

启动服务命令为：net start mysql

方法二：

打开管理工具 服务，找到MySQL服务。

通过右键选择启动或者直接点击左边的启动来启动服务。

5、修改 root 账号的密码

1. 修改MySQL的配置文件（my.ini）,在[mysqld]下添加一行skip-grant-tables

2. mysql 重启后，即可直接用 mysql -u root -p 进入(此时密码为空)

3. mysql>update mysql.user set authentication_string=password('123qaz') where user='root' and Host = 'localhost'

4. mysql>flush privileges

5. mysql>quit

6. 将/etc/my.cnf文件还原(删除skip-grant-tables这一行)，重新启动 mysql

7. 这个时候可以使用 mysql -u root -p '123qaz' 进入了

8. mysql>SET PASSWORD = PASSWORD('123456')设置新密码

线上一个5.7从库复制中断：

查询具体报错：

第一感觉很奇怪，为什么会rollback失败呢？于是根据gtid去对应的主库binlog去看了下，并没有任何rollback语句：

看下本地的relay log，找到这个事务的gtid

到这里，这个relay log日志文件结束了。很显然问题也找到了，就是执行

出错了。

首先 我们看到 这个rollback是MySQL自己加上去的，那么为什么要加呢？

mysql为了保证一个事务只在一个binlog里，所以当Binlog或者relay log发生截断时，最后一个事务要么commit，要么rollback，如果rollback，那么下一个binlog或者relay log会把这个事务重做一遍，保证这个事务不会丢。

由于xa事务无法直接rollback，而需要xa rollback ‘XXX’，所以复制就停了。

怎么修复？是不是直接跳过这个rollback就行了？

我们来试一下，跳过这个rollback:

这里GTID_NEXT值不能用show slave status的里executed值，得用具体报错的停止的gtid

但是，show slave status看到，还是有报错：

为什么又报这个事务commit找不到XID呢？

之前说过，在relaylog截断的时候，如果事务没有commit,会自动在最后加rollback，在下一个relay log开始的时候重新做一次这个事务，按理说我们跳过这个rollback，在下个relaylog会被重做，为啥会在commit的时候找不到xid呢？

我们看到我们跳过的gtid原来就是重做这个事务到PREPARE阶段的gtid，原来，rollback是没有gtid的，所以我们实际上就是把这个事务到PREPARE阶段的gtid给跳过了，commit的时候肯定会找不到xid，接着怎么修复？

为什么这是5.7的一个bug呢？5.7之前的版本因为relaylog被截断并不会出现这个bug。

5.7对xa事务的binlog记录方式做了修改，把 xa start,xa end,xa prepare放到一个event里，xa commit又是另外一个event。而在之前的MySQL版本中，整个xa事务从start到commit都是在一个event中，所以其他版本并没有问题。

最后一个问题：5.7为啥要把xa事务拆成两个event？简单的讲是为了数据安全性。

5.5或者5.6假设下面一个场景：

MySQL在某个分布式事务prepare成功后宕机，宕机前 *** 作该事务的连接并没有断开（如果在宕机前断开连接，事务会被MySQL自动回滚），这个时候已经prepare的事务并不会被回滚，所以在MySQL重新启动后，引擎层通过recover机制能恢复该事务。当然该事务的Binlog已经在宕机过程中被丢失，这个时候，如果去提交，则会造成主从数据的不一致， 即提交没有记录Binlog，从上丢失该条数据。

正因为5.7之前版本的xa事务存在这个bug，5.7后做了修复。从XA START到XA PREPARE之间的 *** 作都被记录到了Master的Binlog中，然后通过复制关系传到了Slave上。也就是说5.7开始，MySQL对于XA事务，在prepare的时候就完成了写Binlog的 *** 作，通过新增一种叫 XA_prepare_log_event 的event类型来实现。

其实 MySQL5.7在xa事务上远不止这个bug，后面再来慢慢总结。

---