当前位置:首页 > CN2资讯 > 正文内容

windows mysql 服务器 sql查询语句导致崩溃 mysql服务器发生宕机怎么办

46分钟前CN2资讯


主库收到从库发送的注册指令后会获取到从库的server-id,report-host,report-user,report-password,prot等相关的数据,最终这些数据会存放到slave_list变量中,如果slave-list这个表中已经存在slave-server-id的信息则会删除掉这个信息,在将新的加入。(不能有相同的server-id出现,否则会直接删除)

master收到slave IO发送的请求后,获取slave发送的binlog相关信息,server-id,名称,POS,binlog大小等等,检查是否已经存在与该从库关联的binlog dump线程,例如,slave IO线程出了问题,此时master的binlog dump线程一直等待主库写入数据操作. 如果这时从库io线程重连到主库,就会发现主库已经存在与该从库对应的dump线程。所以主库在处理从库binlog dump请求时,先检查是否已经存在dump线程。

binlog dump内部调用的是多个while嵌套循环,依次等待并读取binlog文件中的event,随后将event发送到从库,如果此时从库envet已经在使用,则忽略该event,当读到新的binlog时如果event都已经发送完成,则 binlogdump线程会等待binlog更新事件。

IO线程请求拉取binlog的命令发送完成之后,io线程在一个while循环中,不断调用read_event(mysql, mi, &suppress_warnings) 来读取主库发送的binlog数据,并写入到relay log文件中。

IO线程以及master的log dump线程都使用循环的方式一个在等待主master写入数据并发送广播传输,当主库发送二进制日志后通过循环方式不断并写入到relay log文件当中。

1.2、MySQL主从复制配置相关

1.2.1、测试环境

主MySQL

192.168.1.8

从MySQL

192.168.1.9

MySQL

version:5.7

1.2.2、MySQL的部署

MySQL部署略过建议下载oneinstall一键下载工具部署mysql,非常好用!

