对于mysql主备实例，seconds_behind_master是衡量master与slave之间延时的一个重要参数。通过在slave上执行"show slave status;"可以获取seconds_behind_master的值。 ### 原始实现 Definition：The number of seconds that the slave SQL thread is behind processing the master binary log. Type：time_t（long） 计算方式如下： ``` rpl_slave.cc::show_slave_status_send_data() if ((mi->get_master_log_pos() == mi->rli->get_group_master_log_pos()) && (!strcmp(mi->get_master_log_name(), mi->rli->get_group_master_log_name()))) { if (mi->slave_running == MYSQL_SLAVE_RUN_CONNECT) protocol->store(0LL); else protocol->store_null(); } else { long time_diff = ((long)(time(0) - mi->rli->last_master_timestamp) - mi->clock_diff_with_master); protocol->store( (longlong)(mi->rli->last_master_timestamp ? max(0L, time_diff) : 0)); } ``` 主要分为以下两种情况： • SQL线程等待IO线程获取主机binlog，此时seconds_behind_master为0，表示备机与主机之间无延时； • SQL线程处理relay log，此时seconds_behind_master通过(long)(time(0) – mi->rli->last_master_timestamp) – mi->clock_diff_with_master计算得到； ### last_master_timestamp 定义： • 主库binlog中事件的时间。 • type: time_t (long) 计算方式： last_master_timestamp根据备机是否并行复制有不同的计算方式。 #### 非并行复制： ``` rpl_slave.cc:exec_relay_log_event() if ((!rli->is_parallel_exec() || rli->last_master_timestamp == 0) && !(ev->is_artificial_event() || ev->is_relay_log_event() || (ev->common_header->when.tv_sec == 0) || ev->get_type_code() == binary_log::FORMAT_DESCRIPTION_EVENT || ev->server_id == 0)) { rli->last_master_timestamp= ev->common_header->when.tv_sec + (time_t) ev->exec_time; DBUG_ASSERT(rli->last_master_timestamp >= 0); } ``` 在该模式下，last_master_timestamp表示为每一个event的结束时间，其中when.tv_sec表示event的开始时间，exec_time表示事务的执行时间。该值的计算在apply_event之前，所以event还未执行时，last_master_timestamp已经被更新。由于exec_time仅在Query_log_event中存在，所以last_master_timestamp在应用一个事务的不同event阶段变化。以一个包含两条insert语句的事务为例，在该代码段的调用时，打印出event的类型、时间戳和执行时间 ``` create table t1(a int PRIMARY KEY AUTO_INCREMENT ,b longblob) engine=innodb; begin; insert into t1(b) select repeat('a',104857600); insert into t1(b) select repeat('a',104857600); commit; ``` ``` 2020-02-10T06:41:32.628554Z 11 [Note] [MY-000000] [Repl] event_type: 33 GTID_LOG_EVENT 2020-02-10T06:41:32.628601Z 11 [Note] [MY-000000] [Repl] event_time: 1581316890 2020-02-10T06:41:32.628614Z 11 [Note] [MY-000000] [Repl] event_exec_time: 0 2020-02-10T06:41:32.628692Z 11 [Note] [MY-000000] [Repl] event_type: 2 QUERY_EVENT 2020-02-10T06:41:32.628704Z 11 [Note] [MY-000000] [Repl] event_time: 1581316823 2020-02-10T06:41:32.628713Z 11 [Note] [MY-000000] [Repl] event_exec_time: 35 2020-02-10T06:41:32.629037Z 11 [Note] [MY-000000] [Repl] event_type: 19 TABLE_MAP_EVENT 2020-02-10T06:41:32.629057Z 11 [Note] [MY-000000] [Repl] event_time: 1581316823 2020-02-10T06:41:32.629063Z 11 [Note] [MY-000000] [Repl] event_exec_time: 0 2020-02-10T06:41:33.644111Z 11 [Note] [MY-000000] [Repl] event_type: 30 WRITE_ROWS_EVENT 2020-02-10T06:41:33.644149Z 11 [Note] [MY-000000] [Repl] event_time: 1581316823 2020-02-10T06:41:33.644156Z 11 [Note] [MY-000000] [Repl] event_exec_time: 0 2020-02-10T06:41:43.520272Z 0 [Note] [MY-011953] [InnoDB] Page cleaner took 9185ms to flush 3 and evict 0 pages 2020-02-10T06:42:05.982458Z 11 [Note] [MY-000000] [Repl] event_type: 19 TABLE_MAP_EVENT 2020-02-10T06:42:05.982488Z 11 [Note] [MY-000000] [Repl] event_time: 1581316858 2020-02-10T06:42:05.982495Z 11 [Note] [MY-000000] [Repl] event_exec_time: 0 2020-02-10T06:42:06.569345Z 11 [Note] [MY-000000] [Repl] event_type: 30 WRITE_ROWS_EVENT 2020-02-10T06:42:06.569376Z 11 [Note] [MY-000000] [Repl] event_time: 1581316858 2020-02-10T06:42:06.569384Z 11 [Note] [MY-000000] [Repl] event_exec_time: 0 2020-02-10T06:42:16.506176Z 0 [Note] [MY-011953] [InnoDB] Page cleaner took 9352ms to flush 8 and evict 0 pages 2020-02-10T06:42:37.202507Z 11 [Note] [MY-000000] [Repl] event_type: 16 XID_EVENT 2020-02-10T06:42:37.202539Z 11 [Note] [MY-000000] [Repl] event_time: 1581316890 2020-02-10T06:42:37.202546Z 11 [Note] [MY-000000] [Repl] event_exec_time: 0 ``` #### 并行复制： ``` rpl_slave.cc mts_checkpoint_routine ts = rli->gaq->empty() ? 0 : reinterpret_cast<Slave_job_group *>(rli->gaq->head_queue())->ts; rli->reset_notified_checkpoint(cnt, ts, true); /* end-of "Coordinator::"commit_positions" */ ``` 在该模式下备机上存在一个分发队列gaq，如果gaq为空，则设置last_commit_timestamp为0；如果gaq不为空，则此时维护一个checkpoint点lwm，lwm之前的事务全部在备机上执行完成，此时last_commit_timestamp被更新为lwm所在事务执行完成后的时间。该时间类型为time_t类型。 ``` ptr_group->ts = common_header->when.tv_sec + (time_t)exec_time; // Seconds_behind_master related rli->rli_checkpoint_seqno++; ``` ``` if (update_timestamp) { mysql_mutex_lock(&data_lock); last_master_timestamp = new_ts; mysql_mutex_unlock(&data_lock); } ``` 在并行复制下，event执行完成之后才会更新last_master_timestamp，所以非并行复制和并行复制下的seconds_behind_master会存在差异。 ### clock_diff_with_master 定义： • The difference in seconds between the clock of the master and the clock of the slave (second - first). It must be signed as it may be 0. clock_diff_with_master is computed when the I/O thread starts; for this the I/O thread does a SELECT UNIX_TIMESTAMP() on the master. • type: long ``` rpl_slave.cc::get_master_version_and_clock() if (!mysql_real_query(mysql, STRING_WITH_LEN("SELECT UNIX_TIMESTAMP()")) && (master_res= mysql_store_result(mysql)) && (master_row= mysql_fetch_row(master_res))) { mysql_mutex_lock(&mi->data_lock); mi->clock_diff_with_master= (long) (time((time_t*) 0) - strtoul(master_row[0], 0, 10)); DBUG_EXECUTE_IF("dbug.mts.force_clock_diff_eq_0", mi->clock_diff_with_master= 0;); mysql_mutex_unlock(&mi->data_lock); } ``` 该差值仅被计算一次，在master与slave建立联系时处理。 ### 其他 #### exec_time 定义： • the difference from the statement’s original start timestamp and the time at which it completed executing. • type: unsigned long ``` struct timeval end_time; ulonglong micro_end_time = my_micro_time(); my_micro_time_to_timeval(micro_end_time, &end_time); exec_time = end_time.tv_sec - thd_arg->query_start_in_secs(); ``` #### 时间函数 （1）time_t time(time_t timer) time_t为long类型，返回的数值仅精确到秒； （2）int gettimeofday (struct timeval *tv, struct timezone *tz) 可以获得微秒级的当前时间； （3）timeval结构 ``` #include <time.h> stuct timeval { time_t tv_sec; /*seconds*/ suseconds_t tv_usec; /*microseconds*/ } ``` ### 总结 使用seconds_behind_master衡量主备延时只能精确到秒级别，且在某些场景下，seconds_behind_master并不能准确反映主备之间的延时。主备异常时，可以结合seconds_behind_master源码进行具体分析。

