面试

Posted on | Edited on | In | Views: ℃
alt

好男人就是我, 我就是好男人！
我就是王杰民 ^_^

能说说你们这个业务的逻辑以及数据库怎么设计吗？

答：

在工作中遇到过的难点问题有哪些？能说说代表性几个吗？

答：

MySQL 异地冗灾怎么做？

答：

###业务数据增长量是多少G，数据库怎么监控数据增长量？

答：

分库分表逻辑简单说下？增量怎么解决？

答：

kafka会丢数据吗？为什么回丢数据？

答：

会丢数据

MySQL 备份怎么做？ 备份校验怎么做？

答：

使用中间件之后的架构，数据库的事务是什么样子的？与程序直接链接数据库使用的事务区别是什么？

答：

之前分表了16张，在使用一定时间够发现16张表已经不满足了，那怎么扩容，扩容之后数据怎么同步过来？

答：

程序中的名词 线程和协程各是什么意思？

答：

有没有看过MySQL源码？那主从同步的底层是怎么实现的？底层的网络传输模式是什么样子的？

答：

innobackupex比冷拷贝的优势是什么？

答：

数据库的RC和RR事务级别区别是什么？

答：

MySQL 的 SQL审核怎么做？

答：

监控怎么做的？都监控哪些指标？

答：

系统怎么优化？

答：

MySQL GTID复制时候，发生问题，快速解决。为何不用找binlog file number和 binlogbposition点。就能直接change master to NewMaster ？

答：

工作中出现故障，你的判断处理思路是什么？

答：

服务器机器突然死机重启，怎么排查问题？

答：

统计一个log日志文件中，最后一个字段是手机号，取手机号的最后四位数字统计出现的次数，倒序现实打印出来。

答：

MySQL 半同步会丢数据吗？

答：

MySQL 主从原理，是主推送binlog还是从获取binlog？

答：

怎么做才能保证MySQL 不丢数据？

答：

MySQL IBP中的LRU的原理

答：

ph-ost 实现原理

答：

pt-osc和gh-ost 的区别

答：

MHA 架构中有没有做二次开发？MHA有什么缺点？在使用MHA架构，网络抖动了发生切换了怎么办？怎么防止这个问题发生？

答：

MySQL 清除三个小时的binlog？

答：

1
mysql> PURGE MASTER LOGS BEFORE DATE_SUB(NOW(), INTERVAL 3 HOUR);

MySQL binlog文件里面都有什么内容？

答：

binlog由一系列的binlog event构成。每个binlog event包含header和data两部分。
  • header部分提供的是event的公共的类型信息，包括event的创建时间，服务器等等。
  • data部分提供的是针对该event的具体信息，如具体数据的修改
    • 从mysql5.0版本开始，binlog采用的是v4版本，第一个event都是format_desc event 用于描述binlog文件的格式版本，这个格式就是event写入binlog文件的格式。关于之前版本的binlog格式，可以参见binary-log-versions
      接下来的event就是按照上面的格式版本写入的event
      最后一个rotate event用于说明下一个binlog文件。
      binlog索引文件是一个文本文件，其中内容为当前的binlog文件列表。比如下面就是一个mysql-bin.index文件的内容。
      接下来分析下几种常见的event，其他的event类型可以参见官方文档。
  • format_desc event
    • 下面是我在FLUSH LOGS之后新建的一个全新的binlog文件mysql-bin.000053，从binlog第一个event也就是format_desc event开始分析

      前面4个字节是固定的magic number,值为0x6e6962fe。接着是一个format_desc event，先看下19个字节的header。这19个字节中前4个字节0x567fb2b8是时间戳，第5个字节0x0f是event type，接着4个字节0x00000004是server_id，再接着4个字节0x00000067是长度103，然后的4个字节0x0000006b是下一个event的起始位置107，接着的2个字节的0x0001是flag（1为LOG_EVENT_BINLOG_IN_USE_F，标识binlog还没有关闭，binlog关闭后，flag会被设置为0），这样4+1+4+4+4+2=19个字节的公共头就完了(extra_headers暂时没有用到)。然后是这个event的data部分，event的data分为Fixed data和Variable data两部分，其中Fixed data是event的固定长度和格式的数据，Variable data则是长度变化的数据，比如format_desc event的Fixed data长度是0x54=84个字节。下面看下这84=2+50+4+1+27个字节的分配：开始的2个字节0x0004为binlog的版本号4，接着的50个字节为mysql-server版本，如我的版本是5.5.46-0ubuntu0.14.04.2-log，与SELECT version();查看的结果一致。接下来4个字节是binlog创建时间，这里是0；然后的1个字节0x13是指之后所有event的公共头长度，这里都是19；接着的27个字节中每个字节为mysql已知的event（共27个）的Fixed data的长度；可以发现format_desc event自身的Variable data部分为空。

  • rotate event
    • 接着我们不做额外操作，直接FLUSH LOGS，可以看到一个rotate event，除了format_desc event的flag从0x0001变成了0x0000。然后从0x567fb3c2开始是一个rotate event。依照前面的分析，前面19个字节为event的header，其event type是0x04，长度为0x2b=43，下一个event起始位置为0x96=150，然后是flag为0x0000，接着是event data部分，首先的8个字节为Fixed data部分，记录的是下一个binlog的位置偏移4，而余下来的43-19-8=16个字节为Variable data部分，记录的是下一个binlog的文件名mysql-bin.000054。对照mysqlbinlog -vv mysql-bin.000053可以验证。
  • query event
    • 刷新binlog，设置binlog_format=statement，创建一个表CREATE TABLEtt(ivarchar(100) DEFAULT NULL) ENGINE=InnoDB, 然后在测试表tt中插入一条数据insert into tt values(‘abc’)，会产生3个event，包括2个query event和1个xid event。其中2个query event分别是BEGIN以及INSERT 语句，而xid event则是事务提交语句（xid event是支持XA的存储引擎才有的，因为测试表tt是innodb引擎的，所以会有。如果是myisam引擎的表，也会有BEGIN和COMMIT,只不过COMMIT会是一个query event而不是xid event）。
    • 抛开format_desc event，从0000006b开始分析第一个query event。头部跟之前的event一样，只是query event的type为0x02，长度为0x44=64，下一个event位置为0xaf=175。flag为8，接着是data部分，从format_desc event我们可以知道query event的Fixed data部分为13个字节，因此也可以算出Variable data部分为64-19-13=32字节。
      • Fixed data：首先的4个字节0x00000026为执行该语句的thread id，接下来的4个字节是执行的时间0(以秒为单位)，接下来的1个字节0x04是语句执行时的默认数据库名字的长度，我这里数据库是test，所以长度为4.接着的2个字节0x0000是错误码（注：通常情况下错误码是0表示没有错误，但是在一些非事务性表如myisam表执行INSERT…SELECT语句时可能插入部分数据后遇到duplicate-key错误会产生错误码1062，或者是事务性表在INSERT…SELECT出错不会插入部分数据，但是在执行过程中CTRL+C终止语句也可能记录错误码。slave db在复制时会执行后检查错误码是否一致，如果不一致，则复制过程会中止）,接着2个字节0x001a为状态变量块的长度26。
      • Variable data：从0x001a之后的26个字节为状态变量块（这个暂时先不管），然后是默认数据库名test，以0x00结尾，然后是sql语句BEGIN，接下来就是第2个query event的内容了。
    • 第二个query event与第一个格式一样，只是执行语句变成了insert into tt values(‘abc’)。
    • 第三个xid event为COMMIT语句。前19个字节是通用头部，type是16。data部分中Fixed data为空，而variable data为8个字节，这8个字节0x000000008a是事务编号（注意事务编号不一定是小端字节序，因为是从内存中拷贝到磁盘的，所以这个字节序跟机器相关）。
      • 0x0000006b-0x000000ae为query event，语句是BEGIN,前面已经分析过。
  • table_map event
    • 0x0000000af开始为table_map event。除去头部19个字节，Fixed data为8个字节，前面6个字节0x32=50为table id，接着2个字节0x0001为flags。
    • Variable data部分，首先1个字节0x04为数据库名test的长度，然后5个字节是数据库名test+结束符。接着1个字节0x04为表名长度，接着5个字节为表名trow+结束符。接着1个字节0x02为列的数目。而后是2个列的类型定义，分别是0x03和0x0f（列的类型MYSQL_TYPE_LONG为0x03，MYSQL_TYPE_VARCHAR为0x0f)。接着是列的元数据定义，首先0x02表示元数据长度为2，因为MYSQL_TYPE_LONG没有元数据，而MYSQL_TYPE_VARCHAR元数据长度为2。接着的0x000a就是MYSQL_TYPE_VARCHAR的元数据，表示我们在定义表时的varchar字段c长度为10，最后一个字节0x02为掩码，表示第一个字段i不能为NULL。关于列的类型以及元数据等更详细的信息可以参见官方资料
  • write_rows event
    • 从0x000000dd开始为write_rows event，除去头部19个字节，前6个字节0x32也是table id，然后两个字节0x0001为flags。接着的1个字节0x02为表中列的数目。然后1个字节0xff各个bit标识各列是否存在值，这里表示都存在。
    • 接着的就是插入的各行数据了。第1个字节0xfe的各个bit标识该行变化之后各列是否为NULL，为NULL记为1.这里表示第1列不为NULL，因为第一行数据插入的是(1,NULL)。接下来是各列的数据，第一列是MYSQL_TYPE_LONG,长度为4个字节，所以0x00000001就是这个值。第二列是NULL不占字节。接下来是第二行，先是0xfc标识两列都不为NULL，先读取第一列的4个字节0x00000002也就是我们插入的数字2，然后读取第二列，先是一个字节的长度0x01，然后是内容0x61也就是字符’a’。到此，write_rows event也就分析完了。rows相关的event还有update_rows event和delete_rows event等，欲了解更多可以参见官方文档。
  • intvar event
    • intvar event在binlog_format=statement时使用到，用于自增键类型auto_increment，十分重要。intval event的Fixed data部分为空，而Variable data部分为9个字节，第1个字节用于标识自增事件类型 LAST_INSERT_ID_EVENT = 1 or INSERT_ID_EVENT = 2，余下的8个字节为自增ID。
