看看报错信息，缺点是“(-1, 'error totally whack')”
这个缺点让我没有任何思路，网上有一些谈论说是访问数据库出错了。
但是我查看运维系统后台的日志，API访问依旧正常，再试了一个备用账号，创造也能够正常上岸，我就疑惑是不是就我们两个上岸不明晰，看看上岸记录的信息，其他人都是正常的。我就纳闷了，看来这个问题的缘故原由很扑朔迷离啊。
我的第一个思路是想Django的项目里面会自动掩护一个django_session我的印象中这个表有百万条记录了，会不会是由于检讨的时候回调写入这个表的时候有问题导致的。
这个文件有1.6G旁边，算是比较大的了。
-rw-r----- 1 mysql mysql 8664 Feb 22 13:25 django_session.frm
-rw-r----- 1 mysql mysql 1690304512 Mar 19 09:40 django_session.ibd
清理会话信息Django供应了一个方法clearsessions
python manage.py clearsessions
(0.000) SET SQL_AUTO_IS_NULL = 0; args=None
(0.000) SET SQL_AUTO_IS_NULL = 0; args=None
(430.746) DELETE FROM `django_session` WHERE `django_session`.`expire_date` < '2019-03-19 09:46:23.752256'; args=(u'2019-03-19 09:46:23.752256',)
这个过程持续了6分钟，从后真个日志来看前端业务没有任何影响。
当然delete是不彻底的，表还是1.6G旁边，这个时候我们利用一点小技巧来转移一下数据，这个过程持续韶光较短，大概有几秒钟。
整体的思路便是移形换位。
create table devopsdb_arch.django_session like devopsdb.django_session;
insert into devopsdb_arch.django_session select from devopsdb.django_session where ;
alter table devopsdb.django_session rename to devopsdb_arch.django_session_bak;
alter table devopsdb_arch.django_session rename to devopsdb.django_session;
清理完之后，空间立马紧缩到了几十兆，但是登录的时候依然报错，以是这个时候我开始重新核阅这个问题，问题不在django_session表上面。
看后真个日志调用，是在检讨用户名密码之后，会写入django_session数据之后回调写入auth_user表，把last_login字段修正为当前韶光。
但是根据报错在这个阶段失落败了，以是我就考试测验手工修正一下这个部分，结果创造了问题：
update auth_user set last_login='2019-03-19 09:15:38' where username='root';
ERROR 3101 (HY000): Plugin instructed the server to rollback the current transaction.
看到这个问题，我已经基本打消了运用层面的问题，很可能是数据库导致的了。这个数据库是一套MGR多主的环境，和其余一套环境是跨机房的多活架构。
对付这个问题的修复，排查了sys schema下面和锁干系的数据字典，没有得到任何信息。
带着试试看的态度，由于节点2目前没有业务写入，对节点二的环境重启了Group replication，重启后，考试测验update竟然成功了。
>>update auth_user set last_login='2019-03-19 09:15:38' where id=1;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0
但是我重新登录页面的时候还是报错了。
重新进行验证创造还是同样的问题，我疑惑是django_session写入的事务失落败导致，以是再一次清理了会话表，这一次很快就完成了，但是登录依旧失落败。
以是这个时候耐下心来看看GTID的配置和日志的信息，创造有一个事务的日志没有运用过去。
这个问题的一种补救办法便是关闭流控flowcontrol,然后重启Group replication，我先停滞了节点2的GR,然后停滞节点1的GR,然后启动，接着启动节点2的GR.
再次测试就正常了。
这个问题虽然办理了，但是由于限于环境和规复业务的须要，没有做更多的剖析。 从表现来看和其余一个bug有些类似。
https://bugs.mysql.com/bug.php?id=84901
对付多主环境的问题还须要持续关注，从目前来看还算是比较稳定的。