目前mysql的镜像只同步了download目录，没有同步yum和apt目录： https://repo.mysql.com/mysql的官方仓库地址是有yum和apt支持的，希望考虑同步yum和apt目录

（1）前言        今天来和大家聊聊MySQL的复制演进过程，熟悉MySQL的同学应该都知道什么是MySQL复制mysql，关于这块知识网络上也有各种材料，笔者查找过很多资料，发现很多材料都描述得不够全面，光看单篇文章难以建立整体概念，因此梳理了一版浅显全面的文章出来，帮助大家轻松读懂MySQL复制演进过程。        言归正传，一直以来，MySQL的主从复制都常常被大家诟病，总结原因有以下几点：        1. 主从复制速度问题(这是最主要的)        mysql采取的复制方式是，主机执行提交之后将语句记录进binlog，备机启动一个IO线程从主传输binlog到本地，进入本地的relaylog；然后备机会另外启动一个SQL线程负责顺序执行relaylog中的语句，对语句在备机上重做，所以说这是一个异步的拷贝过程。这样会导致一个问题，就是备机数据大部分情况下会延后。主机对本地磁盘的IO、备机从主机传输的网络IO、备机本地的磁盘IO、最后备机重放数据的IO，经过了四个过程，即使服务器和网络配置都很快，理论上也一定是有延迟的；如果服务器和网络配置有瓶颈，这个延迟就会扩大化到影响业务的程度，最直接的就是读写分离的情况下，导致前端写入操作明明已经返回完成了，后端读数据时却显示没有完成。        2. 主机宕机切换后脏数据问题        mysql的主备目的之一，就是在主宕机的情况下，能及时切换到备机继续提供服务，不至于整个系统挂掉，即故障转移。但就是因为主从复制要经过复制这一消耗IO的步骤，主在挂掉的一瞬间，一般主备机都会有一定量的数据区别，这些在主机执行完毕了但还未传输到备机上的数据，就是所谓的脏数据。这样的脏数据，同样会导致前后不一致，如果服务器和网络配置不高，本来同步复制就慢的情况下，会导致极大的差别。                2009年oracle公司收购了sun，对mysql进行升级换代之后，有了巨大的改进，在5.5、5.6、5.7版本都针对主从有升级改造，在目前的5.7版本达到了非常高的可用性，配合最新的HA中间件mysql fabric，可以达到以前的几倍的稳定性。下面来详细讲一讲这三个版本中，oracle都对主从具体做了什么改进。（2）MySQL5.5版本        1. 5.5版本添加了一个semi-sync replication（半同步复制）的插件，这个插件就是为了优化同步复制的脏数据问题而生的。        2. 半同步复制在提交过程中增加了一个延迟，在提交事务后，只有在备库收到了该事务的binlog时才会给客户端进行查询结束的反馈。这会给客户端查询体验增加一些延迟，不过问题不大，因为相对于写入硬盘的时间，通过网络传输些日志的时延不算什么。重要的是，半同步复制不会阻塞事务的提交，而是阻塞在给客户端的反馈；当备库一直没有回应已收到事件，主库会超时并转化成正常的异步复制模式。        3. 顺带提一下半同步复制简单原理：在传输binlog时，要求备机返回ack证明自己拿到了数据，在至少一个备机返回ack后，主机才将数据修改提交到本地，这样能保证至少一个备机和主机是完全一致的。        4. 再举个例吧：当在主机上持续不断insert数据时，始终有一部分数据处在传输到备机的过程中，这部分数据在主机上已经是执行成功的状态，但因为还没传输完成收到任何一台备机的回应，所以尚未持久化。这个瞬间主机宕机了，数据传输不完，备机的回应也收不到了，主机重启后，主机上的这部分数据因为没有收到回应进行持久化，所以消失了。而备机上的这部分数据因为尚未接收完全，也不能作为一个relaylog提交执行，所以备机也没有这部分数据。最终的结果就是，这部分脏数据就被丢弃了，不会造成主从的不一致。        5. 优点：保证至少一个备机和主机在任何时候都是一致的，不会出现你比我多或者我比你多的情况，不需要进行主从恢复后的数据恢复行为。在只有一主一从的情况下，整个系统永远不会有脏数据。        6. 缺点：显而易见的，一主多备的情况下，除了只有一台备机的情况外，其他备机都会有数据不一致现象。另外，没有成功传输的数据就被直接丢弃了，找都找不回来，如果涉及金融交易，瞬时的数据丢失也是不可原谅的，所以这种架构在数据重要度非常高的业务里不能用。（3）MySQL5.6版本        1. 5.6版本对主从同步进行了改进，加入了GTID（5.6.2开始，5.6.10完善）的事务区分标志，又加入了多线程复制和组提交的新模式。        2. GTID：在MySQL5.6以前对于主从复制出现问题有时候需要分析BINLOG找到POS点，然后再CHANG MASTER TO。容易犯错，造成主从复制错误。引入GTID后,不需要再寻找BINLOG和POS点，只需要知道MASTER的IP、密码、端口就可以，MySQL会从内部GTID机制自动找到同步点。加入GTID后，一是可以根据GTID可以知道事务最初是在哪个实例上提交的，二是GTID的存在也方便了Replication的Failover。        3. GTID原理：分成两部分，一部分是服务的UUID，保存在mysql数据目录的auto.cnf文件中，这是一个非常重要的文件，不能删除，这一部分是不会变的。另外一部分就是事务ID（TID）了，随着事务的增加，其值依次递增。        4. 多线程并发复制：在MySQL5.6之前，复制是单线程队列式的,只能一个一个运行。在新版中支持基于库的多线程复制，但是库里的表不能多线程。针对多个库的情况，开启多线程，每个库一个独立IO线程，可以交叉并发传输。在不同库同一时间进行的操作理论上是互不影响的，可以同步进行，你改你的，我改我的。极大改善了多库业务的复制速度。贴个经典的图。                5. 5.6的并行复制框架实际包含了一个协调线程和若干个工作线程，协调线程负责分发和解决冲突，工作线程只负责执行。        6. 但是多线程并发复制也不一定完全有效，其并行只是基于schema的，也就是基于库的。如果用户的MySQL数据库实例中存在多个schema，对于备机复制的速度的确可以有比较大的帮助。但如果业务始终只有一个库，或者数据库压力都集中在一个库上，其他库基本没什么操作，那针对库的多线程基本没有意义，还是和以前的单线程复制是一样的速度。所以说MySQL 5.6所谓的并行复制对真正用户来说，有点雷声大雨点小。        7. 组提交：极大提升了binlog和innodb的redolog的落盘（保存到磁盘）效率，可将多次磁盘IO可以合并成一次磁盘IO，减少读写次数，有效提高了写日志的速度。也就意味着在主从同步过程中，磁盘IO这一块的效率提高了。        8. 组提交的原理：多个事务同时执行完成，数据需要持久化到log中时，会全部进入一个待提交队列。最先进入队列的事务线程成为leader线程，其他后续进入的成为follower线程，leader线程将会获得这个队列的控制权，就是会获得一个锁，全权负责本次队列中所有事务的落盘操作。接着联系其他follower线程，将他们的提交内容获取得到，并让他们等待自己完成操作。接着这个leader线程会进入后续的落盘过程，等完成后，会通知本队列中所有follower线程落盘已经完成，可以返回成功状态了。（4）MySQL5.7版本        1. MySQL 5.6基于库的并行复制出来后，基本无人问津，在沉寂了一段时间之后，MySQL 5.7出来了，它的并行复制以一种全新的姿态出现在用户面前。MySQL 5.7才可称为真正的并行复制，这其中最为主要的原因就是slave服务器的回放与master是一致的，即master服务器上是怎么并行执行的，那么slave上就怎样进行并行回放。不再有库的并行复制限制，对于binlog格式也无特殊的要求（基于库的并行复制也没有要求）。        2. 5.7之所以被看作mysql主从复制上一个划时代的版本，主要原因是mysql将日志组提交的模式应用到了主从网络IO上，在原来已经通过组提交优化了的磁盘IO效率基础上，对网络IO效率进行了同样的优化，正是将困扰mysql主从复制多年的两大难题解决的最重要版本。官方称之为Enhanced Multi-Threaded Slave（简称MTS）。        3. MTS这么牛，再多点一下：增强的多线程复制，即通过备机开启多个IO线程，主机通过组提交的模式并行地传输事务进行复制。具体思想简单易懂，一言以蔽之：一个组提交的事务都是可以并行回放的，若这些事务都已进入到事务的prepare阶段，则说明事务之间没有任何冲突（否则就不可能提交），关于MTS的详细原理和实现，可以查阅资料详细学习一下，这里点到为止。        4. 但是前面提到的网络IO是有先后顺序的，和传输顺序通常是不同的，收到事务后需要区分先后顺序来执行，否则备机执行顺序和主机不同，数据同样会出错。获取事务先后顺序的方法也很简单，就是使用的MYSQL 5.6已经加入的GTID，因为每个事务在提交时已经按顺序生成了唯一的GTID，备机读到事务后按照GTID的顺序执行就可以了。        5. 在这样的模式下，从机可以同时消费主机的多个事务队列，在同一时间接收到更多的数据传输，有效降低了数据来不及传输而导致的宕机数据丢失的概率。        6.最后提一个问：MySQL5.7是如何识别哪些事务是要一起提交的呢？        其实就是在GTID event 中增加了两个字段：int64 last committed和int64 sequence number,同一个组提交里多个事务gtid不同，但last committed却是一致的，同时一个组里的last committed对应上一个事务的sequence number。当slave的coordinator线程在分发这些event的时候，具有相同last committed 的事务(event的集合)就可以同时发送给不同的work线程，达到并行同步的目的。        总结一下，MySQL复制演进历程大致可以概括为：从5.5的单线程复制，到5.6基于Schema级别的并行复制，再到5.7最大化还原主库的支持事务级别的并行复制。其实总体来看其发展是有连贯的前因后果的，大致了解MySQL复制的来龙去脉之后，再去抠细节会清晰许多。

