last

倒数第三个员工信息 SELECT * FROM employees ORDER BY hire_date DESC LIMIT 2,1; LIMIT m,n : 表示从第m+1条开始，取n条数据； LIMIT n ： 表示从第0条开始，取n条数据，是limit(0,n)的缩写 薪资涨15次以上的 SELECT emp_no, COUNT(emp_no) AS t FROM salaries GROUP BY emp_no HAVING t > 15 去重当前薪资 SELECT DISTINCT salary FROM salaries WHERE to_date = '9999-01-01' ORDER BY salary DESC 不是经理的员工 SELECT emp_no FROM employees WHERE emp_no NOT IN (SELECT emp_no FROM dept_manager) title进行分组，显示大于2的组 SELECT title, COUNT(title) AS t FROM titles GROUP BY title HAVING t >= 2 同上，忽略重复的emp_no SELECT title, COUNT(DISTINCT emp_no) AS t FROM titles GROUP BY title HAVING t >= 2

1.HashSet概述： 　　HashSet实现Set接口，由哈希表（实际上是一个HashMap实例）支持。 它不保证set 的迭代顺序；特别是它不保证该顺序恒久不变。此类允许使用null元素。HashSet中不允许有重复元素，这是因为HashSet是基于HashMap实现的，HashSet中的元素都存放在HashMap的 key 上面，而value中的值都是统一的一个 private static final Object PRESENT = new Object(); 。HashSet跟HashMap一样，都是一个存放链表的数组。 　　HashSet中add方法调用的是底层HashMap中的put()方法，而如果是在HashMap中调用put，首先会判断key是否存在，如果key存在则修改value值，如果key不存在这插入这个key-value。而在set中，因为value值没有用，也就不存在修改value值的说法， 因此往HashSet中添加元素，首先判断元素（也就是key）是否存在，如果不存在这插入，如果存在着不插入，这样HashSet中就不存在重复值。 2.HashSet的实现： 对于HashSet而言，它是 基于HashMap实现的 ， HashSet底层使用HashMap来保存所有元素，更确切的说，HashSet中的元素，只是存放在了底层HashMap的 key 上

第1章 MySQL主从复制 1.1 数据库损坏了？ 主要理解为：业务不能使用数据库 外在原因： 1、网络问题 2、业务应用有问题，客户端损坏 数据库本身的原因： 1、物理损坏：机器坏了、硬盘坏了、存储坏了 2、逻辑损坏：误drop、delete、truncate、、update。 解决方案： 1、备份 2、主从复制 1.2 MySQL主从复制 1.2.1 MySQL复制概念 指将主数据库的DDL和DML操作通过二进制日志传到复制服务器上，然后在复制服务器上将这些日志文件重新执行，从而使复制服务器和主服务器的数据保持同步。复制过程中一个服务器充当主服务器（master），而一个或多个其它服务器充当从服务器（slaves）。主服务器将更新重新写入二进制日志文件，并维护文件的一个索引以跟踪日志循环。这些日志可以记录发送到从服务器的更新。当一个从服务器连接主服务器时，它通知主服务器、从服务器在日志中读取的最后一次成功更新的位置。从服务器接受从那时起发生的任何更新，然后封锁并等待主服务器通知新的更新。 复制的用途： 通过主从复制（master-slave）的方式来同步数据，再通过读写分离（mysql-proxy）来提升数据库的并发负载能力，或者用来作为主备机的设计，保证在主机停止响应之后在很短的时间内就可以将应用切换到备机上继续运行。 优势： （1）数据库集群系统具有多个数据库节点

现在不少公司都在用MySQL（master）-->MySQL（slave）的框架，当然也有一主多从的架构，这也是MySQL主从的一个延伸架构;当然也有的公司MySQL主主的架构，MySQL主主架构要是处理得不适当，会面临各种各样的问题，当然啦，每种数据库构架都有自己的优缺点，合适自己公司业务需求的且方便自己维护的架构都可以认为是理想的构架，当出现同步断开了，我们是不是一味的使用 --slave-skip-errors=[error_code] 来跳过错误代码呢？其实不是的，这样做可能会造成数据不一致的可能，下面我只针对MySQL Replication常见的错误进行说明及处理。 一、在master上更新一条记录时出现的故障 （ master与slave处理同步的情况下，binlog为row格式 ） 在slave库上，模拟slave少了一条数据，所以把id=6的记录在slave上先delete掉： root@mysql-slave> select * from test; +----+------+----------+ | id | name | code | +----+------+----------+ | 6 | aa | 10002011 | | 7 | bb | 10002012 | | 8 | cc | 10002013 | | 9 | dd | 10002014 |

从MySQL5.5版本以后，开始引入并行复制的机制，是MySQL的一个非常重要的特性。 MySQL5.6开始支持以schema为维度的并行复制，即如果binlog row event操作的是不同的schema的对象，在确定没有DDL和foreign key依赖的情况下，就可以实现并行复制。 社区也有引入以表为维度或者以记录为维度的并行复制的版本，不管是schema，table或者record，都是建立在备库slave实时解析row格式的event进行判断，保证没有冲突的情况下，进行分发来实现并行。 MySQL5.7的并行复制，multi-threaded slave即MTS，期望最大化还原主库的并行度，实现方式是在binlog event中增加必要的信息，以便slave节点根据这些信息实现并行复制。 MySQL 5.7的并行复制建立在group commit的基础上，所有在主库上能够完成prepared的语句表示没有数据冲突，就可以在slave节点并行复制。 关于MySQL5.7的组提交，我们要看下以下的参数： mysql> show global variables like '%group_commit%'; +-----------------------------------------+-------+ | Variable_name | Value | +------