创建一个测试表 create table tinc (i int auto_increment primary key, c varchar(10)) engine=innodb;，然后执行一个插入语句INSERT INTO tinc(c) values(‘abc’);就可以看到intvar event了，这里的自增事件类型为INSERT_ID_EVENT。而如果用语句INSERT INTO tinc(i, c) VALUES(LAST_INSERT_ID()+1, ‘abc’)，则可以看到自增事件类型为LAST_INSERT_ID_EVENT的intvar event。

参考资料为官方资料

数据库加锁是什么样的流程？

答：

表级锁定（table-level）
* 表级别的锁定是MySQL各存储引擎中最大颗粒度的锁定机制。该锁定机制最大的特点是实现逻辑非常简单，带来的系统负面影响最小。所以获取锁和释放锁的速度很快。由于表级锁一次会将整个表锁定，所以可以很好的避免困扰我们的死锁问题。当然，锁定颗粒度大所带来最大的负面影响就是出现锁定资源争用的概率也会最高，致使并大度大打折扣。使用表级锁定的主要是MyISAM，MEMORY，CSV等一些非事务性存储引擎。
行级锁定（row-level）
* 行级锁定最大的特点就是锁定对象的颗粒度很小，也是目前各大数据库管理软件所实现的锁定颗粒度最小的。由于锁定颗粒度很小，所以发生锁定资源争用的概率也最小，能够给予应用程序尽可能大的并发处理能力而提高一些需要高并发应用系统的整体性能。虽然能够在并发处理能力上面有较大的优势，但是行级锁定也因此带来了不少弊端。由于锁定资源的颗粒度很小，所以每次获取锁和释放锁需要做的事情也更多，带来的消耗自然也就更大了。此外，行级锁定也最容易发生死锁。使用行级锁定的主要是InnoDB存储引擎。
页级锁定（page-level）
* 页级锁定是MySQL中比较独特的一种锁定级别，在其他数据库管理软件中也并不是太常见。页级锁定的特点是锁定颗粒度介于行级锁定与表级锁之间，所以获取锁定所需要的资源开销，以及所能提供的并发处理能力也同样是介于上面二者之间。另外，页级锁定和行级锁定一样，会发生死锁。在数据库实现资源锁定的过程中，随着锁定资源颗粒度的减小，锁定相同数据量的数据所需要消耗的内存数量是越来越多的，实现算法也会越来越复杂。不过，随着锁定资源颗粒度的减小，应用程序的访问请求遇到锁等待的可能性也会随之降低，系统整体并发度也随之提升。使用页级锁定的主要是BerkeleyDB存储引擎。
总的来说，MySQL这3种锁的特性可大致归纳如下：
  • 表级锁：开销小，加锁快；不会出现死锁；锁定粒度大，发生锁冲突的概率最高，并发度最低；
  • 行级锁：开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低，并发度也最高；
  • 页面锁：开销和加锁时间界于表锁和行锁之间；会出现死锁；锁定粒度界于表锁和行锁之间，并发度一般。
    适用：从锁的角度来说，表级锁更适合于以查询为主，只有少量按索引条件更新数据的应用，如Web应用；而行级锁则更适合于有大量按索引条件并发更新少量不同数据，同时又有并发查询的应用，如一些在线事务处理（OLTP）系统。
    InnoDB锁定模式及实现机制
    InnoDB的行级锁定同样分为两种类型，共享锁和排他锁，而在锁定机制的实现过程中为了让行级锁定和表级锁定共存，InnoDB也同样使用了意向锁（表级锁定）的概念，也就有了意向共享锁和意向排他锁这两种。当一个事务需要给自己需要的某个资源加锁的时候，如果遇到一个共享锁正锁定着自己需要的资源的时候，自己可以再加一个共享锁，不过不能加排他锁。但是，如果遇到自己需要锁定的资源已经被一个排他锁占有之后，则只能等待该锁定释放资源之后自己才能获取锁定资源并添加自己的锁定。而意向锁的作用就是当一个事务在需要获取资源锁定的时候，如果遇到自己需要的资源已经被排他锁占用的时候，该事务可以需要锁定行的表上面添加一个合适的意向锁。如果自己需要一个共享锁，那么就在表上面添加一个意向共享锁。而如果自己需要的是某行（或者某些行）上面添加一个排他锁的话，则先在表上面添加一个意向排他锁。意向共享锁可以同时并存多个，但是意向排他锁同时只能有一个存在。所以，可以说InnoDB的锁定模式实际上可以分为四种：共享锁（S），排他锁（X），意向共享锁（IS）和意向排他锁（IX），我们可以通过以下表格来总结上面这四种所的共存逻辑关系： 如果一个事务请求的锁模式与当前的锁兼容，InnoDB就将请求的锁授予该事务；反之，如果两者不兼容，该事务就要等待锁释放。
意向锁是InnoDB自动加的，不需用户干预。对于UPDATE、DELETE和INSERT语句，InnoDB会自动给涉及数据集加排他锁（X)；对于普通SELECT语句，InnoDB不会加任何锁；事务可以通过以下语句显示给记录集加共享锁或排他锁。
    1
    2
    共享锁（S）：SELECT * FROM table_name WHERE ... LOCK IN SHARE MODE
    排他锁（X)：SELECT * FROM table_name WHERE ... FOR UPDATE
用SELECT … IN SHARE MODE获得共享锁，主要用在需要数据依存关系时来确认某行记录是否存在，并确保没有人对这个记录进行UPDATE或者DELETE操作。
但是如果当前事务也需要对该记录进行更新操作，则很有可能造成死锁，对于锁定行记录后需要进行更新操作的应用，应该使用SELECT… FOR UPDATE方式获得排他锁。