1、前言&软件需求1、本文档TaiShan 2280 V2基于硬件环境展开。2、本文档基于新安装的SUSE 15SP1系统环境展开。3、系统安装时选择了Development Tools套件。4、已关闭系统防火墙。5、/home分区大小≥50G1.1、软件需求列表软件包名称软件版本获取地址mysql-8.0.16.tar.gz8.0.16https://cdn.mysql.com/archives/mysql-8.0/mysql-8.0.16.tar.gz mysql-boost8.0.16.tar.gz8.0.16https://cdn.mysql.com/archives/mysql-8.0/mysql-boost-8.0.16.tar.gzSLE-15-SP1-Packages-aarch64-GM-DVD1.iso15SP1www.suse.comSLE-15-SP1-Installer-DVD-aarch64-GM-DVD1.iso15SP1www.suse.com  2、zypper 源配置1、 通过SFTP工具上传SLE-15-SP1-Packages-aarch64-GM-DVD1.iso 到/software2、 以root用户登录Linux系统，挂载上传的镜像文件。（命令如下）mount  -o   loop  /software/SLE-15-SP1-Packages-aarch64-GM-DVD1.iso  /mnt1、    配置本地zypper源路径zypper ar file:///mnt local_sles2、    执行zypper lr 查看配置结果3、安装依赖组件1、 执行以下命令安装依赖组件zypper install *gcc*zypper install m4zypper instal makezypper install bisonzypper install gmp-develzypper install cmakezypper install firewalldzypper install ncurseszypper install ncurses-develzypper install libaio-develzypper install opensslzypper install openssl-devel zypper install gmp zypper install gmp-devel zypper install mpfr zypper install  mpfr-develzypper install libmpczypper install libmpc-devel2、 验证gcc&glibc版本gcc  -vldd –-version4、Mysql 8.0.16安装1、前提条件       已完成依赖组件的安装，并验证版本。。2、上传软件包至/homemysql-8.0.16.tar.gz8.0.16https://cdn.mysql.com/archives/mysql-8.0/mysql-8.0.16.tar.gzmysql-boost8.0.16.tar.gz8.0.16https://cdn.mysql.com/archives/mysql-8.0/mysql-boost-8.0.16.tar.gz3、执行以下命令进行依赖包补全4、创建数据文件目录（本文以sdb举例）mkfs.xfs /dev/sdbcd /mkdir datamount /dev/sdb /data3、 编辑fstab添加以下条目，保存退出。Vi /etc/fstab4、 创建mysql用户、用户组及文件目录groupadd mysqluseradd -g mysql mysqlmkdir -p /data/mysql-8.0.16/mysqlcd /data/mysql-8.0.16/mysqlmkdir data tmp run logchown -R mysql:mysql /data/mysql-8.0.16/mysql5、 解压Mysql源码。cd /hometar -zxvf mysql-8.0.16.tar.gztar -zxvf mysql-boost-8.0.16.tar.gz6、 编译安装Mysqlwhereis gcc （查看gcc路径）cd /home/mysql-8.0.16cmake . -DCMAKE_INSTALL_PREFIX=/home/mysql-8.0.16/mysql -DMYSQL_DATADIR=/data/mysql-8.0.16/mysql -DSYSCONFDIR=/etc -DWITH_INNOBASE_STORAGE_ENGINE=1 -DWITH_PARTITION_STORAGE_ENGINE=1 -DWITH_FEDERATED_STORAGE_ENGINE=1 -DWITH_ARCHIVE_STORAGE_ENGINE=1 -DWITH_BLACKHOLE_STORAGE_ENGINE=1 -DWITH_MYISAM_STORAGE_ENGINE=1 -DENABLED_LOCAL_INFILE=1 -DENABLE_DTRACE=0 -DDEFAULT_CHARSET=utf8mb4 -DDEFAULT_COLLATION=utf8mb4_general_ci -DWITH_EMBEDDED_SERVER=1 -DCMAKE_C_COMPILER=/usr/bin/gcc -DDOWNLOAD_BOOST=1 -DWITH_BOOST=/home/mysql-8.0.16/boost/boost_1_69_0 -DFORCE_INSOURCE_BUILD=1在编译安装的时候，路径要根据实际情况而定，下表为对编译安装的关键路径的解释：DCMAKE_INSTALL_PREFIX用于指定软件的安装路径。本次安装路径为：/home/mysql-8.0.16DMYSQL_DATADIR创建数据库时，数据文件存放的路径。本次安装路径为：/data/mysql-8.0.16/mysqlDCMAKE_C_COMPILER安装gcc的存放路径，如果在安装gcc没有指定路径的情况下，一般默认存放在/usr/local/bin目录下，可使用whereis gcc查看具体路径。DWITH_BOOST解压的mysql安装压缩包中boost_1_69_0文件夹所在路径。例如，本文解压在/home目录下，则路径为：/home/mysql-8.0.17/boost/boost_1_69_0完成后如下图：make -j 40make install7、 增加环境变量vim /etc/profile在文件尾部加入以下字段export PATH=/home/mysql-8.0.16/mysql/bin:$PATH其中PATH中的/home/mysql-8.0.16/mysql/bin路径，为mysql软件安装目录下的bin文件的绝对路径10、使用source命令生效环境变量source /etc/profile5、Mysql初始化1、前提条件       已完成数据库安装。2、创建Mysql配置文件       cd /etc       touch my.cnf3、编辑my.cnf文件，其中文件路径（包括软件安装路径、数据日志存放路径等）根据实际情况修改。       vi    /etc/my.cnf[mysqld_safe]log-error=/data/mysql-8.0.16/mysql/log/mysql.logpid-file=/data/mysql-8.0.16/mysql/run/mysqld.pid[mysqldump]quick[mysql]no-auto-rehash[client]socket=/data/mysql-8.0.16/mysql/run/mysql.sock[mysqld]basedir=/home/mysql-8.0.16/mysql  （数据库软件安装的全路径）tmpdir=/data/mysql-8.0.16/mysql/tmpdatadir=/data/mysql-8.0.16/mysql/datasocket=/data/mysql-8.0.16/mysql/run/mysql.sockport=3306user=root[client]socket=/data/mysql-8.0.16/mysql/run/mysql.sockdefault-character-set=utf84、初始化数据库（注意记录密码）/home/mysql-8.0.16/mysql/bin/mysqld --defaults-file=/etc/my.cnf --initialize --basedir=/home/mysql-8.0.16/mysql --datadir=/data/mysql-8.0.16/mysql/data --user=mysql5、启动数据库服务chmod 777 /home/mysql-8.0.16/mysql/support-files/mysql.servercp /home/mysql-8.0.17/mysql/support-files/mysql.server /etc/init.d/mysqlchmod 777 /etc/init.d/mysqlchkconfig --add mysqlservice mysql start 如果启动时出现 mysql is neither service nor target!?使用systemctl unmask mysql.service然后再运行 service mysql startsystemctl status mysql6、登录数据mysql -uroot -p  密码参考初始化数据库章节。7、修改账户密码和相关参数alter user 'root'@'localhost' identified by "123456";   ——修改本地root用户登录密码create user 'root'@'%' identified by '123456';      ——创建全域root用户(允许root从其他服务器访问)grant all privileges on *.* to 'root'@'%';     ——进行授权flush privileges;

