数据库修改字段导致宕机

170614 23:28:56 [ERROR] Slave SQL: Error ‘Got error 64 ‘Temp file write failure‘ from InnoDB‘ on query. Default database: ‘loandb‘. Query: ‘ALTER TABLE ‘trd_loanapply DROP COLUMN LAP_SIGNRATE , Internal MariaDB error code: 1296

170614 23:28:56 [Warning] WSREP: RBR event 1 Query apply warning: 1, 127029889 –删除字段事物ID

170614 23:28:56 [Warning] WSREP: Ignoring error for TO isolated action: source: a2a9f28c-473e-11e7-828b-336b93b44447 version: 3 local: 0 state: APPLYING flags: 65 conn_id: 150694279 trx_id: -1 seqnos (l: 128890633, g: 127029889, s: 127029888, d: 127029888, ts: 24153881134314845)

170614 23:30:01 [ERROR] Slave SQL: Column 38 of table ‘loandb.trd_loanapply‘ cannot be converted from type ‘decimal(18,5)‘ to type ‘decimal(8,5)‘, Internal MariaDB error code: 1677

170614 23:30:01 [ERROR] Slave SQL: Column 38 of table ‘loandb.trd_loanapply‘ cannot be converted from type ‘decimal(18,5)‘ to type ‘decimal(8,5)‘, Internal MariaDB error code: 1677

170614 23:30:01 [Warning] WSREP: RBR event 2 Update_rows_v1 apply warning: 3, 127029985 --修改字段宽度事物ID

170614 23:30:01 [Warning] WSREP: RBR event 2 Update_rows_v1 apply warning: 3, 127029978 --修改字段宽度事物ID

170614 23:30:01 [Warning] WSREP: Failed to apply app buffer: seqno: 127029978, status: 1

at galera/src/trx_handle.cpp:apply():351

Retrying 2th time

170614 23:30:01 [Warning] WSREP: Failed to apply app buffer: seqno: 127029985, status: 1

at galera/src/trx_handle.cpp:apply():351

Retrying 2th time

170614 23:30:01 [ERROR] Slave SQL: Column 38 of table ‘loandb.trd_loanapply‘ cannot be converted from type ‘decimal(18,5)‘ to type ‘decimal(8,5)‘, Internal MariaDB error code: 1677

170614 23:30:01 [Warning] WSREP: RBR event 2 Update_rows_v1 apply warning: 3, 127029978

170614 23:30:01 [ERROR] Slave SQL: Column 38 of table ‘loandb.trd_loanapply‘ cannot be converted from type ‘decimal(18,5)‘ to type ‘decimal(8,5)‘, Internal MariaDB error code: 1677

170614 23:30:01 [Warning] WSREP: RBR event 2 Update_rows_v1 apply warning: 3, 127029985

170614 23:30:01 [Warning] WSREP: Failed to apply app buffer: seqno: 127029978, status: 1

at galera/src/trx_handle.cpp:apply():351

Retrying 3th time

170614 23:30:01 [ERROR] Slave SQL: Column 38 of table ‘loandb.trd_loanapply‘ cannot be converted from type ‘decimal(18,5)‘ to type ‘decimal(8,5)‘, Internal MariaDB error code: 1677

170614 23:30:01 [ERROR] Slave SQL: Column 38 of table ‘loandb.trd_loanapply‘ cannot be converted from type ‘decimal(18,5)‘ to type ‘decimal(8,5)‘, Internal MariaDB error code: 1677

170614 23:30:01 [ERROR] WSREP: Failed to apply trx 127029978 4 times        –修改字段宽度事物ID

170614 23:30:01 [ERROR] WSREP: Failed to apply trx 127029985 4 times        –修改字段宽度事物ID

170614 23:30:01 [ERROR] WSREP: Node consistency compromized, aborting...

170614 23:30:01 [ERROR] WSREP: Node consistency compromized, aborting...

170614 23:30:01 [Note] WSREP: Closing send monitor...

170614 23:30:01 [Note] WSREP: /usr/local/mysql/bin/mysqld: Terminated.  --导致数据库宕机

170614 23:30:02 mysqld_safe Number of processes running now: 0

170614 23:30:02 mysqld_safe WSREP: not restarting wsrep node automatically

170614 23:30:02 mysqld_safe mysqld from pid file /mysql/mysqld.pid ended

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------
分析上面的日志信息:---------------------------------------------------------------------------------------

删除字段的操作对应的事物ID:127029889修改字段宽度的操作的事物ID:127029978 、127029985 

---------------------------------------------------------------------------------------
导致数据库宕机的事物是:127029978 、127029985


 --------------------------------------------------------------------------------------

说明:1. 我们的上线脚本里是没有修改列宽的操作,并且也和XXX确认过最近没有修改列宽的操作,所以本次宕机和数据库上线操作无关。2. 本着优先保障业务正常运行的原则,我们优先对数据库进行和恢复,并对相关联的从节点进行了修复。3. 并在当晚将数据库临时文件系统指向大的文件系统,避免再次产生临时文件系统不足现象。