一、基本信息说明 【DB1】 IP: 192.168.102.144 hostname: LVS-Real1 【DB2】 IP: 192.168.102.145 hostname: LVS-Real2 【VIP】 IP: 192.168.102.146 二、MySQL配置主主互备 1.配置DB1和DB2的/etc/my.cnf 【DB1】 [root@LVS-Real1 ~]# more /etc/my.cnf [client] port = 3306 socket = /tmp/mysql.sock [mysqld] user=mysql port = 3306 server_id = 1 #需保证唯一性 socket=/tmp/mysql.sock basedir =/usr/local/mysql datadir =/usr/local/mysql/data pid-file=/usr/local/mysql/data/mysqld.pid log-error=/usr/local/mysql/log/mysql-error.log log-bin=mysql-bin #开启二进制日志 relay-log=mysql-relay-bin replicate-wild-ignore-table=mysql.% #忽略复制mysql数据库下的所有对象，以下依次类推

环境： DB1：centos6.8、mysql5.5、192.168.2.204 hostname：bogon DB2：centos6.8、mysql5.5、192.168.2.205 hostname：localhost.localdomain vip：192.168.2.33 一、先配置DB1和DB2的双主热备 1、分别在DB1和DB2上安装mysql，我这里是用的ansible自动部署 [root@www ansible]# ansible-playbook lnmp.yml PLAY [new] ********************************************************************* TASK [setup] ******************************************************************* ok: [192.168.2.205] ok: [192.168.2.204] TASK [mysql : Create backup folder] ******************************************** ok: [192.168.2.204] ok: [192.168.2.205] TASK [mysql : create log folder]

目录 1.mysql简介 1.1 主从作用 3.1 mysql安装 3.2 mysql主从配置 3.2.1 确保从数据库与主数据库里的数据一样(两个里面都无数据) 3.2.2 在主数据库里创建一个同步账号授权给从数据库使用 3.2.3 配置主数据库 3.2.4 配置从数据库 3.2.5 测试验证 4.mysql主从配置 4.1确保从数据库与主数据库里的数据一样 4.1.2在主数据库里创建一个同步账号授权给从数据库使用 4.1.3配置主数据库 4.1.3 配置从数据库 4.1.4测试验证 1.mysql简介 在现代企业中，数据显得尤为重要，而存储数据的数据库选择又五花八门，但无论是何种数据库，均存在着一种隐患。 想几个问题： 用一台数据库存放数据，若此数据库服务器宕机了导致数据丢失怎么办？ 业务量大了，数据多了，访问的人多了，一台数据库无法保证服务质量了怎么办？ 1.1 主从作用 实时灾备，用于故障切换 读写分离，提供查询服务 备份，避免影响业务（这里的备份不是指数据库的备份，而是服务器的备份，相当于一台备用服务器） 1.2 主从形式 一主一从 主主复制 一主多从---扩展系统读取的性能，因为读是在从库读取的 多主一从---5.7开始支持 联级复制 2. 主从复制原理 主从复制步骤： 主库将所有的写操作记录到binlog日志中并生成一个log dump线程

db01 172.21.0.10 db02 172.21.0.14 一、安装数据库看上一遍博客 修改配置文件 db01 172.21.0.10 [root@VM_0_10_centos mysql]# cat /etc/my.cnf [mysqld] port=3306 character-set-server=utf8 basedir=/usr/local/mysql datadir=/usr/local/mysql/data #innodb_buffer_pool_size=8M max_connections=1000 slow_query_log = 1 slow_query_log_file=/usr/local/mysql/log/mysql_slow_query.log long_query_time = 5 max_connections=1000 log-bin=/usr/local/mysql/log_bin/mysql-bin.log # 开启二进制日志 binlog_format=mixed server-id = 1 auto_increment_increment=2 # 步进值auto_imcrement。一般有n台主 MySQL 就填n auto_increment_offset=1 # 起始值。一般填第n台主MySQL。此时为第一台主MySQL

Top NSD DBA2 DAY01 案例1：MySQL一主一从 案例2：配置主从从同步结构 配置半同步复制模式 1 案例1：MySQL一主一从 1.1 问题 构建 主-->从 复制结构 其中主机192.168.4.10作为主库 主机192.168.4.20作为从库 1.2 方案 使用2台RHEL 7虚拟机，如图-1所示。其中192.168.4.10是MySQL主服务器，负责提供同步源；另一台192.168.4.20作为MySQL从服务器，通过调取主服务器上的binlog日志，在本地重做对应的库、表，实现与主服务器的AB复制（同步）。 图－1 提前为两台MySQL服务器安装好MySQL-server、MySQL-Client软件包，并为数据库用户root修改密码；Linux客户机上则只需安装MySQL-Client软件包即可。 1.3 步骤 实现此案例需要按照如下步骤进行。 步骤一：初始化现有库 为了在启用binlog日志及同步之前保持主、从库的一致性，建议进行初始化——备份主服务器上现有的库，然后导入到从服务器上。 当现有库、表都采用MyISAM引擎时，可执行离线备份、恢复，这样更有效率；否则，可通过mysqldump等工具来实现库的导出、导入。 1）备份MySQL Master（192.168.4.10）上现有的库 如果服务器已经启用binlog，建议对日志做一次重置