公司一些数据库开始出现不规律的OOM（ “out of memory” ，超出内存空间，即内存不足。），好几次出现业务不可用场景，而且时长都超过半小时，莫着急，小编今天带您快速了解， MySQL数据库频繁出现OOM问题该如何化解。大神：你把7天以内的内存使用历史记录说一下。小明：这7天的内存持续增高。大神：首先，你使用MySQL自身提供的performance_schema，分析哪块内存区域消耗最大且持续增长；其次，看看最近是否有业务变更，以及新模块涉及的语句是什么。小明：大神，根据你的建议，我们找到一个重大突破口，发现这么一个问题：表数量较大（1w+），innodb memory持续增长，慢语句中发现大量重复频繁元数据查询语句。大神：自建数据库绝大部分环境都会忽略掉一个设置，即内存管理器使用系统自带的glibc库，在一些情况下内存存在持续增长并达到最大值，而且很长时间内不会释放一个潜在问题。如果表数量较大，且频繁查询元数据会造成内存碎片无法及时清理，并最终导致系统出现OOM。小明：纳尼，还有这种情况，我这就去查查。出问题的数据库确实是这么一个组合： MySQL数据库某分支版本+安装采用系统自带内存管理器+一个新模块上线+不定期的查询元数据，综合导致了OOM问题。大神：OOM问题在数据运维中经常会出现，影响较大，需要规避，而华为云数据库MySQL很好地做到了这一点。它不是简单的将数据库服务化，而是采用了jemalloc内存管理器，不存在内存回收问题，且内存管理性能更优；同时内核对innodb_buffer_pool_size进行了内控，可以避免用户设置超过实际物理内存的失误，这也是华为云数据库稳定背后的一个细节体现。小明：听起来很腻害的样子！我得赶紧试一下。大神：华为云数据库将操作系统、数据库版本、数据库默认设置、内核优化形成一个组合呈现给用户，让用户即开即用，简单省心。像4s店提车一样，可以立马上路。小明：问题已解决，客户系统运行稳定，华为云数据库MySQL真牛！不过，是否还会有复发的风险呢？大神：华为云数据库MySQL会给用户提供合理的默认设置，但OOM的另外一个关键在于“怎么用”，这里我给你一个锦囊妙计，你可以根据以下公式来推算和配置数据库合适的总内存，这样可以避免了OOM问题。小明：太好了，以后可以少加班了。大神：认准华为云数据库MySQL，化解OOM不在话下，高效安全又可靠。 以上是供应商-华为云为您整理的MySQL数据库频繁出现OOM问题该如何化解，您可以在云社区参与讨论，也可前往华为云帮助中心：云数据库 MySQL了解更详细的解答。