1.2.3、MySQL主从复制的基本流程
  • 首先确定配置master 和 slave其中mysql主配置文件的 ‘server-id’
  • 创建一个用于slave和master通信的用户账号
  • 查看matser的状态,show matser status;需要记录:File的名称以及Postsion的数字
  • 主mysql数据给从数据授权之后需要通过从数据库进行连接操作,连接的时候需要matser的file名称以及postsion这两个数据
  • 从mysql数据库连接成功后,启动同步操作:start slave;
  • 最后检查连接的状态:(show slave status;)
  • 1.2.4、MySQL主从复制实现

    主从复制实现还是非常简单的,按照2.1.3的说明一步步部署就可以了,过程如下:

    1.2.4.1、Master与slave binlog日志开启

    第一步确定master和slave的mysql开启了binlog二进制文件的操作,可以通过以下命令查看:

    MySQL [(none)]> show variables like 'log\_bin'; +---------------+-------+ | Variable_name | Value | +---------------+-------+ | log_bin | ON | +---------------+-------+ 1 row in set (0.01 sec)

    确定log_bin为on的状态,mysql二进制日志mysql-bin.000001,mysql-bin.000002 这样的方式出现,通常出现在mysql目录下。mysql二进制日志中记录了mysql中sql语句执行的所有日志操作. 有一款mysql的工具是通过mysql二进制日志中的内容从而进行数据库的恢复操作. 如果mysql重启一次就会产生新的mysql-bin二进制日志。

    1.2.4.2、确认matser与slave serverid不一致

    server_id是不可以重复的,server_id 在每一个正在同步中的slave在master上都会对应一个matser线程,这个线程是通过slave的serverid来标识的,如果存在两台从服务器的serverid一致,只能一个链接成功,因为slave在master端最多只有一个线程,通过serverid来标识slave是哪台,如果发现slave两台id都一致,则会导致另外一台不同步的问题. 以下方式配置server id;

    master:

    [root@master ~]# vi /etc/my.cnf [root@master ~]# cat /etc/my.cnf | grep server-id server-id = 1 `这是配置文件中matser的id号` [root@master ~]#

    slave:

    [root@slave ~]# vi /etc/my.cnf [root@slave ~]# cat /etc/my.cnf | grep server-id server-id = 2 `这是配置文件中slave的id号` [root@slave ~]#

    配置matser 和 slave serverid后进行重启mysql操作使其生效!

    1.2.4.3、创建一个用于slave和master通信的用户账号

    mstser数据库操作:

    MySQL [(none)]> grant replication slave on *.* to 'myslave'@'192.168.1.9' identified by 'pwd123'; Query OK, 0 rows affected, 1 warning (0.01 sec) MySQL [(none)]> flush privileges; Query OK, 0 rows affected (0.00 sec) MySQL [(none)]>

    这条sql是授权1.9这台主机,也就是slave,通过myslave这个用户,通过密码pwd123来链接主mysql的操作

    1.2.4.4、查看master正在使用的二进制以及位置编号
    MySQL [(none)]> show master status; +------------------+----------+--------------+------------------+-------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set | +------------------+----------+--------------+------------------+-------------------+ | mysql-bin.000007 | 602 | | | | +------------------+----------+--------------+------------------+-------------------+ 1 row in set (0.00 sec)

    file表示mysql目前正在使用的二进制日志的文件,position记录了当前执行二进制日志位置。 这两个值需要做保留,从服务器会通过链接到主mysql,与主的二进制文件的日志进行同步,同时从哪里开始同步是由 Position来决定。

    1.2.4.5、slave数据库进行连接操作
    change master to master_host='192.168.1.8', master_user='myslave', master_password='pwd123', master_port=3306, master_log_file='mysql-bin.000007', master_log_pos=602 ;
    • change master to 连接matser数据库
    • master_host master数据库的地址
    • master_user master创建slave与master连接的用户名
    • master_password master创建slave与master连接用户名的密码
    • master_port master 数据库的端口
    • master_log_file matser数据库正在使用的二进制文件
    • master_log_pos master数据库执行二进制日志位置

    操作:

    MySQL [(none)]> change master to -> master_host='192.168.1.8', -> master_user='myslave', -> master_password='pwd123', -> master_port=3306, -> master_log_file='mysql-bin.000007', -> master_log_pos=602; Query OK, 0 rows affected, 2 warnings (0.00 sec) MySQL [(none)]>

    1.2.4.6、slave数据库启动同步

    start slave;命令

    MySQL [(none)]> start slave; Query OK, 0 rows affected (0.00 sec) MySQL [(none)]> show slave status\G; *************************** 1. row *************************** Slave_IO_State: Waiting for master to send event Master_Host: 192.168.1.8 Master_User: myslave Master_Port: 3306 Connect_Retry: 60 Master_Log_File: mysql-bin.000007 Read_Master_Log_Pos: 602 Relay_Log_File: 192-relay-bin.000003 Relay_Log_Pos: 320 Relay_Master_Log_File: mysql-bin.000007 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: 602 Relay_Log_Space: 1230 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: 0 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: 1 Master_UUID: 691ede37-7085-11ec-bbac-000c298a92c4 Master_Info_File: /data/mysql/master.info SQL_Delay: 0 SQL_Remaining_Delay: NULL Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates Master_Retry_Count: 86400 Master_Bind: Last_IO_Error_Timestamp: Last_SQL_Error_Timestamp: Master_SSL_Crl: Master_SSL_Crlpath: Retrieved_Gtid_Set: Executed_Gtid_Set: Auto_Position: 0 Replicate_Rewrite_DB: Channel_Name: Master_TLS_Version: 1 row in set (0.00 sec)

    Slave_IO_Running: Yes : IO线程开启成功
    Slave_SQL_Running: Yes : SQL线程开启成功

    1.2.4.7、验证数据同步

    到此刻matser数据库创建,删除,增加,改动,从数据库都会进行实时同步数据. 到此mysql主从复制已实现。

    1.3、MySQL主从复制测试

    1.3.1、测试主master宕机


    主数据库发生停止的情况下,slave的IO线程向master发出请求未能链接成功报错信息如下:

    当matser宕机后slave 状态显示error reconnecting to master '[email protected]:3306' - retry-time: 60 retries: 1重新连接到主服务器时出错[email protected]:3306’-重试时间:60

    1.3.2、测试master主服务器网络连接断开

    断开前:

    断开后:

    查看错误信息:

    一旦发生IO发生:error reconnecting to master '[email protected]:3306' - retry-time: 60 retries: 1错误问题以下几个方式解决:

  • 网络不通,尝试ping测试,检查网络通信问题是否能到达master
  • 配置给与权限slave连接主配置的用户名密码错误问题
  • 主防火墙以及从数据库防火墙配置限制问题,检查端口出入配置
  • IO进程去连接主mysql发送请求,如果出现非yes的情况则检查双方服务器数据库的连接问题。包括配置问题,确保网络,配置无误。如果配置无误则检查网络问题,当网络恢复之后,slave IO会重新链接运行。

    1.3.3、测试slave数据库宕机,master数据库正常写入,slave还原场景

    例如:在一个数据量写入非常庞大的环境当中,主从复制正在运行,突然从数据库意外宕机关机,主数据库还在不断的写入数据。如下:

    正常运行复制当中

    IO SQL正常读写

    slave强制关机

    主服务器无法到达从


    master使用批量插入10万行数据脚本

    此脚本为创建了一个test_yanzan的库创建了一张tb1_db的表,在其中插入10万行数据.

    # 批量插入: #!/bin/bash HOSTNAME="localhost" PORT="3306" USERNAME="root" PASSWORD="123123" DBNAME="test\_yanzan" TABLENAME="tb1\_db" #create database mysql -h ${HOSTNAME} -P${PORT} -u${USERNAME} -p${PASSWORD} -e "drop database if exists ${DBNAME}" create\_db\_sql="create database if not exists ${DBNAME}" mysql -h ${HOSTNAME} -P${PORT} -u${USERNAME} -p${PASSWORD} -e"${create\_db\_sql}" #create table create\_table\_sql="create table if not exists ${TABLENAME}(stuid int not null primary key,stuname varchar(20) not null,stusex char(1) not null,cardid varchar(20) not null,birthday datetime,entertime datetime,address varchar(100)default null)" mysql -h ${HOSTNAME} -P${PORT} -u${USERNAME} -p${PASSWORD} ${DBNAME} -e"${create\_table\_sql}" #insert data to table i="1" while [ $i -le 100000 ] do insert\_sql="insert into ${TABLENAME} values($i,'zhangsan','1','21276387261874682','1999-10-10','2017-10-24','beijingchangpingqu')" mysql -h ${HOSTNAME} -P${PORT} -u${USERNAME} -p${PASSWORD} ${DBNAME} -e"${insert\_sql}" let i++ done #select data select\_sql="select count(\*)from${TABLENAME}" mysql -h ${HOSTNAME} -P${PORT} -u${USERNAME} -p${PASSWORD} ${DBNAME} -e"${select\_sql}"

    总计插入时长:10分钟 配置低谨慎使用!启动slave服务器

    slave数据库启动后自动连接到主sql,读取新增日志信息进行同步操作。

    正常同步成功:

    1.3.4、测试master&slave同时宕机

    master & slave 启动后:

    可完全正常链接。

    1.3.5、MySQL主从复制的致命!操作!

    slave开启IO线程后向master发出请求,master为IO线程开启一个dump 线程用来传输二进制日志,随后IO线程将收到的日志信息以及节点信息存放到中继日志当中,SQL线程读取中继日志进行解析写入实现主从同步。 但当slave数据库上例如有db_users的库文件,此时当主创建slave已存在的db_users库会发生什么如下:

    查看从库slave状态

    Error 'Can't create database 'db_users'; database exists' on query. Default database: 'db_users'. Query: 'create database db_users'错误“无法创建数据库”db_users”;查询中存在“数据库”。默认数据库:“db_用户”。查询:“创建数据库db\u用户”.以上直接中断SQL线程的结果,提示已经存在某数据库,当我们没有设置mysql主从复制异常脚本时,如果出现此类现象没有任何报警,那么主数据库目前还正在写入数据,比如在此情况下继续在主数据库创建数据。

    发现从数据库报错信息没有改变,并且没有同步新的数据,这是因为刚刚主master创建的数据库与slave的数据库相互冲突的结果。 流程是:slave已经存在db_users的库,当master创建db_users库,通过传输最后到中继日志,随后sql线程读取中继日志中的create database db_users发现已经存在此库,于是报出已经存在的结果,这样的结果导致后续中继日志中的语句不断增加,因为IO线程正常运行不断接收binlog日志写入中继日志,但sql线程断开从此无法同步数据。

    解决办法:
    以上情况sql线程在执行中继日志中的创建db_users的命令冲突,有一个指令是可以让sql线程跳过此冲突指令如下:
    set GLOBAL sql_slave_skip_counter=1; 重新启动slave

    或者也可以 stop slave 执行语句 然后开启slave即可。

    同步成功


    如果执行完之后还是没有解决,或者继续报错,那就一直执行这条语句就可以了,直到解决问题。

    1.4、主从复制并不能减轻对数据库的压力

    slave并不能提高数据库的效率问题,当并发量写入数据读取数据比较庞大千万级别所有的压力都在master服务器上,master数据库一边要处理写入的数据,一边还要处理读取的数据,还要将binlog日志节点发送到slave的IO线程。太忙了… 因此主从复制是为了读写分离提供服务,这样就可以大大提高数据库的效率问题。

    二、MySQL读写分离|应用场景及原理

    2.1、应用场景

    当用户在应用层创建了一篇文章,通常是以insert插入形式,代表写入操作。调度中介服务器检测到用户是写入操作时,将用户的写入操作请求分发到master主数据库中,当用户要查询文章时,中介检测到查询操作,将查询操作分配到slave从数据库中运行。这样就实现了主从读写分离。

    中间的分配分发的服务器软件可以通过mysql-proxy来实现。

    2.2、MySQL-proxy

    mysql-proxy是mysql官方提供的mysql中间件服务,上游可接入若干个mysql-client,后端可连接若干个mysql-server。它使用mysql协议,任何使用mysql-client的上游无需修改任何代码,即可迁移至mysql-proxy上。mysql-proxy最基本的用法,就是作为一个请求拦截,请求中转的中间层:将客户端的请求分发到不同的数据库当中。

    2.3、MySQL-proxy部署安装

    master

    192.168.1.8

    slave

    192.168.1.7

    mysqlproxy

    192.168.1.6


    2.3.1、下载mysql-proxy

    官网:https://downloads.mysql.com/archives/proxy/#downloads

    或者:

    wget https://downloads.mysql.com/archives/get/p/21/file/mysql-proxy-0.8.5-linux-glibc2.3-x86-64bit.tar.gz

    我的mysqlproxy是centos7.2的操作系统

    2.3.2、解压mysql-proxy压缩包

    解压操作:

    [root@192 ~]# tar zxvf mysql-proxy-0.8.5-linux-glibc2.3-x86-64bit.tar.gz mysql-proxy-0.8.5-linux-glibc2.3-x86-64bit/ mysql-proxy-0.8.5-linux-glibc2.3-x86-64bit/licenses/ mysql-proxy-0.8.5-linux-glibc2.3-x86-64bit/licenses/glib-2.16.6-license.txt mysql-proxy-0.8.5-linux-glibc2.3-x86-64bit/licenses/libffi-3.0.12-license.txt mysql-proxy-0.8.5-linux-glibc2.3-x86-64bit/licenses/pcre-7.4-license.txt mysql-proxy-0.8.5-linux-glibc2.3-x86-64bit/licenses/glib-2.16.6/ mysql-proxy-0.8.5-linux-glibc2.3-x86-64bit/licenses/glib-2.16.6/glib-2.16.6-ia64-atomic.patch mysql-proxy-0.8.5-linux-glibc2.3-x86-64bit/licenses/glib-2.16.6/glib-2.16.6.tar.gz mysql-proxy-0.8.5-linux-glibc2.3-x86-64bit/licenses/glib-2.16.6/glib-2.16.6-win-cmake.patch mysql-proxy-0.8.5-linux-glibc2.3-x86-64bit/licenses/glib-2.16.6/glib-2.16.6-no-circular-dep.pat

    将解压出来的mysql-proxy-0.8.5-linux-glibc2.3-x86-64bi目录copy一份改名为,mysql-proxy.

    [root@192 ~]# ls anaconda-ks.cfg mysql-proxy-0.8.5-linux-glibc2.3-x86-64bit.tar.gz [root@192 ~]# tar zxf mysql-proxy-0.8.5-linux-glibc2.3-x86-64bit.tar.gz [root@192 ~]# ls anaconda-ks.cfg mysql-proxy-0.8.5-linux-glibc2.3-x86-64bit.tar.gz mysql-proxy-0.8.5-linux-glibc2.3-x86-64bit [root@192 ~]# mv mysql-proxy-0.8.5-linux-glibc2.3-x86-64bit /usr/local/mysql-proxy [root@192 ~]#

    2.3.3、配置mysqlproxy

    打开/etc/mysql-proxy.cnf文件输入以下信息:

    [mysql-proxy] # 运行mysql-proxy用户 user=root # mysql-proxy连接后端mysql服务器的用户 admin-username=mysql_proxy_user # mysql-proxy连接后端mysql服务器的密码 admin-password=pwd123 # 代理的监听地址端口,默认端口4040 proxy-address=0.0.0.0:4040 #指定后端主master写入数据 proxy-backend-addresses=192.168.1.8:3306 #指定后端从slave读取数据 proxy-read-only-backend-addresses=192.168.1.9:3306 #指定读写分离配置文件位置 proxy-lua-script=/usr/local/mysql-proxy/share/doc/mysql-proxy/rw-splitting.lua #日志位置 log-file=/usr/local/mysql-proxy/logs/mysql-proxy.log #定义log日志级别,由高到低分别有(error|warning|info|message|debug) log-level=debug #以守护进程方式运行 daemon=true #mysql-proxy崩溃时,尝试重启 keepalive=true

    以上设置了写入sql的服务器地址以及读取sql服务器地址信息. 在/usr/local/mysql-proxy/logs 这个logs目录如果没有需要手动创建!

    打开/usr/local/mysql-proxy/share/doc/mysql-proxy/rw-splitting.lua文件修改以下信息:

    原:

    if not proxy.global.config.rwsplit then proxy.global.config.rwsplit = { min_idle_connections = 4, max_idle_connections = 8, is_debug = false ![img]() ![img]() **网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。** **[需要这份系统化的资料的朋友,可以戳这里获取]()** **一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!** 改以下信息: 原:

    if not proxy.global.config.rwsplit then
    proxy.global.config.rwsplit = {
    min_idle_connections = 4,
    max_idle_connections = 8,

    is_debug = false

      你可能想看:

      扫描二维码推送至手机访问。

      版权声明:本文由皇冠云发布,如需转载请注明出处。

      本文链接:https://www.idchg.com/info/31514.html

      分享给朋友:

      “windows mysql 服务器 sql查询语句导致崩溃 mysql服务器发生宕机怎么办” 的相关文章

      中国电信CN2线路图解视频:解密高效网络通信的秘密

      在信息时代,网络通信的效率和稳定性直接影响着企业的运营和发展。对于跨国企业而言,如何实现高效、安全的跨国数据传输和语音通信,更是关乎企业核心竞争力的重要问题。而在中国电信CN2线路的助力下,这些难题迎刃而解。本文将通过图解视频和详细解析,为您全面解读中国电信CN2线路的技术优势和应用场景,带您领略高...

      VPN测评:2023年最佳VPN服务推荐及选择指南

      当我第一次接触VPN时,感觉这个概念既神秘又充满吸引力。VPN,全称为虚拟专用网络,它为用户提供了一种安全、私人上网的方式。不论是为了保护个人隐私,还是为了突破地域限制,VPN已经成为现代网上活动中不可或缺的工具。 我发现VPN有许多用途。首先,它能加密我的网络连接,让我的在线活动在网络上变得更加私...

      RackNerd与ColoCrossing的对比分析:选择适合你的数据中心服务

      RackNerd vs ColoCrossing概述 在当前的互联网服务市场中,RackNerd与ColoCrossing都是备受关注的数据中心服务提供商。它们各自的成长背景和市场定位都显示出一些显著的差异。RackNerd成立于2019年,专注于提供低价 VPS 和服务器租用服务,屡次推出吸引人的...

      如何选择合适的免费VPS服务并有效利用

      免费VPS概述 在研究云计算相关技术的时候,VPS(虚拟专用服务器)成了一个非常重要的概念。简单来说,VPS是一种通过虚拟化技术来划分的服务器,每个VPS都是独立的,用户可以获得与一个物理服务器类似的操作体验。作为个人开发者或中小企业的选择,VPS提供了灵活性和可控性,是许多人搭建网站或开发项目的理...

      RackNerd优惠活动详解:如何享受高性价比虚拟主机和VPS折扣

      RackNerd是一家在2019年成立的美国主机商。虽然成立时间不久,它却迅速在市场上崭露头角,赢得了许多VPS用户的青睐。公司的数据中心分别位于洛杉矶、圣何塞、西雅图和纽约等地,这些地理位置的选择让它的服务在各个区域都有稳定的覆盖。从我个人的体验来说,RackNerd的性价比非常高,尤其在价格和服...

      蘑菇云:自然与核爆炸的惊人现象及其深远影响

      蘑菇云这个词,一提起来让人既熟悉又敬畏。它的外形就像个倒立的蘑菇,顶部宽大、底部则较小,这是因为它源自于强大爆炸所产生的气体。这种云朵看似平常,却是一种强烈爆炸后气体与空气混合的结果。虽然蘑菇云在现代多被与核爆炸联系在一起,但实际上,火山喷发及一些天体撞击也可能产生自然形成的蘑菇云。 了解蘑菇云的形...