InnoDB行锁实现方式
InnoDB行锁是通过给索引上的索引项加锁来实现的，只有通过索引条件检索数据，InnoDB才使用行级锁，否则，InnoDB将使用表锁
在实际应用中，要特别注意InnoDB行锁的这一特性，不然的话，可能导致大量的锁冲突，从而影响并发性能。下面通过一些实际例子来加以说明。
（1）在不通过索引条件查询的时候，InnoDB确实使用的是表锁，而不是行锁。
（2）由于MySQL的行锁是针对索引加的锁，不是针对记录加的锁，所以虽然是访问不同行的记录，但是如果是使用相同的索引键，是会出现锁冲突的。
（3）当表有多个索引的时候，不同的事务可以使用不同的索引锁定不同的行，另外，不论是使用主键索引、唯一索引或普通索引，InnoDB都会使用行锁来对数据加锁。
（4）即便在条件中使用了索引字段，但是否使用索引来检索数据是由MySQL通过判断不同执行计划的代价来决定的，如果MySQL认为全表扫描效率更高，比如对一些很小的表，它就不会使用索引，这种情况下InnoDB将使用表锁，而不是行锁。因此，在分析锁冲突时，别忘了检查SQL的执行计划，以确认是否真正使用了索引。
3.间隙锁（Next-Key锁）
当我们用范围条件而不是相等条件检索数据，并请求共享或排他锁时，InnoDB会给符合条件的已有数据记录的索引项加锁；
对于键值在条件范围内但并不存在的记录，叫做“间隙（GAP)”，InnoDB也会对这个“间隙”加锁，这种锁机制就是所谓的间隙锁（Next-Key锁）

nnoDB使用间隙锁的目的：
  1. 防止幻读，以满足相关隔离级别的要求。对于上面的例子，要是不使用间隙锁，如果其他事务插入了empid大于100的任何记录，那么本事务如果再次执行上述语句，就会发生幻读；
  2. 为了满足其恢复和复制的需要。
    • 很显然，在使用范围条件检索并锁定记录时，即使某些不存在的键值也会被无辜的锁定，而造成在锁定的时候无法插入锁定键值范围内的任何数据。在某些场景下这可能会对性能造成很大的危害。
    • 除了间隙锁给InnoDB带来性能的负面影响之外，通过索引实现锁定的方式还存在其他几个较大的性能隐患：
      • 当Query无法利用索引的时候，InnoDB会放弃使用行级别锁定而改用表级别的锁定，造成并发性能的降低；
      • 当Query使用的索引并不包含所有过滤条件的时候，数据检索使用到的索引键所只想的数据可能有部分并不属于该Query的结果集的行列，但是也会被锁定，因为间隙锁锁定的是一个范围，而不是具体的索引键；
      • 当Query在使用索引定位数据的时候，如果使用的索引键一样但访问的数据行不同的时候（索引只是过滤条件的一部分），一样会被锁定。
        因此，在实际应用开发中，尤其是并发插入比较多的应用，我们要尽量优化业务逻辑，尽量使用相等条件来访问更新数据，避免使用范围条件。
        还要特别说明的是，InnoDB除了通过范围条件加锁时使用间隙锁外，如果使用相等条件请求给一个不存在的记录加锁，InnoDB也会使用间隙锁。
        通常来说，死锁都是应用设计的问题，通过调整业务流程、数据库对象设计、事务大小，以及访问数据库的SQL语句，绝大部分死锁都可以避免。下面就通过实例来介绍几种避免死锁的常用方法：
      • 在应用中，如果不同的程序会并发存取多个表，应尽量约定以相同的顺序来访问表，这样可以大大降低产生死锁的机会。
      • 在程序以批量方式处理数据的时候，如果事先对数据排序，保证每个线程按固定的顺序来处理记录，也可以大大降低出现死锁的可能。
      • 在事务中，如果要更新记录，应该直接申请足够级别的锁，即排他锁，而不应先申请共享锁，更新时再申请排他锁，因为当用户申请排他锁时，其他事务可能又已经获得了相同记录的共享锁，从而造成锁冲突，甚至死锁。
      • 在REPEATABLE-READ隔离级别下，如果两个线程同时对相同条件记录用SELECT…FOR UPDATE加排他锁，在没有符合该条件记录情况下，两个线程都会加锁成功。程序发现记录尚不存在，就试图插入一条新记录，如果两个线程都这么做，就会出现死锁。这种情况下，将隔离级别改成READ COMMITTED，就可避免问题。
      • 当隔离级别为READ COMMITTED时，如果两个线程都先执行SELECT…FOR UPDATE，判断是否存在符合条件的记录，如果没有，就插入记录。此时，只有一个线程能插入成功，另一个线程会出现锁等待，当第1个线程提交后，第2个线程会因主键重出错，但虽然这个线程出错了，却会获得一个排他锁。这时如果有第3个线程又来申请排他锁，也会出现死锁。对于这种情况，可以直接做插入操作，然后再捕获主键重异常，或者在遇到主键重错误时，总是执行ROLLBACK释放获得的排他锁。
什么时候使用表锁

对于InnoDB表，在绝大部分情况下都应该使用行级锁，因为事务和行锁往往是我们之所以选择InnoDB表的理由。但在个别特殊事务中，也可以考虑使用表级锁：

* 事务需要更新大部分或全部数据，表又比较大，如果使用默认的行锁，不仅这个事务执行效率低，而且可能造成其他事务长时间锁等待和锁冲突，这种情况下可以考虑使用表锁来提高该事务的执行速度。
* 事务涉及多个表，比较复杂，很可能引起死锁，造成大量事务回滚。这种情况也可以考虑一次性锁定事务涉及的表，从而避免死锁、减少数据库因事务回滚带来的开销。
  当然，应用中这两种事务不能太多，否则，就应该考虑使用MyISAM表了。
* 在InnoDB下，使用表锁要注意以下两点。
    * 使用LOCK TABLES虽然可以给InnoDB加表级锁，但必须说明的是，表锁不是由InnoDB存储引擎层管理的，而是由其上一层──MySQL Server负责的，仅当autocommit=0、InnoDB_table_locks=1（默认设置）时，InnoDB层才能知道MySQL加的表锁，MySQL Server也才能感知InnoDB加的行锁，这种情况下，InnoDB才能自动识别涉及表级锁的死锁，否则，InnoDB将无法自动检测并处理这种死锁
    * 在用 LOCK TABLES对InnoDB表加锁时要注意，要将AUTOCOMMIT设为0，否则MySQL不会给表加锁；事务结束前，不要用UNLOCK TABLES释放表锁，因为UNLOCK TABLES会隐含地提交事务；COMMIT或ROLLBACK并不能释放用LOCK TABLES加的表级锁，必须用UNLOCK TABLES释放表锁

SQL优化怎么做？SQL执行过程是什么样子的？从client发起请求到数据库执行SQL在返回数据流程是什么？

答：

连接
  • 客户端发起一条Query请求，监听客户端的’连接管理模块’接收请求
  • 将请求转发到’连接进/线程模块’
  • 调用’用户模块’来进行授权检查
  • 通过检查后，’连接进/线程模块’从’线程连接池’中取出空闲的被缓存的连接线程和客户端请求对接，如果失败则创建一个新的连接请求
    处理
  • 先查询缓存，检查Query语句是否完全匹配，接着再检查是否具有权限，都成功则直接取数据返回
  • 上一步有失败则转交给’命令解析器’，经过词法分析，语法分析后生成解析树
  • 接下来是预处理阶段，处理解析器无法解决的语义，检查权限等，生成新的解析树
  • 再转交给对应的模块处理
  • 如果是SELECT查询还会经由’查询优化器’做大量的优化，生成执行计划
  • 模块收到请求后，通过’访问控制模块’检查所连接的用户是否有访问目标表和目标字段的权限
  • 有则调用’表管理模块’，先是查看table cache中是否存在，有则直接对应的表和获取锁，否则重新打开表文件
  • 根据表的meta数据，获取表的存储引擎类型等信息，通过接口调用对应的存储引擎处理
  • 上述过程中产生数据变化的时候，若打开日志功能，则会记录到相应二进制日志文件中
    结果
  • Query请求完成后，将结果集返回给’连接进/线程模块’
  • 返回的也可以是相应的状态标识，如成功或失败等
  • 连接进/线程模块’进行后续的清理工作，并继续等待请求或断开与客户端的连接