https://mp.weixin.qq.com/s?__biz=MzA5MjM5OTYzNA==&mid=2247483901&idx=3&sn=c19fee4b9ddccb76773c4fc6233a0c6e&chksm=906cf080a71b79967a8918ff4d2d370a0d5382693acc12d7ff92da3b66e1bb135ffb28659f58&token=109181865&lang=zh_CN#rd

https://mp.weixin.qq.com/s?__biz=MzA5MjM5OTYzNA==&mid=2247483901&idx=2&sn=f5e0fc947179320529c1511c0e1cb794&chksm=906cf080a71b7996b158ba9f5dcf979e1a01a5cc754e323a3ea73a967b95dfdd19400b0516e2&token=109181865&lang=zh_CN#rd

新得一年，小云妹我又带着数据库的新知识来了，实例性能不断提升，升级必须安排上。云数据库 RDS for MySQL支持自动和手动升级内核小版本啦，详细操作，云图说为您详解~云数据库 RDS for MySQL介绍页入口：https://www.huaweicloud.com/product/mysql.html云数据库 RDS for MySQL成长地图入口：https://support.huaweicloud.com/rds/index.html【往期回顾】●【第一期】初始华为云关系型数据库RDS●【第二期】万万没想到，云数据库MySQL原来是这样的！●【第三期】这些购买云数据库MySQL的技能实用到哭，你确定不来看看？●【第四期】云数据库MySQL一键实现弹性扩展是种什么样的体验？●【第五期】太给力了！认识云数据库PostgreSQL只需要这三步●【第六期】这才是云数据库SQL Server正确的打开方式●【第七期】数据库的私人医生——云DBA●【第八期】小云妹带你快速玩转关系型数据库实例操作（一）●【第九期】小云妹带你快速玩转关系型数据库实例操作（二）

