早上巡检数据库,发现一个延迟从库的sql_thread中断了。

 

常用的第一种方法就是把/usr/local/ 文件夹下的有关 mysql
的两个文件夹都删除了. 附图就应该懂啦~:
至于怎么找到的这两个文件也说一下吧: Finder右键 > 前往文件夹 >
/usr/local/

注:入坑内容来源于易百教程,这只是自己学习路上的经验总结…(附上易百教程网址:)
持续跟新中…

一,Illegal mix of collations (gbk_bin,IMPLICIT) and (latin1_swedish_ci,COERCIBL

在MySQL上写了一个存储过程,但是我发现用#写完中文注释后,在保存时这些注释会消失。在觉得可能是编码问题导致识别不了中文语句,于是就直接将数据库的编码修改成为了gbk,但是并没有能够修复这个问题。

相反,在运行原本正常的存储过程时,出现了诡异的报错:Illegal mix of
collations (gbk_bin,IMPLICIT) and (latin1_swedish_ci,COERCIBL…

百度之后并没有合适的解决办法,阅读了stackoverflow上的这篇回答,里面介绍了MySQL本身的编码和字符比较体系,collation的设定保证了使用某种编码体系时可以正常进行字符之间的比较,包括bin/cs/ci几种,分别代表二进制字符比较(可以比较二进制字符和正常字符,大小写敏感)、大小写敏感、大小写不敏感三种比较方式。同时,这个回答给出了下面的描述:

Literal expressions take the collation specified in
the collation_connection system
variable; values from tables take the collation specified in their
column metadata.

表达式会使用系统默认的collation_connection字符比较设定,而表内的值则会采取最初建表时给每个列设定的设定。

接下来,我使用“show
VARIABLES”命令查看了系统对应的变量,找到collation_connection,发现取值为latin1_swedish_ci,猜测应该是之前写存储过程时,默认使用的latin编码,但是后面我将数据库编码整体修改为了gbk_bin,导致了不同步。

图片 1

本来准备查一下是否有办法可以修改“collation_connection”,但是发现并没有特别便利的解决方案。

于是,我就把数据库的编码模式回退到了“latin1”,并且将“collation_connection”设置为“latin1_swedish_ci”,于是问题解决了。

Last_SQL_Errno: 1755
Last_SQL_Error: Cannot execute the current event group in the parallel
mode. Encountered event Gtid, relay-log name ./oracle-relay-bin.000093,
position 152912092 which prevents execution of this event group in
parallel mode. Reason: The master event is logically timestamped
incorrectly..

今天在调试MySQL出现了一些坑。需要记录一下。

图片 2

MySQL导入示例数据库(

基本语句:

SELECT语句(从表或试图获取数据)

  查询employees表里的所有信息

 SELECT * FROM employees;

  只查看员工的名字,姓氏和职位,请使用以下查询:

 SELECT lastname, firstname, jobtitle FROM employees;

where语句(根据指定的过滤表达式或条件来指定要选择的行)

  假设只想从employees表中获取销售代表员工,可使用以下查询

SELECT 
    lastname, firstname, jobtitle
FROM
    employees
WHERE
    jobtitle = 'Sales Rep';

 

**数据库的操作:**

  创建数据库:

 

CREATE DATABASE [IF NOT EXISTS] database_name;

 

    显示数据库:

SHOW DATABASES

  选择要使用的数据库:

USE DATABASE;

  删除数据库:

 

DROP DATABASE [IF EXISTS] database_name;

 

 

 

**数据库_表_的操作:**       

**  创建表:**

 

CREATE TABLE [IF NOT EXISTS] table_name(
        column_list
) engine=table_type;

 

注:要在CREATE TABLE语句中为表定义列,请使用以下语法:

column_name data_type[size] [NOT NULL|NULL] [DEFAULT value] [AUTO_INCREMENT]
  • column_name指定列的名称。每列具有特定数据类型和大小,例如:VARCHAR(255)
  • NOT NULLNULL表示该列是否接受NULL值。
  • DEFAULT值用于指定列的默认值。
  • AUTO_INCREMENT指示每当将新行插入到表中时,列的值会自动增加。每个表都有一个且只有一个AUTO_INCREMENT列。

**如果要将表的特定列设置为主键,则使用以下语法:**

 

PRIMARY KEY (col1,col2,...)

 

eg:

图片 3图片 4

CREATE TABLE IF NOT EXISTS tasks (
  task_id INT(11) NOT NULL AUTO_INCREMENT,
  subject VARCHAR(45) DEFAULT NULL,
  start_date DATE DEFAULT NULL,
  end_date DATE DEFAULT NULL,
  description VARCHAR(200) DEFAULT NULL,
  PRIMARY KEY (task_id)
) ENGINE=InnoDB;

View Code

 

  修改表(包括删除):

首先创建一个名为tasks的新表:

 

图片 5图片 6

DROP TABLE IF EXISTS tasks;

CREATE TABLE tasks (
    task_id INT NOT NULL,
    subject VARCHAR(45) NULL,
    start_date DATE NULL,
    end_date DATE NULL,
    description VARCHAR(200) NULL,
    PRIMARY KEY (task_id),
    UNIQUE INDEX task_id_unique (task_id ASC)
);

View Code

 

使用MySQL ALTER
TABLE语句来设置列的自动递增属性:

ALTER TABLE tasks
CHANGE COLUMN task_id task_id INT(11) NOT NULL AUTO_INCREMENT;

验证:

图片 7图片 8

INSERT INTO tasks(subject,
                  start_date,
                  end_date,
   description)
VALUES('Learn MySQL ALTER TABLE',
       Now(),
       Now(),
      'Practicing MySQL ALTER TABLE statement');

INSERT INTO tasks(subject,
                  start_date,
                  end_date,
           description)
VALUES('Learn MySQL CREATE TABLE',
       Now(),
       Now(),
      'Practicing MySQL CREATE TABLE statement');

SELECT 
    task_id, description
FROM
    tasks;

View Code

使用MySQL ALTER TABLE语句将新的列添加到表中:

ALTER TABLE tasks 
ADD COLUMN complete DECIMAL(2,1) NULL
AFTER description;

使用MySQL ALTER TABLE从表中删除列:

ALTER TABLE tasks
DROP COLUMN description;

重命名表:

ALTER TABLE tasks
RENAME TO work_items;

 

 

**   **

**数据的增删改查:
**

  首先创建一个表:  

USE testdb;

CREATE TABLE IF NOT EXISTS tasks (
    task_id INT(11) AUTO_INCREMENT,
    subject VARCHAR(45) DEFAULT NULL,
    start_date DATE DEFAULT NULL,
    end_date DATE DEFAULT NULL,
    description VARCHAR(200) DEFAULT NULL,
    PRIMARY KEY (task_id)
)ENGINE=InnoDB DEFAULT CHARSET=utf8;

 

INSERT INTO(插入数据)

 INSERT INTO table(column1,column2...)
 VALUES (value1,value2,...);

  多行:

INSERT INTO table(column1,column2...)
VALUES (value1,value2,...),
       (value1,value2,...),
...;

  如果为表中的所有列指定相应列的值,则可以忽略INSERT语句中的列列表,如下所示:

INSERT INTO table
VALUES (value1,value2,...),
       (value1,value2,...),
...;

update语句(更新数据)

UPDATE table_name 
SET 
    column_name1 = expr1,
    column_name2 = expr2,
    ...
WHERE
    condition;

eg:

UPDATE employees 
SET 
    email = 'mary.new@yiibai.com'
WHERE
    employeeNumber = 1056;

多行:

UPDATE employees 
SET 
    lastname = 'Hill',
    email = 'mary.hill@yiibai.com'
WHERE
    employeeNumber = 1056;

delete语句(删除数据)

DELETE FROM table_name
WHERE condition;

 

二、MySQL客户端中的超时连接时间设置

当用MySQL查询比较大的表时,如果使用客户端,会出现连接超时的报错情况,这种情况下,可以修改客户端上的超时时间。MySQL
Workbench和Navicat不同。

MySQL Workbench:

图片 9

Navicat:

在需要修改的数据库上“右键->编辑连接”

图片 10

条件判断中的NULL,如果是某个字段取值A为NULL,在使用条件“A<>’0′
”之类的格式时,并不会返回NULL的行,目前还不清楚原因,猜测可能NULL和普通的取值不在一个比较体系里面,这种情况下,如果只是需要返回NULL对应的行,就用is
NULL做判断就好了。

检查performance_schema下的replication_applier_status_by_worker表,除了GTID之外也没有更具体的信息:

# These are commonly set, remove the # and set as required.
 basedir =E:\MySQL\mysql-5.7.16-winx64\mysql-5.7.16-winx64
 datadir =E:\MySQL\mysql-5.7.16-winx64\mysql-5.7.16-winx64\data
 #bind-address=127.0.0.1
 port =3306
 #skip-grant-tables
 #server_id =....

/usr/local文件夹

"root@localhost:mysql3308.sock  [(none)]>select * from performance_schema.replication_applier_status_by_worker;
+--------------+-----------+-----------+---------------+------------------------------------------------+-------------------+--------------------+----------------------+
| CHANNEL_NAME | WORKER_ID | THREAD_ID | SERVICE_STATE | LAST_SEEN_TRANSACTION                          | LAST_ERROR_NUMBER | LAST_ERROR_MESSAGE | LAST_ERROR_TIMESTAMP |
+--------------+-----------+-----------+---------------+------------------------------------------------+-------------------+--------------------+----------------------+
|              |         1 |      NULL | OFF           | 0b961fcc-41c2-11e7-84fd-286ed488c7da:156369774 |                 0 |                    | 0000-00-00 00:00:00  |
|              |         2 |      NULL | OFF           |                                                |                 0 |                    | 0000-00-00 00:00:00  |
|              |         3 |      NULL | OFF           |                                                |                 0 |                    | 0000-00-00 00:00:00  |
|              |         4 |      NULL | OFF           |                                                |                 0 |                    | 0000-00-00 00:00:00  |
|              |         5 |      NULL | OFF           |                                                |                 0 |                    | 0000-00-00 00:00:00  |
|              |         6 |      NULL | OFF           |                                                |                 0 |                    | 0000-00-00 00:00:00  |
|              |         7 |      NULL | OFF           |                                                |                 0 |                    | 0000-00-00 00:00:00  |
|              |         8 |      NULL | OFF           |                                                |                 0 |                    | 0000-00-00 00:00:00  |
+--------------+-----------+-----------+---------------+------------------------------------------------+-------------------+--------------------+----------------------+

上面一句
skip-grant-tables这句话就是你在无法知道root密码的时候进行非授权进去修改密码的。


既然relay_log的位置信息都有了,那就去日志里看看吧:

但是我无论怎么做:

还有一种是参照了好几篇文章发现的, 应该也能卸载干净~:

解析Binlog文件:

update user set password=password(‘123456′) where user=’root’;

先停止所有mysql有关进程, 在终端里逐条运行下列语句:

mysqlbinlog -v --base64-output=decode-rows oracle-relay-bin.000093 >1.sql

确发现我始终是不能更改这个密码总是会提示我什么什么root@localhost无法访问之内的,最后找到一个方法处理具体是哪位的博客忘记记录了

sudo rm /usr/local/mysql

sudo rm -rf /usr/local/mysql*

sudo rm -rf /Library/StartupItems/MySQLCOM

sudo rm -rf /Library/PreferencePanes/My*

vim /etc/hostconfig  (and removed the line MYSQLCOM=-YES-)

rm -rf ~/Library/PreferencePanes/My*

sudo rm -rf /Library/Receipts/mysql*

sudo rm -rf /Library/Receipts/MySQL*

sudo rm -rf /var/db/receipts/com.mysql.*

找到152912092位置点附近的日志:

图片 11

注: 也将会卸载MySQL的DMG格式安装文件.

图片 12

直接修改授权的密码

希望mac MySQL的那些坑这一系列文章能够帮助大家尽快入门~~

检查了一下数据库中这个表ID为14816035的数据确实是不存在的。

然后能登陆了,但是你发现你创建库的时候或者表的时候,还是会出现错误。

另外除了这条日志,其它日志的last_committed和sequence_number都为0,last_committed表示事务提交的时候,上次事务提交的编号。last_committed和sequence_number代表的就是所谓的LOGICAL_CLOCK。

图片 13

猜测如果手动把这条数据插入延迟从库,并且使用注入一个空事务跳过这个GTID的方法重启sql_thread,相信这个错误也能被解决。

这时候你需要再次执行

但既然带了LOGICAL_CLOCK的事务就会出错,跳过事务的方法很难保证以后不会出错。

图片 14

注意到这条日志的last_committed是一个异常大的值,且错误信息中有提到The
master event is logically timestamped
incorrectly。我怀疑是不是并行配置的问题。

这就ok了

从库配置:

创建库

"root@localhost:mysql3308.sock  [(none)]>show variables like '%para%';
+------------------------+---------------+
| Variable_name          | Value         |
+------------------------+---------------+
| slave_parallel_type    | LOGICAL_CLOCK |
| slave_parallel_workers | 8             |
+------------------------+---------------+

图片 15

 再检查主库配置:

创建表

(root@localhost:mysql.sock) [(none)]>show variables like '%para%';
+------------------------+-------+
| Variable_name          | Value |
+------------------------+-------+
| slave_parallel_workers | 0     |
+------------------------+-------+

图片 16

 发现主库根本就没有slave_parallel_type这项配置。想起来主库是mysql5.6了。

查询

(root@localhost:mysql.sock) [(none)]>select version();
+------------+
| version()  |
+------------+
| 5.6.35-log |
+------------+

图片 17

 那么问题基本上就知道了,主库5.6只支持基于DATABASE的并行复制,而5.7的从库配置成LOGICAL_CLOCK导致了异常。

查询所有的数据库

明白了问题所在,那就好解决了,把从库的slave_parallel_type改为DATABASE,再起sql_thread问题应该就解决了:

图片 18

"root@localhost:mysql3308.sock  [none]>set global slave_parallel_type='DATABASE';
Query OK, 0 rows affected (0.00 sec)

"root@localhost:mysql3308.sock  [none]>show global variables like '%slave_parallel_type%';
+---------------------+----------+
| Variable_name       | Value    |
+---------------------+----------+
| slave_parallel_type | DATABASE |
+---------------------+----------+
1 row in set (0.00 sec)

"root@localhost:mysql3308.sock  [none]>show slave status\G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: master
                  Master_User: rep
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: binlog.000104
          Read_Master_Log_Pos: 160115307
               Relay_Log_File: oracle-relay-bin.000093
                Relay_Log_Pos: 152912092
        Relay_Master_Log_File: binlog.000100
             Slave_IO_Running: Yes
            Slave_SQL_Running: No
              Replicate_Do_DB: 
          Replicate_Ignore_DB: 
           Replicate_Do_Table: 
       Replicate_Ignore_Table: 
      Replicate_Wild_Do_Table: 
  Replicate_Wild_Ignore_Table: 
                   Last_Errno: 1755
                   Last_Error: Cannot execute the current event group in the parallel mode. Encountered event Gtid, relay-log name ./oracle-relay-bin.000093, position 152912092 which prevents execution of this event group in parallel mode. Reason: The master event is logically timestamped incorrectly..
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 152911925
              Relay_Log_Space: 4455094667
              Until_Condition: None
               Until_Log_File: 
                Until_Log_Pos: 0
           Master_SSL_Allowed: No
           Master_SSL_CA_File: 
           Master_SSL_CA_Path: 
              Master_SSL_Cert: 
            Master_SSL_Cipher: 
               Master_SSL_Key: 
        Seconds_Behind_Master: NULL
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error: 
               Last_SQL_Errno: 1755
               Last_SQL_Error: Cannot execute the current event group in the parallel mode. Encountered event Gtid, relay-log name ./oracle-relay-bin.000093, position 152912092 which prevents execution of this event group in parallel mode. Reason: The master event is logically timestamped incorrectly..
  Replicate_Ignore_Server_Ids: 
             Master_Server_Id: 50
                  Master_UUID: 0b961fcc-41c2-11e7-84fd-286ed488c7da
             Master_Info_File: mysql.slave_master_info
                    SQL_Delay: 3600
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State: 
           Master_Retry_Count: 86400
                  Master_Bind: 
      Last_IO_Error_Timestamp: 
     Last_SQL_Error_Timestamp: 180716 18:02:56
               Master_SSL_Crl: 
           Master_SSL_Crlpath: 
           Retrieved_Gtid_Set: 0b961fcc-41c2-11e7-84fd-286ed488c7da:111060115-163843604
            Executed_Gtid_Set: 0b961fcc-41c2-11e7-84fd-286ed488c7da:1-156369774
                Auto_Position: 1
         Replicate_Rewrite_DB: 
                 Channel_Name: 
           Master_TLS_Version: 
1 row in set (0.00 sec)

"root@localhost:mysql3308.sock  [none]>stop slave sql_thread;
Query OK, 0 rows affected, 1 warning (0.00 sec)

"root@localhost:mysql3308.sock  [none]>start slave sql_thread;
Query OK, 0 rows affected (0.01 sec)

"root@localhost:mysql3308.sock  [none]>show slave status\G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: master
                  Master_User: rep
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: binlog.000104
          Read_Master_Log_Pos: 160161836
               Relay_Log_File: oracle-relay-bin.000093
                Relay_Log_Pos: 169205552
        Relay_Master_Log_File: binlog.000100
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              Replicate_Do_DB: 
          Replicate_Ignore_DB: 
           Replicate_Do_Table: 
       Replicate_Ignore_Table: 
      Replicate_Wild_Do_Table: 
  Replicate_Wild_Ignore_Table: 
                   Last_Errno: 0
                   Last_Error: 
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 169205385
              Relay_Log_Space: 4455141196
              Until_Condition: None
               Until_Log_File: 
                Until_Log_Pos: 0
           Master_SSL_Allowed: No
           Master_SSL_CA_File: 
           Master_SSL_CA_Path: 
              Master_SSL_Cert: 
            Master_SSL_Cipher: 
               Master_SSL_Key: 
        Seconds_Behind_Master: 5351
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error: 
               Last_SQL_Errno: 0
               Last_SQL_Error: 
  Replicate_Ignore_Server_Ids: 
             Master_Server_Id: 50
                  Master_UUID: 0b961fcc-41c2-11e7-84fd-286ed488c7da
             Master_Info_File: mysql.slave_master_info
                    SQL_Delay: 3600
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State: Waiting for Slave Worker to release partition
           Master_Retry_Count: 86400
                  Master_Bind: 
      Last_IO_Error_Timestamp: 
     Last_SQL_Error_Timestamp: 
               Master_SSL_Crl: 
           Master_SSL_Crlpath: 
           Retrieved_Gtid_Set: 0b961fcc-41c2-11e7-84fd-286ed488c7da:111060115-163843692
            Executed_Gtid_Set: 0b961fcc-41c2-11e7-84fd-286ed488c7da:1-156400100
                Auto_Position: 1
         Replicate_Rewrite_DB: 
                 Channel_Name: 
           Master_TLS_Version: 
1 row in set (0.00 sec)

终于找到喜欢命令行的理由了。

打完收工。

 

转载请注明出处。

本文地址:

发表评论

电子邮件地址不会被公开。 必填项已用*标注

网站地图xml地图