小结

用户模块校验用户,然后去线程连接池拿线程(连接足够的话),找命令分发器,到查询缓存模块查SQL语句,如果没有,走命令解析器,然后访问控制模块,设定用户的权限,设定好后走表管理模块,获取锁和缓存,然后获取各种信息,存储的方式:存储引擎,从存储引擎获取数据,然后返回

数据库事务ACID特性

答：

数据库事务ACID特性,数据库事务的4个特性：
  • 原子性(Atomic): 事务中的多个操作，不可分割，要么都成功，要么都失败； All or Nothing.
  • 一致性(Consistency): 事务操作之后, 数据库所处的状态和业务规则是一致的; 比如a,b账户相互转账之后，总金额不变；
  • 隔离性(Isolation): 多个事务之间就像是串行执行一样，不相互影响;
  • 持久性(Durability): 事务提交后被持久化到永久存储.
    隔离性,其中隔离性分为了四种：
  • READ UNCOMMITTED：可以读取未提交的数据，未提交的数据称为脏数据，所以又称脏读。此时：幻读，不可重复读和脏读均允许；
  • READ COMMITTED：只能读取已经提交的数据；此时：允许幻读和不可重复读，但不允许脏读，所以RC隔离级别要求解决脏读；
  • REPEATABLE READ：同一个事务中多次执行同一个select,读取到的数据没有发生改变；此时：允许幻读，但不允许不可重复读和脏读，所以RR隔离级别要求解决不可重复读；
  • SERIALIZABLE: 幻读，不可重复读和脏读都不允许，所以serializable要求解决幻读；
    加强理解：
  • 脏读：可以读取未提交的数据。RC 要求解决脏读；
  • 不可重复读：同一个事务中多次执行同一个select, 读取到的数据发生了改变(被其它事务update并且提交)；
  • 可重复读：同一个事务中多次执行同一个select, 读取到的数据没有发生改变(一般使用MVCC实现)；RR各级级别要求达到可重复读的标准；
  • 幻读：同一个事务中多次执行同一个select, 读取到的数据行发生改变。也就是行数减少或者增加了(被其它事务delete/insert并且提交)。SERIALIZABLE要求解决幻读问题；

这里一定要区分 不可重复读 和 幻读：

不可重复读的重点是修改:

同样的条件的select, 你读取过的数据, 再次读取出来发现值不一样了

幻读的重点在于新增或者删除:

同样的条件的select, 第1次和第2次读出来的记录数不一样

从结果上来看, 两者都是为多次读取的结果不一致。但如果你从实现的角度来看, 它们的区别就比较大：

对于前者, 在RC下只需要锁住满足条件的记录，就可以避免被其它事务修改，也就是 select for update, select in share mode; RR隔离下使用MVCC实现可重复读；

对于后者, 要锁住满足条件的记录及所有这些记录之间的gap，也就是需要 gap lock。

而ANSI SQL标准没有从隔离程度进行定义，而是定义了事务的隔离级别，同时定义了不同事务隔离级别解决的三大并发问题：

Isolation Level Dirty Read Unrepeatable Read Phantom Read
Read UNCOMMITTED YES YES YES
READ COMMITTED NO YES YES
READ REPEATABLE NO NO YES
SERIALIZABLE NO NO NO
MySQL 中RC和RR隔离级别的区别

MySQL数据库中默认隔离级别为RR，但是实际情况是使用RC 和 RR隔离级别的都不少。好像淘宝、网易都是使用的 RC 隔离级别。那么在MySQL中 RC 和 RR有什么区别呢？我们该如何选择呢？为什么MySQL将RR作为默认的隔离级别呢？
RC 与 RR 在锁方面的区别

显然 RR 支持 gap lock(next-key lock)，而RC则没有gap lock。因为MySQL的RR需要gap lock来解决幻读问题。而RC隔离级别则是允许存在不可重复读和幻读的。所以RC的并发一般要好于RR；

RC 隔离级别，通过 where 条件过滤之后，不符合条件的记录上的行锁，会释放掉(虽然这里破坏了“两阶段加锁原则”)；但是RR隔离级别，即使不符合where条件的记录，也不会是否行锁和gap lock；所以从锁方面来看，RC的并发应该要好于RR；另外 insert into t select … from s where 语句在s表上的锁也是不一样的

两个并发事务A，B执行的时间序列如下(A先于B开始，B先于A结束)

1
2
3
4
5
6
7
A1: start transaction;
B1: start transaction;
A2: select * from t;
B2: insert into t values (4, wangwu);
A3: select * from t;
B3: commit;
A4: select * from t;

1
2
3
4
5
6
7
8
9
10
11
12

提问1：假设事务的隔离级别是可重复读RR，事务A中的三次查询，A2, A3, A4分别读到什么结果集？
回答：RR下
(1)A2读到的结果集肯定是{1, 2, 3}，这是事务A的第一个read，假设为时间T；
(2)A3读到的结果集也是{1, 2, 3}，因为B还没有提交；
(3)A4读到的结果集还是{1, 2, 3}，因为事务B是在时间T之后提交的，A4得读到和A2一样的记录；

提问2：假设事务的隔离级别是读提交RC，A2, A3, A4又分别读到什么结果集呢？
回答：RC下
(1)A2读到的结果集是{1, 2, 3}；
(2)A3读到的结果集也是{1, 2, 3}，因为B还没有提交；
(3)A4读到的结果集还是{1, 2, 3, 4}，因为事务B已经提交

仍然是上面的两个事务，只是A和B开始时间稍有不同(B先于A开始，B先于A结束)

1
2
3
4
5
6
7
8
9
10
11
12
13

B1: start transaction;
A1: start transaction;
A2: select * from t;
B2: insert into t values (4, wangwu);
A3: select * from t;
B3: commit;
A4: select * from t;

提问3：假设事务的隔离级别是可重复读RR，事务A中的三次查询，A2, A3, A4分别读到什么结果集？
提问4：假设事务的隔离级别是读提交RC，A2, A3, A4的结果集又是什么呢？

回答：事务的开始时间不一样，不会影响“快照读”的结果，所以结果集和case 1一样。

仍然是并发的事务A与B(A先于B开始，B先于A结束)

1
2
3
4
5
6
7
8
9
10

A1: start transaction;
B1: start transaction;
B2: insert into t values (4, wangwu);
B3: commit;
A2: select * from t;
提问5：假设事务的隔离级别是可重复读RR，事务A中的A2查询，结果集是什么？
提问6：假设事务的隔离级别是读提交RC，A2的结果集又是什么呢？
回答：在RR下，
A2是事务A的第一个read，假设为时间T，它能读取到T之前提交事务写入的数据行，故结果集为{1, 2, 3, 4}。在RC下，没有疑问，一定是{1, 2, 3, 4}。

事务开始的时间再换一下(B先于A开始，B先于A结束)

1
2
3
4
5
6
7
8
9
10

B1: start transaction;
A1: start transaction;
B2: insert into t values (4, wangwu);
B3: commit;
A2: select * from t;

提问7：假设事务的隔离级别是可重复读RR，事务A中的A2查询，结果集是什么？
提问8：假设事务的隔离级别是读提交RC，A2的结果集又是什么呢？
回答：事务的开始时间不一样，不会影响“快照读”的结果，所以结果集和case 3一样。

总结：
  • RR下，事务在第一个Read操作时，会建立Read View
  • RC下，事务在每次Read操作时，都会建立Read View

怎么针对数据库中某一张表中的一条数据上锁？

答：

1
2
mysql> SELECT * FROM T1 WHERE ID = 1 FOR UPDATE;
mysql> SELECT * FROM T1 WHERE ID = 1 LOCK IN SHARE MODE;

行锁的三种模式，讲讲是什么？

答：

InnoDB有三种行锁的算法：
  • Record Lock：单个行记录上的锁。
  • Gap Lock：间隙锁，锁定一个范围，但不包括记录本身。GAP锁的目的，是为了防止同一事务的两次当前读，出现幻读的情况。
  • Next-Key Lock：1+2，锁定一个范围，并且锁定记录本身。对于行的查询，都是采用该方法，主要目的是解决幻读的问题。