时间: 2024-08-03 21:14:21

数据库修改字段导致宕机的相关文章

weblogic out of space in CodeCache for adapters导致宕机

weblogic会莫名的宕机,宕机日志跟以往的不同: Caused By: java.lang.VirtualMachineError: out of space in CodeCache for adapters at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:141) at net.sf.jasperreports.engine.fill.JREvaluato

AZURE云上 mkfs.ext4 /dev/sdc 导致宕机问题解决纪实

1.mkfs.ext4后down机 Azure上新建的vm,准备安装oracle数据库,但是挂载的磁盘,初始化后,直接down机了,如下图,失去连接,xshell窗口直接断开退出了.看下面图片 021.png 尝试过一下办法: (1)      azure管理界面,重启vm,再来一遍,还是down机. (2)      删除这台vm,重建一台新的vm,还是一样只要执行mkfs.ext4 /dev/sdc直接down机. (3)      在别的区建vm,不在东区建在北区建,还是一样. 2.问题分

普通电脑运行Linux系统负载过重会导致宕机

生产环境: 硬件设备:普通电脑承担Linux服务器 操作系统:CentOS6.8 问题描述:7月16日发现无法访问Linux服务器,当时分析有可能出现两种情况: 1.普通电脑硬件故障,很有可能是长时间运行导致硬件故障,严重的来说是硬件烧坏了: 2.Linux系统运行当中出现问题. 通过种种原因分析排除了4种情况: 1.如果是断电了,但其他服务器运行正常: 2.如果是断网了,但其他服务器可以正常访问: 3.如果是web服务导致无法访问,但一般情况也来远程连接,可是无法远程连接: 4.通过理论上和长

SQL Server数据库修改字段属性

1:向表中添加字段 Alter table [表名] add [列名] 类型 2: 删除字段 Alter table [表名] drop column [列名] 3: 修改表中字段类型 (可以修改列的类型,是否为空) Alter table [表名] alter column [列名] 类型 4:添加主键 Alter table [表名] add constraint [ 约束名] primary key( [列名]) 5:添加唯一约束 Alter table [表名] add constrai

数据库修改字段的长度

POSTSQL修改列的长度:alter table km_wiki_urlForm alter COLUMN str11 type varchar(2000) ; Oracle修改列的长度:alter table km_wiki_urlForm modify(str11 nvarchar2(2000));SQLSERVER修改列的长度:Alter Table km_wiki_urlForm ALTER COLUMN str11 varchar(2000);

一例mysql主从数据库,从库宕机后无法启动的解决方案

启动时报错信息: Starting MySQL... ERROR! The server quit without updating PID file (/usr/local/mysql/data/qkzhi-appzookeeper-1.novalocal.pid). 2017-08-25T09:14:20.974876Z mysqld_safe mysqld from pid file        /usr/local/mysql/data/qkzhi-appzookeeper-2.nov

技术培训 | RAC 宕机罪犯案情探析之子游标

大家好,我是云和恩墨的李轶楠,不过网上的朋友更习惯叫我600,所以我也慢慢熟悉了这个称呼,其实这个称呼来自于ITPUB论坛上当时我注册的论坛ID"ORA-600",因为这个ID跟Oracle的著名错误号一样,很容易给大家留下深刻印象,所以被我借用了过来,呵呵.这些年通过论坛上认识了很多朋友,也结识了现在与我一起奋战的恩墨小伙伴们. 闲话不多说,我们来看看我们今天要分享的主题吧,这些年我们积累了大量的客户群体,也意味着我们面对着各种复杂的环境与事件,后续我会把我们小伙伴们所遭遇到的各种或

中亦科技黄远邦技术人生(16) ——红色警报--Oracle宕机潮来临,快快行动起来!

1 前言 2月14日,情人节前夕,某数据中心一套Oracle 11.2.0.4 RAC宕了! 隔了几天,又有一套RAC宕了! 几天后,紧接着又有一套RAC宕了... 作为运维的你,听到其他客户出现这样的宕机潮时,是不是心底会泛起一阵莫名的恐慌? 那么问题来了,贵司的数据中心到会不会也将出现类似的宕机潮呢? 这些故障是什么原因引起的呢? 这股宕机潮会继续疯狂延续下去么- 如果不能及时找到问题真相,那么小y相信,这股宕机潮还会继续延续下去! 贵中心的Oracle数据库也许正在越来越接近宕机了!可怕的

服务器寿命周期内只会关机一次,为什么能够长时间持续工作而不宕机?

首先,服务器能够长时间持续的工作是和其硬件架构及使用环境相关的. 排名第一中提到的火星探测器其实使用的也是IBM P series服务器,并且在探测器里搭载了两台,以实现HA冗余. 生活中的商用服务器为了能够达到用户的不间断持续高可用性的需求,往往都是要使用硬件或者软件层面的集群式配置以达到此方面需求. 从各个平台简单说下,一般的PC SERVER,既大量的存在商业服务器领域的windows或者linux服务器[还不清楚的话,简单来说就是cpu使用的是因特尔生产的],其可靠性是最差的,一年下来,