我们知道MySQL有四种不同的隔离级别，分别是：read-uncommit、read-commit、repeat-read和serializable。这四种隔离级别分别解决了不同的数据一致性问题，也存在不同的问题。 可以通过MySQL的下列参数来设置不同的隔离级别： ``` transaction-isolation = {READ-UNCOMMITTED | READ-COMMITTED | REPEATABLE-READ | SERIALIZABLE} ``` ### read-uncommitted 该隔离级别下允许一个事务读取到其它事务未提交的写操作，比如下面事务trx 1在t2时刻读到了事务trx 2的修改结果，但是事务trx2并没有提交，我们称这种现象为脏读。脏读对事务 没有任何意义，我们应该尽量的避免 ``` a=1; trx 1 -------------------- trx 2 begin; begin; (t1) select a; -> a==1 update a=2; (t2) select a; -> a==2 rollback commit; ``` ### read-committed 此隔离级别下解决了事务的脏读问题, 比如下面事务trx 2在t2时刻已经将a修改为2但没有提交，事务trx 1读到的仍然是a=1。在t3时刻事务trx2提交了修改，事务trx1读到了修改的结果a==2。 ``` a=1; trx 1 -------------------- trx 2 begin; begin; (t1) select a; -> a==1 update a=2; (t2) select a; -> a==1 commit; (t3) select a; -> a==2 commit; ``` 虽然read-committed解决了脏读的问题，但是依然存在幻读的问题。如下所示，初始时a有两条记录（1,10），t2时刻事务2**了一条a=5的记录但是没有提交，事务1读到的是（1,10）两条记录。 在t3时刻事务2已经提交，此时事务1读到的是（1,5,10）3条记录。此问题被称为幻读，也称做不可重复读。 ``` a=（1，10）; trx 1 -------------------- trx 2 begin; begin; (t1) select a>0; -> a==（1，10） insert a=5; (t2) select a>0; -> a==（1，10） commit; (t3) select a>0; -> a==（1，5，10） commit; ``` ### repeated-read 该隔离级别下解决了脏读和幻读的问题，如下t2时刻事务2**了一条a=5的记录但是没有提交，事务1读到的是（1,10）两条记录。在t3时刻事务2已经提交，此时事务1依然读到的是（1,10）2条记录 ``` a=（1，10）; trx 1 -------------------- trx 2 begin; begin; (t1) select a>0; -> a==（1，10） insert a=5; (t2) select a>0; -> a==（1，10） commit; (t3) select a>0; -> a==（1，10） commit; ``` 该隔离级别存在的问题是lost update，该问题的发送场景如下： ``` a=1; trx 1 -------------------- trx 2 begin; begin; (t1) @val1 = select a; -> @val1==1 (t2) @val2 = select a; -> @val2==1 set a=@val2+1; (t3) commit; --> a=2 set a=@val1+2; (t4) commit; --> a=3 ``` t1，t2时刻事务trx1、trx2分别读到了a为1，t3时刻事务2将它修改成a+1=2并行提交，t4时刻事务1将它修改成a+2=3。最终a的值为3，为事务1的修改结果，事务2的修改结果就丢失了。这种情况 称为lost update。 ### serializable 该隔离级别下很好的解决了lost udpate的问题，上面同样的两个事务执行过程如下： ``` a=1; trx 1 -------------------- trx 2 begin; begin; (t1) @val1 = select a; -> @val1==1 (t2) @val2 = select a; // block阻塞 set a=@val1+2; (t3) commit; --> a=3 @val2==3 set a=@val2+1; (t4) commit; --> a=4 ``` 如上所示，t2时刻事务2读取a的值是发生了阻塞等待，因为此时事务1正在读取a的值。直到t3时刻事务1提交完成，事务2才能读到a的值，结果为@val2==3，是事务1的修改结果。接下来事务2将它修改 成a+1=4。事务1和事务2对a的修改都最终体现在了a的终值上面。 ### 总结： MySQL提供了四种不同的隔离级别，分别是：read-uncommit、read-commit、repeated-read和serializable，后三种隔离级别分别结果了脏读、幻读、lost update的问题。虽然serializable解决了全部 的问题，但是实际运行时它的性能是最差的。所以日常生产环境中我们一般使用read-commit、repeated-read两种隔离级别，既能解决一些严重的不一致问题又能保持MySQL比较高的性能。