innobackupex原理说一下

答：

  • innobackupex 在启动后，会先 fork 一个进程，启动 xtrabackup进程，然后就等待 xtrabackup 备份完 ibd 数据文件；
  • xtrabackup 在备份 InnoDB 相关数据时，是有2种线程的，1种是 redo 拷贝线程，负责拷贝 redo 文件，1种是 ibd 拷贝线程，负责拷贝 ibd 文件；redo 拷贝线程只有一个，在 ibd 拷贝线程之前启动，在 ibd 线程结束后结束。xtrabackup 进程开始执行后，先启动 redo 拷贝线程，从最新的 checkpoint 点开始顺序拷贝 redo 日志；然后再启动 ibd 数据拷贝线程，在 xtrabackup 拷贝 ibd 过程中，innobackupex 进程一直处于等待状态（等待文件被创建）。
  • xtrabackup 拷贝完成idb后，通知 innobackupex（通过创建文件），同时自己进入等待（redo 线程仍然继续拷贝）;
  • innobackupex 收到 xtrabackup 通知后，执行FLUSH TABLES WITH READ LOCK (FTWRL)，取得一致性位点，然后开始备份非 InnoDB 文件（包括 frm、MYD、MYI、CSV、opt、par等）。拷贝非 InnoDB 文件过程中，因为数据库处于全局只读状态，如果在业务的主库备份的话，要特别小心，非 InnoDB 表（主要是MyISAM）比较多的话整库只读时间就会比较长，这个影响一定要评估到。
  • 当 innobackupex 拷贝完所有非 InnoDB 表文件后，通知 xtrabackup（通过删文件） ，同时自己进入等待（等待另一个文件被创建）；
  • xtrabackup 收到 innobackupex 备份完非 InnoDB 通知后，就停止 redo 拷贝线程，然后通知 innobackupexredo log 拷贝完成（通过创建文件）；
  • innobackupex 收到 redo 备份完成通知后，就开始解锁，执行 UNLOCK TABLES；
  • 最后 innobackupex 和 xtrabackup 进程各自完成收尾工作，如资源的释放、写备份元数据信息等，innobackupex 等待 xtrabackup 子进程结束后退出。

在上面描述的文件拷贝，都是备份进程直接通过操作系统读取数据文件的，只在执行 SQL 命令时和数据库有交互，基本不影响数据库的运行，在备份非 InnoDB 时会有一段时间只读（如果没有MyISAM表的话，只读时间在几秒左右），在备份 InnoDB 数据文件时，对数据库完全没有影响，是真正的热备。InnoDB 和非 InnoDB 文件的备份都是通过拷贝文件来做的，但是实现的方式不同，前者是以page为粒度做的(xtrabackup)，后者是 cp 或者 tar 命令(innobackupex)，xtrabackup 在读取每个page时会校验 checksum 值，保证数据块是一致的，而 innobackupex 在 cp MyISAM 文件时已经做了flush（FTWRL），磁盘上的文件也是完整的，所以最终备份集里的数据文件都是写入完整的。

对NoSQL有了解吗？mongoDB副本集选举流程什么？

答：

Mongodb复制集由一组Mongod实例（进程）组成，包含一个Primary节点和多个Secondary节点，Mongodb Driver（客户端）的所有数据都写入Primary，Secondary从Primary同步写入的数据，以保持复制集内所有成员存储相同的数据集，提供数据的高可用。
Primary选举

复制集通过replSetInitiate命令（或mongo shell的rs.initiate()）进行初始化，初始化后各个成员间开始发送心跳消息，并发起Priamry选举操作，获得『大多数』成员投票支持的节点，会成为Primary，其余节点成为Secondary。

大多数』的定义

假设复制集内投票成员（后续介绍）数量为N，则大多数为 N/2 + 1，当复制集内存活成员数量不足大多数时，整个复制集将无法选举出Primary，复制集将无法提供写服务，处于只读状态。

特殊的Secondary

正常情况下，复制集的Seconary会参与Primary选举（自身也可能会被选为Primary），并从Primary同步最新写入的数据，以保证与Primary存储相同的数据。

Secondary可以提供读服务，增加Secondary节点可以提供复制集的读服务能力，同时提升复制集的可用性。另外，Mongodb支持对复制集的Secondary节点进行灵活的配置，以适应多种场景的需求。

特殊的Secondary

正常情况下，复制集的Seconary会参与Primary选举（自身也可能会被选为Primary），并从Primary同步最新写入的数据，以保证与Primary存储相同的数据。

Secondary可以提供读服务，增加Secondary节点可以提供复制集的读服务能力，同时提升复制集的可用性。另外，Mongodb支持对复制集的Secondary节点进行灵活的配置，以适应多种场景的需求

Arbiter

Arbiter节点只参与投票，不能被选为Primary，并且不从Primary同步数据。 比如你部署了一个2个节点的复制集，1个Primary，1个Secondary，任意节点宕机，复制集将不能提供服务了（无法选出Primary），这时可以给复制集添加一个Arbiter节点，即使有节点宕机，仍能选出Primary。

Arbiter本身不存储数据，是非常轻量级的服务，当复制集成员为偶数时，最好加入一个Arbiter节点，以提升复制集可用性。

Priority0

Priority0节点的选举优先级为0，不会被选举为Primary。

比如你跨机房A、B部署了一个复制集，并且想指定Primary必须在A机房，这时可以将B机房的复制集成员Priority设置为0，这样Primary就一定会是A机房的成员。（注意：如果这样部署，最好将『大多数』节点部署在A机房，否则网络分区时可能无法选出Primary）
Vote0

Mongodb 3.0里，复制集成员最多50个，参与Primary选举投票的成员最多7个，其他成员（Vote0）的vote属性必须设置为0，即不参与投票。

Hidden

Hidden节点不能被选为主（Priority为0），并且对Driver不可见。 因Hidden节点不会接受Driver的请求，可使用Hidden节点做一些数据备份、离线计算的任务，不会影响复制集的服务。

Delayed

Delayed节点必须是Hidden节点，并且其数据落后与Primary一段时间（可配置，比如1个小时）。 因Delayed节点的数据比Primary落后一段时间，当错误或者无效的数据写入Primary时，可通过Delayed节点的数据来恢复到之前的时间点。

数据同步

Primary与Secondary之间通过oplog来同步数据，Primary上的写操作完成后，会向特殊的local.oplog.rs特殊集合写入一条oplog，Secondary不断的从Primary取新的oplog并应用。

因oplog的数据会不断增加，local.oplog.rs被设置成为一个capped集合，当容量达到配置上限时，会将最旧的数据删除掉。另外考虑到oplog在Secondary上可能重复应用，oplog必须具有幂等性，即重复应用也会得到相同的结果。

oplog里各个字段的含义如下
  • ts： 操作时间，当前timestamp + 计数器，计数器每秒都被重置
  • h：操作的全局唯一标识
  • v：oplog版本信息
  • op：操作类型
    • i：插入操作
    • u：更新操作
    • d：删除操作
    • c：执行命令（如createDatabase，dropDatabase）
    • n：空操作，特殊用途
  • ns：操作针对的集合
  • o：操作内容，如果是更新操作
  • o2：操作查询条件，仅update操作包含该字段
    Secondary初次同步数据时，会先进行init sync，从Primary（或其他数据更新的Secondary）同步全量数据，然后不断通过tailable cursor从Primary的local.oplog.rs集合里查询最新的oplog并应用到自身。
  1. T1时间，从Primary同步所有数据库的数据（local除外），通过listDatabases + listCollections + cloneCollection敏命令组合完成，假设T2时间完成所有操作。
  2. 从Primary应用[T1-T2]时间段内的所有oplog，可能部分操作已经包含在步骤1，但由于oplog的幂等性，可重复应用。
  3. 根据Primary各集合的index设置，在Secondary上为相应集合创建index。（每个集合_id的index已在步骤1中完成）。
