MySQL 中并非所有的数据库存储引擎都支持事务操作，比如 MyISAM 就不支持。所以，使用事务处理的时候一定要确定所操作的表示是否支持事务处理，可以通过查看建表语句来查看有没有指定事务类型的存储引擎。当然，事务处理是为了保障表数据原子性、一致性、隔离性、持久性。这些都需要消耗系统资源，请谨慎选择。
Zabbix监控Mysql | Mysql 5.7，8.0基准性能比较，Mysql8.0主主配置
上周五进行了一个大表删除的操作，在删除的过程中，出现了一点小问题，白白花费了两个小时，我这里记录了一下大概的过程，废话不多说了，直接看过程吧。
公司原有的架构：一个展示型的网站，LAMT，MySQL5.1.77版本（MYISAM），50M数据量。
MySQL 事务主要用于处理操作量大，复杂度高的数据。比方我想要删除一个用户（销户）以及这个用户的个人信息、订单信息以及其他信息，这里会涉及到很多SQL语句的执行来满足我们的业务需求，我们要一次性删除这些数据，这些数据库操作语句就构成了一个事务。
MySQL日志记录了MySQL数据库日常操作和错误信息。MySQL有不同类型的日志文件（各自存储了不同类型的日志），从日志当中可以查询到MySQL数据库的运行情况、用户的操作、错误的信息等。
今天这篇文章，是之前很早时候线上的一个案例，重新翻看的时候，觉得挺有意思，就再转发一遍。
该文摘要总结：通过分析Flume的日志，发现Flume在MySQL异常关闭的情况下不断提交事务，导致进入无限循环的抛出异常状态。通过查询MySQL的超时配置和HiveServer的日志，发现flume与MySQL之间的断开并非长期无交互，且人为关闭MySQL服务导致连接中断。权宜之计可以在sink的代码中提交事务出异常时，修改下sink的状态为BACK.OFF，防止不断打印日志造成机器磁盘满影响其他服务。
GTID即全局事务ID (global transaction identifier), 其保证为每一个在主上提交的事务在复制集群中可以生成一个唯一的ID。GTID最初由google实现，官方MySQL在5.6才加入该功能。mysql主从结构在一主一从情况下对于GTID来说就没有优势了，而对于2台主以上的结构优势异常明显，可以在数据不丢失的情况下切换新主。使用GTID需要注意: 在构建主从复制之前，在一台将成为主的实例上进行一些操作（如数据清理等），通过GTID复制，这些在主从成立之前的操作也会被复制到从服务器上，引起复制失败。也就是说通过GTID复制都是从最先开始的事务日志开始，即使这些操作在复制之前执行。比如在server1上执行一些drop、delete的清理操作，接着在server2上执行change的操作，会使得server2也进行server1的清理操作。
MySQL经过多年的改进和完善之后，已经基本具备了所有通用数据库管理系统所需要的相关功能。
类型：ext2 3 4 ，xfs 数据。 不管使用什么文件系统，数据内容不会变化，不同的是，存储空间、大小、速度。
开始使用： 默认情况下，MySQL数据库没有开启慢查询日志，需要我们手动来设置这个参数。 通过show variables like '%slow_query_log' 查看是否开启了慢查询日志
MySQL5.6加入了GTID的新特性，其全称是Global Transaction Identifier，可简化MySQL的主从切换以及Failover。GTID用于在binlog中唯一标识一个事务。当事务提交时，MySQL Server在写binlog的时候，会先写一个特殊的Binlog Event，类型为GTID_Event，指定下一个事务的GTID，然后再写事务的Binlog。主从同步时GTID_Event和事务的Binlog都会传递到从库，从库在执行的时候也是用同样的GTID写binlog，这样主从同步以后，就可通过GTID确定从库同步到的位置了。也就是说，无论是级联情况，还是一主多从情况，都可以通过GTID自动找到需要进行复制的点位，而无需像之前版本那样通过File_name和File_position来进行位置点的主从复制。
压测除了全链路压测外，有时候也需要对指定服务进行性能测试，这里以jmeter工具对数据库进行压测说明。
1、GTIDs（Global transaction identifiers）全局事务标识符，是mysql 5.6新加入的一项技术
问题：最近使用laravel的DB::transaction()方法进行事务操作时，发现事务总是无效的。代码如下：
MySQL主从复制包括异步模式、半同步模式、GTID模式以及多源复制模式，默认是异步模式 (如之前详细介绍的mysql主从复制)。所谓异步模式指的是MySQL 主服务器上I/O thread 线程将二进制日志写入binlog文件之后就返回客户端结果，不会考虑二进制日志是否完整传输到从服务器以及是否完整存放到从服务器上的relay日志中，这种模式一旦主服务(器)宕机，数据就可能会发生丢失。
记得前些日子分享过一篇有关MySQL中事务的知识点,但当时对MySQL中的事务只是纯粹的知道如何使用,缺乏对理论的进一步认识,抽时间单独去了解了一下,便在做一个较为全面的总结.
本篇文章只介绍 ZABBIX 数据库高可用的实现方式，ZABBIX前端的高可用将在后续文章中实现
在MySQL中，在MySQL 5.5.5版本之前默认的存储引擎为MyISAM，但是MyISAM引擎是不支持事务的，InnoDB才支持事务。可能有一些特殊情况导致使用MySQL 5.5.5之后版本的默认的存储引擎也为MyISAM，如果是这样，那么Spring事务便不会生效。可以在MySQL查询控制台中使用show engines;命令查看默认的存储引擎，比如：
「mysql数据库中日志是重要组成部分，记录着数据库运行期间各种状态信息」。主要有6类：
（1）基于Paxos协议和原生复制，多数节点同意即可通过事务提交； （2）具备高可用自动故障检测，可自动切换； （3）可弹性扩展，集群自动的新增和移除节点； （4）有单主和多主模式； （5）支持多节点写入，具备冲突检测机制，可以适应多种应用场景需求。
MySQL集群具备高可用、可扩展、以管理、低成本的特点。生产环境中MySQL部署会使用Mysql 主从架构或Mysql双主互备架构。同时采用keepalived来实现mysql的自动故障切换。两台Mysql服务器互为主从，但同一时刻只有一个Mysql服务器可读写，另一个Mysql服务器只能进行读操作，保证数据的一致性。MySQl主主同步就是两台机器互为主的关系，在任何一台机器上写入都会同步至备端。
例如：如果使用 Navicat、PHPMyAdmin 之类的可视化工具，可以直接点击转储 SQL 文件，或者导出 SQL 文件之类的功能。
事务&连接池 一.事务 1. 事务介绍 什么是事务 事务，一般是指要做的或所做的事情。在计算机术语中是指访问并可能更新数据库中各种数据项的一个程序执行单元。这些单元要么全都成功，要么全都不成功。 事务
Mysql复制（replication）是一个异步的复制，从一个Mysql 实例（Master）复制到另一个Mysql 实例（Slave）。实现整个主从复制，需要由Master服务器上的IO进程，和Slave服务器上的Sql进程和IO进程共从完成。要实现主从复制，首先必须打开Master端的binary log（bin-log）功能，因为整个 MySQL 复制过程实际上就是Slave从Master端获取相应的二进制日志，然后再在自己slave端完全顺序的执行日志中所记录的各种操作。（二进制日志几乎记录了除select以外的所有针对数据库的sql操作语句）
MySQL存储引擎介绍 文件系统 操作系统组织和存取数据的一种机制。 文件系统是一种软件。 文件系统类型 ext2 ext3 ext4 xfs 数据 不管使用什么文件系统，数据内容不会变化 不同的是，存储空间、大小、速度 MySQL引擎 可以将MySQL引擎理解为：MySQL的“文件系统”，只不过功能更加强大。 MySQL引擎的功能 除了可以提供基本的存取功能，还有更多功能事务功能、锁定、备份和恢复、优化以及特殊功能。 MySQL 提供以下存储引擎： – InnoDB – MyISAM – MEMOR
Binlog Load提供了一种使Doris增量同步用户在Mysql数据库的对数据更新操作的CDC(Change Data Capture)功能。针对MySQL数据库中的INSERT、UPDATE、DELETE、过滤Query支持，暂不兼容DDL（Data Definition Language）语句。
当单台 MYSQL 服务器无法满足当前网站流量时的优化方案。需要搭建 mysql 集群技术。
多年DBA工作，也遇到很多数据库疑难杂症，其处理和分析值得记录和分享，准备写一个系列文章，这是第1篇。
原因：1.数据安全问题，如果你将数据存贮在容器中，当容器rm后，你就无了，当然你可以使用外挂数据卷的方式，但我在某些大佬的文章上看到，即使你外挂的数据卷，docker volumes的设计是围绕union fs镜像层提供持久化存贮，如果容器异常崩溃，数据库未正常关闭，则可能损坏数据，而且外挂数据卷对物理机硬件损伤较大（这段话是我从大佬文章里抄的，但前面rm数据就不见了是我实践过的）
大家有没有想过为什么MySQL数据库可以实现主从复制，实现持久化，实现回滚的呢？其实关键在于MySQL里的三种log，分别是：
* GreatSQL社区原创内容未经授权不得随意使用，转载请联系小编并注明来源。 1、什么是主从延迟？ 本质是从库的回放跟不上主库，回放阶段的延迟
MySQL日志管理 错误日志 配置方法： vim /etc/my.cnf [mysqld] log-error=/tmp/mysql.log 查看配置方式： show variables like '%log%error%'; 作用： 记录mysql数据库的一般状态信息及报错信息，是我们对于数据库常规报错处理的常用日志。 一般查询日志 配置方法： vim /etc/my.cnf [mysqld] general_log=on general_log_file=/data/mysql/server2.log
一、日志类型： MySQL有几个不同的日志文件，可以帮助你找出mysqld内部发生的事情： 日志文件记入文件中的信息类型错误日志记录启动、运行或停止时出现的问题。查询日志记录建立的客户端连接和执行的语句。二进制日志记录所有更改数据的语句。主要用于复制和即时点恢复。慢日志记录所有执行时间超过long_query_time秒的所有查询或不使用索引的查询。事务日志记录InnoDB等支持事务的存储引擎执行事务时产生的日志。 默认情况下，所有日志创建于mysqld数据目录中。通过刷新日志，你可以强制 mysqld来
（1） 错误日志log_error：记录MySQL服务的启动、运行或停止MySQL服务时出现的问题
转：http://blog.csdn.net/qq394829044/article/details/53203645
MYSQL 8.018-9 已经上线了，下载了percona 的8.018-9 ，打开了官方的 show card。
在 MySQL 的实际使用中，常常会遇到一条 SQL 执行非常慢的情况，此前我们总结了一系列博客来排查相关的问题：
当用户AA向用户BB转账，就需要执行两个SQL语句，一个是用户AA减少100，另一个是用户BB增加100，SQL如下：
作为《手撕MySQL》系列的第三篇文章，今天讲解使用 bin log实现主从复制的功能。主从复制也是MySQL集群实现高可用、数据库读写分离的基石。因为是系列文章，上一篇文章中（传送门）我们已经介绍了在MySQL中查看 bin log的相关状态以及文件信息，并且借助 bin log（二进制日志）实现数据恢复的案例。因此在这篇文章中如有涉及相关知识，将不再赘述。
上述这个错误，接触 MySQL 的同学或多或少应该都遇到过，专业一点来说，这个报错我们称之为锁等待超时。
本文介绍了什么是MySQL、MySQL的发展历程、特性、应用场景、优缺点以及如何进行MySQL的入门学习。
MySQL是我们非常常用的关系型数据库，非常重要，所以在这里给大家整理下MySQL的基础内容。
上一篇发了MySQL主从复制集群搭建流程，不过好像小伙伴们对这个文章并不感兴趣，但是老哥出于对技术的热爱，和对小伙伴们的负责，我还是要写主从复制另一种实现方式：GTID。这些技术真的蛮重要的，希望你们能学习。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
即时通信 IM
ICP备案
对象存储
实时音视频