随着数据上云进程的加快，越来越多企业愿意把云下数据库搬到云上，同时对云上数据库的要求也越来越高。尤其是数据的完整可靠，承载着企业业务持续发展的使命，其重要性不言而喻。而企业在云上使用过程中，事务经常面临丢失的风险，可靠性和完整性得不到满足，很大程度上影响了企业的业务发展。针对这个问题，华为云数据库MySQL高可靠的应用机制能够保证事务不丢失，进而保证企业业务的稳定发展。部分云厂商为了保证事务不丢失，而选择增加一个数据库结点的方式，从而成本也上升了。华为云数据库MySQL高可靠特性介绍华为云数据库MySQL 高可靠特性是华为云数据库团队精心推出的重大功能特性，基于主备模式下在最大程度保证主库效率的同时，保证主库崩溃时快速恢复服务，并且做到事务零丢失，进而保证企业业务的稳定持续。主备模式是现今RDS  for MySQL最为流行的部署形态，通常采用半同步复制。华为云数据库MySQL半同步复制凭借高可靠特性能够精准判断主库崩溃时的复制状态，并根据主库崩溃时的复制状态自行准确恢复服务，很好地保障了数据的高可靠性。华为云数据库MySQL保证数据高可靠的秘诀精准判断主库崩溃时的复制状态 华为云数据库MySQL半同步复制基于状态通道和时间戳的高可靠特性，总体上是管控节点（HA）保存主库最后的复制状态和时间戳，备实例保存主库最后的复制状态和时间戳，然后通过比较它们来精准判断主库崩溃时的复制状态。根据主库崩溃状态自行恢复服务 华为云数据库MySQL半同步复制状态下绝大多数情况是同步复制状态，极少数情况下（如执行大事务时）会转换到异步复制状态，然后自动转换回同步复制状态。而现在华为云数据库半同步复制凭借高可靠特性能够精准判断主库崩溃时的复制状态，并根据主库崩溃时的复制状态按照以下四种情况准确恢复服务：在同步复制状态下主库崩溃，拉起主库，保证不丢失事务，并且秒级恢复服务。l   在同步复制状态下主库崩溃，如果不能拉起主库，服务平滑切换到备库，保证不丢失事务，并且秒级恢复服务。l   在异步复制状态下主库崩溃，不能切换到备库，拉起主库，保证不丢失事务，并且秒级恢复服务。l   在异步复制状态下主库崩溃后，不能切换到备库，如果不能拉起主库，会在原来的数据上恢复主库，保证不丢失事务，并且分钟级恢复服务。华为云数据库MySQL半同步复制高可靠特性能最大程度保证主库效率，是因为主库的事务提交只依赖于备库，而备库把这个事务写入中继日志后立即返回一个ACK（即确认字符），没有强同步复制备库回放事务带来的延迟。场景应用机房掉电 当用户购买了华为云数据库MySQL，其主库所在的机房掉电，主库挂掉，用户服务被中断时，华为云数据库MySQL凭借高可靠特性可以使服务在秒级内平滑切换到备库，用户可以重新连接上华为云数据库，并且做到服务与中断前的数据视图完全一致，没有任何事务丢失。执行大事务时数据库挂掉 当用户购买的华为云数据库MySQL半同步复制主库正在执行大事务，并且复制状态从同步复制转换到异步复制时，主库突然挂掉，用户服务被迫中断，华为云数据库MySQL主库会在秒级内被拉起对外提供服务，用户可以重新连接上华为云数据库，并且与中断前的数据视图完全一致，没有事务丢失。华为云数据库MySQL半同步复制高可靠特性不仅能够保证事务不丢失, 而且能够保证秒级恢复服务（极端情况下，分钟级恢复服务），从而确保主备数据的一致性，保障企业数据的高可靠，为企业发展保驾护航，同时也是践行华为云数据库致力于打造企业级数据和最强数据底座的有力体现。