oplog集合的大小应根据DB规模及应用写入需求合理配置，配置得太大，会造成存储空间的浪费；配置得太小，可能造成Secondary的init sync一直无法成功。比如在步骤1里由于DB数据太多、并且oplog配置太小，导致oplog不足以存储[T1, T2]时间内的所有oplog，这就Secondary无法从Primary上同步完整的数据集。
细说Primary选举
Primary选举除了在复制集初始化时发生，还有如下场景
  • 复制集被reconfig
  • Secondary节点检测到Primary宕机时，会触发新Primary的选举
  • 当有Primary节点主动stepDown（主动降级为Secondary）时，也会触发新的Primary选举
    Primary的选举受节点间心跳、优先级、最新的oplog时间等多种因素影响。
    节点间心跳
    复制集成员间默认每2s会发送一次心跳信息，如果10s未收到某个节点的心跳，则认为该节点已宕机；如果宕机的节点为Primary，Secondary（前提是可被选为Primary）会发起新的Primary选举。
    节点优先级
  • 每个节点都倾向于投票给优先级最高的节点
  • 优先级为0的节点不会主动发起Primary选举
  • 当Primary发现有优先级更高Secondary，并且该Secondary的数据落后在10s内，则Primary会主动降级，让优先级更高的Secondary有成为Primary的机会。
    Optime

    拥有最新optime（最近一条oplog的时间戳）的节点才能被选为主。

    网络分区

    只有更大多数投票节点间保持网络连通，才有机会被选Primary；如果Primary与大多数的节点断开连接，Primary会主动降级为Secondary。当发生网络分区时，可能在短时间内出现多个Primary，故Driver在写入时，最好设置『大多数成功』的策略，这样即使出现多个Primary，也只有一个Primary能成功写入大多数。

说说TCP协议流程

答：

字段 含义
URG 紧急指针是否有效。为1，表示某一位需要被优先处理
ACK 确认号是否有效，一般置为1。
PSH 提示接收端应用程序立即从TCP缓冲区把数据读走。
RST 对方要求重新建立连接，复位。
SYN 请求建立连接，并在其序列号的字段进行序列号的初始值设定。建立连接，设置为1
FIN 希望断开连接。
TCP 握手
第一次握手

客户端发送数据包到服务器,(在此连接请求报文段中的同步位SYN=1,确认ACK=0,表示这是一个TCP连接请求数据报文,序号seq=x,表示传输数据时的起始序号是x)此时,客户端进入SYN_SENT状态,等待服务器确认

第二次握手

服务器收到连接请求报文段后，若同意建立连接,则向客户端发送确认报文段。此时服务器进入SYN_RECV状态。（其中确认报文段中，标识位SYN=1，ACK=1，表示这是一个TCP连接响应数据报文，并含服务端的初始序号seq(服务器)=y，以及服务器对客户端初始序号的确认号ack(服务器)=seq(客户端)+1=x+1）。

第三次握手

客户端再次向服务器发送一个序列号(seq=x+1)，确认号为ack(客户端)=y+1，此包发送完毕，客户端和服务器进入ESTAB_LISHED(TCP连接成功)状态，完成三次握手。

TCP释放
第一次挥手

首先，客户端发送一个FIN，用来关闭客户端到服务器的数据传送，然后等待服务器的确认。其中终止标志位FIN=1，序列号seq=u。

第二次挥手

服务器收到这个FIN，它发送一个ACK，确认ack为收到的序号加一。

第三次挥手

关闭服务器到客户端的连接，发送一个FIN给客户端。

第四次挥手

客户端收到FIN后，并发回一个ACK报文确认，并将确认序号seq设置为收到序号加一。首先进行关闭的一方将执行主动关闭，而另一方执行被动关闭。

TCP 挥手总结

客户端发送FIN后，进入终止等待状态，服务器收到客户端连接释放报文段后，就立即给客户端发送确认，服务器就进入CLOSE_WAIT状态，此时TCP服务器进程就通知高层应用进程，因而从客户端到服务器的连接就释放了。此时是“半关闭状态”，即客户端不可以发送给服务器，服务器可以发送给客户端。此时，如果服务器没有数据报发送给客户端，其应用程序就通知TCP释放连接，然后发送给客户端连接释放数据报，并等待确认。客户端发送确认后，进入TIME_WAIT状态，但是此时TCP连接还没有释放，然后经过等待计时器设置的2MSL后，才进入到CLOSE状态。

MySQL的 Double Writer(双写)是什么？

答：

有一个double write buffer，大小为2M。另一部分是物理磁盘上ibdata系统表空间中大小为2MB，共128个连续的Page，既2个分区。其中120个用于批量写脏，另外8个用于Single Page Flush。做区分的原因是批量刷脏是后台线程做的，不影响前台线程。而Single page flush是用户线程发起的，需要尽快的刷脏并替换出一个空闲页出来。对于批量刷脏，每次找到一个可做flush的page，对其持有S lock，然后将该page拷贝到dblwr中，当dblwr满后者一次批量刷脏结束时，将dblwr中的page全部刷到ibdata中，注意这是同步写操作；然后再唤醒后台IO线程去写数据页。当后台IO线程完成写操作后，会去更新dblwr中的计数以腾出空间，释放block上的S锁，完成写入。

对于Single Page Flush，则做的是同步写操作，在挑出一个可以刷脏的page后，先加入到dblwr中，刷到ibdata，然后写到用户表空间，完成后，会对该用户表空间做一次fsync操作。

Single Page Flush在buffer pool中free page不够时触发，通常由前台线程发起，由于每次single page flush都会导致一次fsync操作，在大并发负载下，如果大量线程去做flush，很显然会产生严重的性能下降。Percona在5.6版本中做了优化，可以选择由后台线程lru manager来做预刷，避免用户线程陷入其中。

如果发生了极端情况（断电）Crash Recovery，InnoDB再次启动后，发现了一个Page数据已经损坏，那么此时就可以从double write buffer中进行数据恢复了。触发数据缓冲池中的脏页进行刷新到data file的时候，并不直接写磁盘，而是会通过memcpy函数将脏页先复制到内存中的double write buffer，之后通过double write buffer再分两次、每次1MB顺序写入共享表空间的物理磁盘上。然后马上调用fsync函数，同步脏页进磁盘上。由于在这个过程中，double write页的存储时连续的，因此写入磁盘为顺序写，性能很高；完成double write后，再将脏页写入实际的各个表空间文件。

MySQL 半同步中5.7比5.6的优点是那些呢？

答：

半同步复制，普通的replication，即mysql的异步复制，依靠mysql二进制日志也即binary log进行数据复制。比如两台机器，一台主机(master)，另外一台是从机(slave)。

  • 正常的复制为：事务一（t1）写入binlog buffer；dumper 线程通知slave有新的事务t1；binlog buffer 进行checkpoint；slave的io线程接收到t1并写入到自己的的relay log；slave的sql线程写入到本地数据库。 这时，master和slave都能看到这条新的事务，即使master挂了，slave可以提升为新的master。
  • 异常的复制为：事务一（t1）写入binlog buffer；dumper 线程通知slave有新的事务t1；binlog buffer 进行checkpoint；slave因为网络不稳定，一直没有收到t1；master 挂掉，slave提升为新的master，t1丢失。
  • 很大的问题是：主机和从机事务更新的不同步，就算是没有网络或者其他系统的异常，当业务并发上来时，slave因为要顺序执行master批量事务，导致很大的延迟。

为了弥补以上几种场景的不足，mysql从5.5开始推出了半同步。即在master的dumper线程通知slave后，增加了一个ack，即是否成功收到t1的标志码。也就是dumper线程除了发送t1到slave，还承担了接收slave的ack工作。如果出现异常，没有收到ack，那么将自动降级为普通的复制，直到异常修复。

我们可以看到半同步带来的新问题：

  • 如果异常发生，会降级为普通的复制。 那么从机出现数据不一致的几率会减少，并不是完全消失。
  • 主机dumper线程承担的工作变多了，这样显然会降低整个数据库的性能。
  • 在MySQL 5.5和5.6使用after_commit的模式下, 即如果slave 没有收到事务，也就是还没有写入到relay log 之前，网络出现异常或者不稳定，此时刚好master挂了，系统切换到从机，两边的数据就会出现不一致。 在此情况下，slave会少一个事务的数据。

MySQL 5.7 主从一致性加强，支持在事务commit前等待ACK
新版本的semi sync 增加了rpl_semi_sync_master_wait_point= AFTER_SYNC;参数, 来控制半同步模式下主库在返回给会话事务成功之前提交事务的方式。
该参数有两个值:

1
2
AFTER_COMMIT: master将每个事务写入binlog ,传递到slave 刷新到磁盘(relay log)，同时主库提交事务。master等待slave 反馈收到relay log，只有收到ACK后master才将commit OK结果反馈给客户端。
AFTER_SYNC(5.7独有): master 将每个事务写入binlog , 传递到slave 刷新到磁盘(relay log)。master等待slave 反馈接收到relay log的ack之后，再提交事务并且返回commit OK结果给客户端。 即使主库crash，所有在主库上已经提交的事务都能保证已经同步到slave的relay log中。

支持发送binlog和接受ACK的异步化

  • 旧版本的semi sync 受限于dump thread ，原因是dump thread 承担了两份不同且又十分频繁的任务：传送binlog 给slave ，还需要等待slave反馈信息，而且这两个任务是串行的，dump thread 必须等待 slave 返回之后才会传送下一个 events 事务。dump thread 已然成为整个半同步提高性能的瓶颈。在高并发业务场景下，这样的机制会影响数据库整体的TPS 。
  • without_ack_receiving_thread
    • 为了解决上述问题，在5.7版本的semi sync 框架中，独立出一个 ack collector thread ，专门用于接收slave 的反馈信息。这样master 上有两个线程独立工作，可以同时发送binlog 到slave ，和接收slave的反馈。
  • 控制主库接受SLAVE写事务成功反馈数量。
    • MySQL 5.7 新增了SET GLOBAL rpl_semi_sync_master_wait_for_slave_count= N;参数，可以用来控制主库接受多少个slave写事务成功反馈，给高可用架构切换提供了灵活性。当count值为2时，master需等待两个slave的ack。
  • Binlog 互斥锁改进
    • 旧版本半同步复制在主提交binlog的写会话和dump thread读binlog的操作都会对binlog添加互斥锁，导致binlog文件的读写是串行化的，存在并发度的问题。
    • binlog_mutex_after_tuning
      • MySQL 5.7 对binlog lock进行了以下两方面优化:
        • 移除了dump thread对binlog的互斥锁
        • 加入了安全边际保证binlog的读安全
  • 组提交
    • MySQL 5.7 引入了新的变量slave-parallel-type，其可以配置的值有:
      • DATABASE （5.7之前默认值），基于库的并行复制方式
      • LOGICAL_CLOCK （5.7新增值），基于组提交的并行复制方式；

MySQL的RPO 和 RTO 名词是什么意思？

答：

RPO: 恢复点目标

  • 恢复点目标是指企业的损失容限：在对业务造成重大损害之前可能丢失的数据量。该目标表示为从丢失事件到最近一次在前备份的时间度量。

    RTO: 恢复时间目标

  • RTO指的是应用程序可以中断或关闭多少时间而不会对业务造成重大损害。有些应用程序可能会停机数天而不会产生严重的后果。而一些高优先级的应用程序只能停下来几秒钟，否则将会让企业和客户难以应对，并导致业务丢失。

比如一个操作，Begin;insert into….; commit; 这么操作。TPS 是几？QPS 是几?

答：

我理解的是QPS中包含TPS，所以QPS 是3，TPS 是1.

InnoDB的 MVCC 和 READ VIEW 给我讲解下？

答：

MVCC

是multiversion concurrency control的简称，也就是多版本并发控制，是个很基本的概念。MVCC的作用是让事务在并行发生时，在一定隔离级别前提下，可以保证在某个事务中能实现一致性读，也就是该事务启动时根据某个条件读取到的数据，直到事务结束时，再次执行相同条件，还是读到同一份数据，不会发生变化（不会看到被其他并行事务修改的数据）。

read view

InnoDB MVCC使用的内部快照的意思。在不同的隔离级别下，事务启动时（有些情况下，可能是SQL语句开始时）看到的数据快照版本可能也不同。在RR、RC、RU（READ UNCOMMITTED）等几个隔离级别下会用到 read view。

何时创建read view

其实，我们从上面的解释已经明白了，在RC隔离级别下，是每个SELECT都会获取最新的read view；而在RR隔离级别下，则是当事务中的第一个SELECT请求才创建read view

MySQL mysqldump 实现的原理是什么样子的？

答：

  1. FLUSH /!40101 LOCAL / TABLES
  2. FLUSH TABLES WITH READ LOCK
    执行flush tables操作，并加一个全局读锁，很多童鞋可能会好奇，这两个命令貌似是重复的，为什么不在第一次执行flush tables操作的时候加上锁了，其实，这样做的原因在于可以尽量减少加锁的影响。加上全局读锁，只允许读，不允许更新操作。
  3. SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ
    设置当前会话的事务隔离等级为RR，RR可避免不可重复读和幻读。
  4. START TRANSACTION /!40100 WITH CONSISTENT SNAPSHOT /
    获取当前数据库的快照，这个是由mysqldump中–single-transaction决定的。
    这个只适用于支持事务的表，在MySQL中，只有Innodb。
    注意：
    START TRANSACTION 和 START TRANSACTION WITH CONSISTENT SNAPSHOT 并不一样，
START TRANSACTION WITH CONSISTENT SNAPSHOT 是开启事务的一致性快照。
RC 下的 START TRANSACTION WITH CONSISTENT SNAPSHOT 相当于RR下的START TRANSACTION。
    不明白事务的童鞋可能觉得这点会比较绕，其实所谓的不可重复读和幻读可简单理解为，在同一个事务内，两次SELECT的结果并不相同。
    之所以要使用START TRANSACTION WITH CONSISTENT SNAPSHOT，因为每个表的备份时间并不相同，这就要求在对第一张表进行备份的期间，对第二个表进行的操作，并不会反映到第二张表开始备份时执行的SELECT操作中。（注：mysqldump备份的底层实现即是select * from tab）。而这用START TRANSACTION就无法实现。
  5. SHOW MASTER STATUS
    这个是由–master-data决定的，记录了开始备份时，binlog的状态信息，包括MASTER_LOG_FILE和MASTER_LOG_POS
  6. UNLOCK TABLES
    等记录完成后，就立即释放了，因为现在已经在一个事务中了，其他线程再修改数据已经无所谓，在本线程中已经是可重复读，这也是这一步必须在19 rows之后的原因，如果20 rows和21 rows都在19 rows之前的话就不行了，因为这时事务还没开启，一旦释放，其他线程立即就可以更改数据，从而无法保证得到事务开启时最准确的pos点
  7. 备份的核心是SELECT /!40001 SQL_NO_CACHE / * FROM test1语句。
    该语句会查询到表test1的所有数据，在备份文件中会生成相应的insert语句。
    其中SQL_NO_CACHE的作用是查询的结果并不会缓存到查询缓存中。
  8. SHOW CREATE DATABASE IF NOT EXISTS test，show create table test1
    生成创库语句和创表语句。
  9. SHOW TRIGGERS LIKE ‘test1’
    可以看出，如果不加-R参数，默认是会备份触发器的。
  10. SHOW FUNCTION STATUS WHERE Db = ‘test’
    SHOW CREATE FUNCTION mycat_seq_currval
    SHOW PROCEDURE STATUS WHERE Db = ‘test’
    用于备份存储过程和函数。
  11. 设置SAVEPOINT，然后备份完每个表后再回滚到该SAVEPOINT。
    因为前面通过START TRANSACTION WITH CONSISTENT SNAPSHOT开启的事务只能通过commit或者rollback来结束，而不是ROLLBACK TO SAVEPOINT sp。
    PS：
    这样做不会阻塞在备份期间对已经备份表的ddl操作，具体可见下面的“后续补充”第三点。