近日，华为云数据库MySQL8.0正式发布商用，这也使得华为云成为国内最先支持MySQL8.0的云厂商之一。MySQL8.0作为最新的MySQL版本，有许多重大更新：默认utf8mb4，全新 Data Dictionary 设计，支持 Atomic DDL，全新的版本升级策略，安全和账号管理加强，InnoDB 功能增强等，目前小版本已经 release 到8.0.19，新的功能仍在持续推出。华为云MySQL 8.0由华为云内核团队精心打造，完全兼容社区版MySQL8.0，除了具备官方的全新功能外，还针对华为云用户的特殊使用场景，做了特性增强和质量加固，为用户提供更优的功能和服务，助力客户业务更稳定快速发展。华为云MySQL8.0特性除了安全加固之外，华为云MySQL8.0还做了性能、诊断、易用性等方面的优化。1.线程池在用户高并发业务场景下保证实例的QPS维持在一个稳定的高水平线，不会衰减。2.审计日志方便用户审计业务的同时，尽量降低对业务的性能损耗。优化后2U4G、4U8G、8U16G、16U32G四种规格的机器开启审计后性能下降6.5%，3.31%，3.33%，2.96%左右，对比优化前，性能优化效果在3%-5%左右。3.支持表级别MTS支持表级复制，高并发性能更好。4.新增表和索引级别的统计更加方便数据空间管理。5.回滚段信息统计用于诊断长事务回滚段积压场景。6.Session级CPU和内存开销统计用于诊断session的资源消耗。7.事务超时新增 kill_idle_transaction_timeout 参数，以便对超时的事务连接进行 kill，防止事务长时间未提交带来的系统风险。8.安全特性针对 SSL 链路，静态编译了OpenSSL 1.1.1 版本。华为云MySQL8.0与社区版MySQL5.7性能测试对比以上数据均在同一运行条件下测试得出。由此可见，华为云MySQL8.0在高并发、高访问等高负载情况下表现优异，性能强大。适用更多场景IoT场景华为云MySQL8.0凭借强大的高并发高性能和全面兼容社区版MySQL的有力优势，为物联网应用提供了高吞吐量和支持快速响应，非常适合要求苛刻的物联网应用。电商应用全面增强的半同步协议可为电子商务和移动商务应用程序提供可靠且经济高效的数据存储，使电商应用在网络上快速安全地运行。游戏应用全新增强的主从复制，有效解决了数据复制延迟问题，助力游戏行业轻松部署移动在线服务，提供更加顺畅的游戏体验。此次华为云数据库团队推出的MySQL 8.0版本，是一次朝企业级需求与功能上的改进和优化，更加关注用户场景体验，设计出更贴近企业级用户的功能和服务，也是华为云数据库致力于打造最强数据底座的有力体现。近期，华为云数据库特别推出了免费专区活动，MySQL与DDS免费试用2个月，更多活动详情请戳：https://activity.huaweicloud.com/free_test/index.html华为开发者大会2020（Cloud）是华为面向ICT（信息与通信）领域全球开发者的年度顶级旗舰活动。大会旨在搭建一个全球性的交流和实践平台，开放华为30年积累的ICT技术和能力，以“鲲鹏+昇腾”硬核双引擎，为开发者提供澎湃动力，改变世界，变不可能为可能。我们期待与你共创计算新时代在一起，梦飞扬！

  日志出现clean时，不执行下一步，web页面显示服务器错误，请问这是表示什么错误？？

将此路径拷贝到浏览器中，也不能下载此源码包

编译环境： 类别子项版本下载地址 硬件CPU鲲鹏920--网络Ethernet-10GE--存储SATA 1T--内存512G 2400MHz--OSKylin7.6--Kernel4.14--软件OpenJDK1.8.0_181OS自带Gcc7.3.0link

华为云数据库MySQL提供一键开通读写分离功能，只需要一个连接地址，让您在业务高峰期不再迷茫，不再慌乱，轻松应对业务需求。什么是读写分离？读写分离是指通过一个读写分离的连接地址实现读写请求的自动转发。通过RDS的读写分离连接地址，写请求自动访问主实例，读请求按照读权重设置自动访问各个只读实例。什么时候使用读写分离？在对数据库有少量写请求，但有大量读请求的应用场景下，单个实例可能无法抵抗读取压力，甚至对主业务产生影响。为了实现读取能力的弹性扩展，分担数据库压力，您可以在某个区域中创建一个或多个只读实例，利用只读实例满足大量的数据库读取需求，以此增加应用的吞吐量。开通读写分离功能注意: 您拥有主备实例4U8G以上，1个只读实例即可开通读写分离功能。1.   登录管理控制台。2.   单击管理控制台左上角的，选择区域和项目。3.   选择“数据库 > 云数据库 RDS”。进入云数据库 RDS信息页面。4.   在实例列表中，单击目标实例的名称，进入实例的“基本信息”页面。5.   在左侧导航栏中，单击“读写分离”。您还可以在实例的“基本信息”页面，单击“连接信息”模块“读写分离地址”后的“申请”，跳转到“读写分离”页面。通过读写分离地址，可以快速实现读写分离访问，简单、高效、便携。如何设置阈值和权重开通读写分离功能后，您可以根据需要设置读写分离的延迟阈值和读权重分配。延时阈值只读实例同步主实例数据时允许的最长延迟时间。为避免只读实例读取的数据长时间和主实例不一致，当一个只读实例的延迟时间超过设置的延迟阈值，则不论该只读实例的读权重是多少，读请求都不会转发至该只读实例。读写分离功能成功开启后，延时阈值默认为30s，阈值默认范围为0~7200s，建议该阈值不小于30s，超出阈值的只读实例不分配流量。读权重分配读写分离功能成功开启后，主实例的读权重默认为0，可以修改；只读实例可以设置读权重。实例的读权重越高，处理的读请求越多。例如，假设主实例有4个只读实例，实例的读权重分别为0、100、200、500、300，则表示主实例不处理读请求（写请求仍然自动发往主实例），四个只读实例按照1：2：5：3的比例处理读请求。开通读写分离功能后，系统将根据只读实例的规格默认分配权重，后续新增只读实例也将按照默认规则分配权重。华为云数据库一键开通读写分离功能后，还可以快速弹性扩展，几分钟便可以完成只读实例的添加，且最多可以增加10个只读实例。轻松应对各类业务场景，助力企业服务创新升级。了解更多，请戳我...