总结：

  • mysqldump的本质是通过select * from tab来获取表的数据的。
  • START TRANSACTION /!40100 WITH CONSISTENT SNAPSHOT /必须放到FLUSH TABLES WITH READ LOCK和UNLOCK TABLES之间，放到之前会造成START TRANSACTION /!40100 WITH CONSISTENT SNAPSHOT /和FLUSH TABLES WITH READ LOCK之间执行的DML语句丢失，放到之后，会造成从库重复插入数据。
  • mysqldump只适合放到业务低峰期做，如果备份的过程中数据操作很频繁，会造成Undo表空间越来越大，undo表空间默认是放到共享表空间中的，而ibdata的特性是一旦增大，就不会收缩。
  • mysqldump的效率还是比较低下，START TRANSACTION /!40100 WITH CONSISTENT SNAPSHOT /只能等到所有表备份完后才结束，其实效率比较高的做法是备份完一张表就提交一次，这样可尽快释放Undo表空间快照占用的空间。但这样做，就无法实现对所有表的一致性备份。

mysqldump single-transaction怎么实现获取InnoDB表的一致性备份？

答：

  • SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ
  • 批注：–single-transaction参数的作用，设置事务的隔离级别为可重复读，即REPEATABLE READ，这样能保证在一个事务中所有相同的查询读取到同样的数据，也就大概保证了在dump期间，如果其他innodb引擎的线程修改了表的数据并提交，对该dump线程的数据并无影响，然而这个还不够，还需要看下一条
  • START TRANSACTION /!40100 WITH CONSISTENT SNAPSHOT /
  • 这时开启一个事务，并且设置WITH CONSISTENT SNAPSHOT为快照级别（如果mysql版本高于某一个版本值，我还不大清楚40100代表什么版本）。想象一下，如果只是可重复读，那么在事务开始时还没dump数据时，这时其他线程修改并提交了数据，那么这时第一次查询得到的结果是其他线程提交后的结果，而WITH CONSISTENT SNAPSHOT能够保证在事务开启的时候，第一次查询的结果就是事务开始时的数据A，即使这时其他线程将其数据修改为B，查的结果依然是A

Paxos协议和Raft协议

答：

在分布式中我们非常非常看重的有一般网上经常说的三个点，CAP ！即：C (Consistency 一致性)、A (Availability 可用性)、P (Partition)；也就是我们经常所说的【CAP原理】；而在一致性中我们有非常非常注重四个点， ACID ！ 即：A (Atomicity 原子性)、C (Consistency 一致性)、 I (Isolation 隔离性)、 D (Durability 持久性)，也就是我们常说的【ACID原则】是的一致性原则中的一种

Raft

Raft是一个分布式一致性协议／算法，是Replicated And Fault Tolerant的缩写。在raft中首先具备了三种角色：

  • Leader (领导者)
  • Candidate（候选者）
  • Follower（追随者）

通常再做决策之前需要选举出一个全局的Leader来简化后续的决策过程。Leader决定了log的提交，且 log只能是Leader 想follower单向提交。

  • Leader (领导者)：负责接收客户端的Log，并分发给其他节点。
  • Candidate （候选者）：发起选举请求，竞争Leader。
  • Follower （追随者）：负责接收Leader发送过来的Log，并刷新保存。

Raft 分为两个过程:

  • 选举Leader
  • 日志同步。

Raft的核心思想

  • Leader的选举过程
  • Log的复制方案
  • 数据安全（其实就是一致性）
Paxos（Lamport）：

分布式系统中的节点通信存在两种模型：共享内存（Shared memory）和消息传递（Messages passing）。

基于消息传递通信模型的分布式系统，不可避免的会发生以下错误：进程可能会慢、被杀死或者重启，消息可能会延迟、丢失、重复，在基础Paxos场景中，先不考虑可能出现消息篡改即拜占庭错误的情况。

Paxos算法解决的问题是在一个可能发生上述异常的分布式系统中如何就某个值达成一致，保证不论发生以上任何异常，都不会破坏决议的一致性。

主要有三类节点:

  • 提议者（Proposer）：提出提案等待大家认可该提案为决议。(系统中的提案都拥有一个自增的唯一提案号，<往往由客户端担任该角色>)
  • 接受者（Acceptor）：负责对提案进行投票，认可提案。<往往由服务器担任该角色>
  • 学习者（Learner）：获取批准的结果 （学习acceptor所认可的结果），并帮忙传播，不参与投票过程。<客户端和服务器担任>

Paxos的流程分为两个阶段:

  • 准备阶段
  • 提交阶段

准备阶段：

  • proposer向网络内超过半数的acceptor发送prepare消息 (即：提交自己的提案编号)
  • acceptor正常情况下回复promise消息（接受者时可保存收到过的提案的最大编号和认可的最大提案，如果收到的提案号比自己保留的最大提案号还大，则返回自己已认可的提案号；如果从未认可过提案，则返回空，并更新当前保存的最大提案号，并说明不再认可小于最大提案号的提案）

提交阶段：

  • 在有足够多acceptor回复promise消息时，proposer发送accept消息（如果提案者收到大多数的回复，则发送带有刚才提案号的接受 accept 信息。<注意：如果收到的回复中不带有提案号，说明 提案锁定成功，则使用自己当前的提案内容；如果收到的回复中有提案内容，则替换当前提案值为返回的编号最大的提案值；如果没有收到足够的 回复，则会再次发送请求。<即 第一阶段的动作>）
  • 正常情况下acceptor回复accepted消息 （接受者收到 提案者发来的 接受 accept 信息，如果发现 提案号 不小于 自己保存的当前已接收的最大提案号，则更新 认可的最大提案，并更新认可提案内容）

在MHA架构中，如果VIP发生切换，有没有遇到过VIP不通的现象？怎么解决这个问题呢？

答：

有遇到过。
解决的方法有两种：

  • 执行命令

    1
    2
    3
    # arp -d vip
    # ip neigh flush dev eth0 # 清空eth0的arp表
    # arp -n|awk '/^[1-9]/{print "arp -d  " $1}'|sh -x

  • 修改sysctl.conf

    1
    2
    3
    # sysctl -w net.ipv4.ip_forward = 1
    # echo 1 > /proc/sys/net/ipv4/ip_forward
    # sed -i '/net.ipv4.ip_forward/ s/\(.*= \).*/\11/' /etc/sysctl.conf

在InnoDB引擎中，16k PAGE SIZE, InnoDB的非叶子节点最多能放多少个INT的Primary Keys,能用 16K/4 来估算吗？

答：

在InnoDB引擎中，每一个page预留1/6空闲空间，再减去头尾元数据信息，就是 16338*15/16*1024/4。就是大概的结果。
注: 16338 是去掉 头尾元数据信息后的大小。

参考官方资料

说一说三个范式

答：

第一范式(1NF):

数据库表中的字段都是单一属性的,不可再分. 这个单一属性由基本类型构成, 包括整型/实数/字符型/逻辑性/日期型等.

第二范式(2NF):

数据库表中不存在非关键字段对任一候选关键字段的部分函数依赖(部分函数依赖指的是存在组合关键字段中的某些字段决定非关键字段的情况), 也即所有非关键字段都完全依赖于任意一组候选关键字.

第三范式(3NF):

在第二范式的基础上，数据表中如果不存在非关键字段对任一候选关键字段的传递函数依赖则符合第三范式. 所谓传递函数依赖, 指的是如果存在 ‘A -> B -> C’ 的决定关系, 则C传递函数依赖于A. 因此, 满足第三范式的数据库表应该不存在如下依赖关系: 关键字段 -> 非关键字段x -> 非关键字段y

-------------本文结束感谢您的阅读-------------

本文标题:面试

文章作者:Wang Jiemin

发布时间:2019年01月28日 - 16:01

最后更新:2019年04月26日 - 10:04

原始链接:https://jiemin.wang/2019/01/28/面试/

许可协议: 署名-非商业性使用-禁止演绎 4.0 国际 转载请保留原文链接及作者。

0%