管理给自己设置密码
1 | > mysql -u root |
1 | mysql> SET PASSWORD = PASSWORD('123456'); |
管理员或者有全局权限的用户重设其它用户的密码
方法一
1 | > mysql -u root -p |
1 | mysql> use mysql; |
方法二
1 | > mysql -u root -p |
1 | mysql> use mysql; |
方法三
1 | mysqladmin -u root "old password" "new password" |
1 | > mysql -u root |
1 | mysql> SET PASSWORD = PASSWORD('123456'); |
1 | > mysql -u root -p |
1 | mysql> use mysql; |
1 | > mysql -u root -p |
1 | mysql> use mysql; |
1 | mysqladmin -u root "old password" "new password" |
略 (请在 MySQL 官网下载 tar.gz 的 source 源码包)
官网5.6 下载地址: http://dev.mysql.com/downloads/mysql/5.6.html#downloads
编译参数会在其他文章中详细讲解
使用下面的命令检查是否安装有MySQL Server
1 | > rpm -qa | grep mysql |
1 | > rpm -e mysql #普通删除模式 |
把下载好的mysql二进制包放在 /usr/local/
下
1 | > useradd mysql |
1 | > vim /etc/my.cnf |
1 | > chown mysql:mysql /etc/my.cnf |
1 | > cp support-files/mysql.server /etc/init.d/mysqld |
这里一定要注意,虽然是在CentOS7系列上安装,CentOS7默认使用systemctl管理程序的启动与关闭,但是mysql5.6提供的脚本是使用service控制程序启动与关闭的脚本,所以需要放在/etc/init.d/
下,使用service的方式启动
进入mysql会碰到环境变量的问题,找不到mysql的执行文件
MySQL启动成功后,root默认没有密码,我们需要设置root密码。
设置之前,我们需要先设置PATH,要不不能直接调用mysql
修改/etc/profile文件,在文件末尾添加
1 | > vim /etc/profile |
关闭文件,运行下面的命令,让配置立即生效
1 | source /etc/profile |
现在,我们可以在终端内直接输入mysql进入,mysql的环境了
执行下面的命令修改root密码
1 | mysql -uroot |
ShadowSocks 最近几年大火, 其简单的配置和优秀的速度让大陆地区的墙内用户爱不释手
本篇文章不讨论Mac & Windows 等图形界面下的应用, 而是让 linux 在命令行界面下, http/https 访问也能登上梯子, 看一看外面的大千世界
最近公司的服务器连接 docker hub hub.docker.com 仓库和 node.js nodejs.org 仓库极其缓慢, 使用了各种国内的各种加速服务才勉强解决了燃眉之急(分别使用了 daocloud 的镜像加速和淘宝的加速服务)
本篇文章就是介绍如何实现 Linux 中的 http/https 请求翻墙的需求
shadowsocks安装时是不分客户端还是服务器端的, 只不过安装后有两个脚本一个是sslocal代表以客户端模式工作,一个是ssserver代表以服务器端模式工作
1 | > yum install python-pip |
1 | > nohup sslocal -s your_server_ip -p your_server_port -l 1080 -k your_server_passwd -t 600 -m rc4-md5 > /dev/null 2>&1 & |
注意:
sslocal
这个命令,表示 shadowsocks
以客户端模式工作 your_server_ip
, your_server_port
, your_server_passwd
换成自己的, 这三个分别代表服务器ip, 服务器上 shadowsocks
的端口以及密码.后面的 rc4-md5
加密方式也要换成跟 server
端一致。 1 | { |
然后运行一下命令启动shadowsocks
1 | > nohup sslocal -c /etc/shadowsocks.json /dev/null 2>&1 & |
上述安好了shadowsocks
,但它是 socks5
代理,我门在 shell
里执行的命令,发起的网络请求现在还不支持 socks5
代理,只支持 http/https
代理。为了我门需要安装 privoxy
代理,它能把电脑上所有http请求转发给 shadowsocks
1 | > yum install privoxy -y |
vim /usr/local/etc/privoxy/config
文件,listen-address
找到 listen-address 127.0.0.1:8118
这一句,保证这一句没有注释,8118就是将来http代理要输入的端口。forward-socks5t
, 将 #forward-socks5t / 127.0.0.1:1080 .
此句前面的注释去掉, 意思是转发流量到本地的1080端口, 而1080端口正是 ss 监听的端口1 | > systemctl restart privoxy |
写在 profile 中
1 | > vim /etc/profile |
在当前 session 执行
1 | export http_proxy=http://127.0.0.1:8118 |
1 | curl www.google.com |
如果不能访问, 请重启机器, 依次打开shadowsocks和privoxy再测试
1 | > nohup sslocal -c /etc/shadowsocks.json /dev/null 2>&1 & |
本篇文章不再赘述 MySQL 主从搭建的过程, 只介绍主从切换的过程
MySQL 的主从切换分成两种情况
1 | # slave 中查看从库的状态 |
1 | # master 中查看主库的状态 |
先停止 IO_THREAD 线程, 即断开了从主库的 sql 消息接收, 有利于当前数据库完成剩余的数据同步
1 | # slave |
检查是否是如下状态;
1 | Slave_IO_Running: No |
在停止 IO_THREAD 线程后, 看到 Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update it
这个状态后, 就可以操作完全停止从库,并激活为主库啦
1 | mysql> stop slave; # 完全停止 slave 复制 |
1 | # master |
第二种情况的主从切换, 切换后, 主库不需要再去同步之前的从库(新主库), 有下线的需求, 这种情况下, 操作流程跟以上差不多, 只不过可以省去如下步骤:
reset master
了, 因为原主库(现从库)不要再找点啦(Position)docker容器默认的空间是10G, Pool 大小默认是100G.
1 | > docker info |
Data Space Total: 107.4 GB
这个就是默认的 Pool 大小
如果想指定默认容器的大小(在启动容器的时候指定),可以在docker配置文件里通过dm.basesize参数指定
1 | docker -d --storage-opt dm.basesize=20G |
对于使用 systemctl
管理的docker服务, 可以编辑 systemctl 的启动脚本
1 | > vim /etc/systemd/system/docker.service |
以上方式适用于新 run 起来的 container, 会获取到新的空间
1 | > dmsetup status |
最上面4条开头写着 docker 的虚拟磁盘就是我们即将操作的对象
其中可以明显的看出, 第一条中带有 pool
的字样, 没错, 这个就是 docker 默认的 pool 大小,现在我们要调整 container 的大小, 暂时不管 pool 的默认配置
其余的三条磁盘信息就是当前宿主机中, 起来的 container 使用的虚拟磁盘, 如果你需要指定其中一个来调整, 那么你需要找到虚拟磁盘和 container name 或 container id 的对应关系, 不要搞错!
对应关系可以使用 docker exec -it xxxx /bin/bash
进入到 container 中使用df -h
命令查看根分区的虚拟磁盘名称
也可以在 linux 中使用 docker inspect xxx
来查看 xxx 容器的详细信息
找到了它们的对应关系之后, 接下来就可以对其调整大小了
默认情况下, 所有的虚拟磁盘的映射都在/dev/mapper/
下
1 | > ls -l |
从上面👆的回显也可以看出实际指向的虚拟磁盘文件(是不是有点绕, 这个文件只不过是虚拟磁盘的软连接而已)
接下来我们需要对其进行扩容操作
1 | > dmsetup table docker-253:0-117441065-17379f89f95efb5bafb234d95e0e0dfe549f7ba48fbed69c0111e2ea39c0106e |
假设你想要的容量为 20G
则该值应该为: 20*1024*1024*1024/512
= 41943040
验算: 20G 的值 41943040 = 默认10G 的值 20971520 *2
公式为: x*1024*1024*1024/512
1 | > dmsetup suspend docker-253:0-117441065-17379f89f95efb5bafb234d95e0e0dfe549f7ba48fbed69c0111e2ea39c0106e |
没有回显, 没有消息就是好消息😆
1 | > dmsetup reload docker-253:0-117441065-17379f89f95efb5bafb234d95e0e0dfe549f7ba48fbed69c0111e2ea39c0106e --table '0 41943040 thin 253:2 25' |
把上一步计算出来的值, 覆盖到第一步的回显对应的位置中
1 | > dmsetup resume docker-253:0-117441065-17379f89f95efb5bafb234d95e0e0dfe549f7ba48fbed69c0111e2ea39c0106e |
如果执行到这一步的时候报错:
1 | device-mapper: resume ioctl on docker-253:0-1700-pool failed: Invalid argument |
先不要慌, 稍等片刻, 再重新执行
由于挂起操作会阻塞住所有的 IO, 为了尽快完成扩容, 我们一般把第三四五步骤用一行命令去执行
1 | > dmsetup suspend docker-253:0-117441065-17379f89f95efb5bafb234d95e0e0dfe549f7ba48fbed69c0111e2ea39c0106e \ |
1 | > mount /dev/dm-3 /mnt |
需要先挂载再扩容
调整 pool 大小不同于调整 container 的大小, 需要先对其虚拟文件进行扩容, 再对虚拟磁盘扩容
到这里涉及到了三个概念:
虚拟硬盘设备是基于虚拟文件的, 就好像我们使用的 lvm 卷, 虚拟硬盘设备就相当于 lv 或是说就相当于我们正在使用的文件系统; 而 docker 中的虚拟文件就好比我们物理机的硬盘, 或是说 PV 与 VG 的大小
1 | > ls -lh /var/lib/docker/devicemapper/devicemapper/ |
可以看到 data 是100G 大小, 不要担心他实际占用了100G, 这个是精简配置, 实际用多少就占多少空间, 最大100G
上面看到的 data 文件有100G 的大小, 现在我需要200G 的 pool 大小, 所以需要调整 data 文件的属性
1 | truncate -s 214748364800 /var/lib/docker/devicemapper/devicemapper/data |
1 | > ls -lh /var/lib/docker/devicemapper/devicemapper/ |
1 | > blockdev --getsize64 /dev/loop0 |
第四步基本就是重复上面扩容 container 的步骤, 这里省略了前几步的查看和计算
1 | > dmsetup suspend docker-253:0-1700-pool \ |
扩容 pool 涉及到了两个计算
上面已经给出了扇区的计算公式: x*1024*1024*1024/512
data 大小的计算公式为: x*1024*1024*1024
参考文档:
https://docs.docker.com/engine/userguide/storagedriver/device-mapper-driver/#/increase-capacity-on-a-running-device
https://segmentfault.com/a/1190000002931564
http://www.linuxidc.com/Linux/2015-01/112245.htm
http://www.projectatomic.io/blog/2016/03/daemon_option_basedevicesize/
在开启了 GTID 功能的 MySQL 数据库中, 不论是否使用了 GTID 的方式做了主从同步, 导出导入时都需要特别注意数据库中的 GTID 信息.
1 | ➜ mysqldump -uroot -p userdb > userdb.sql |
mysql提示: 当前数据库实例中开启了 GTID 功能, 在开启有 GTID 功能的数据库实例中, 导出其中任何一个库, 如果没有显示地指定--set-gtid-purged
参数, 都会提示这一行信息. 意思是默认情况下, 导出的库中含有 GTID 信息, 如果不想导出包含有 GTID 信息的数据库, 需要显示地添加--set-gtid-purged=OFF
参数. 于是乎, dump 变成了如下样子
➜ mysqldump -uroot -p --set-gtid-purged=OFF userdb > userdb.sql
使用以上这条命令 dump 出来的库是不包含 GTID 信息的
导入的时候也分两种, 一种是导入带有 GTID 的信息的库, 一种是导入不带有 GTID 信息的库
不带有 GTID 信息的 dump 文件, 不管目标数据库实例是否开启了 GTID 功能, 且不管数据库实例是否已有其他 GTID 信息, 都可以顺利导入
带有 GTID 信息的 dump 文件, 要求目标数据库实例必须开启 GTID 功能, 且当前数据库中无其他 GTID 信息. 如果目标数据库中已经记录了一条或一条以上的 GTID 信息, 那么在导入数据库时会报出类似如下的错误❌
1 | ➜ mysql -uroot -p userdb < userdb.sql |
在 mysql5.7版本中加入了多 channel 的特性, 一台数据库实例可以同时与多个主库同步, 实现多主一从架构, 但是假如现在数据库实例中开启了 GTID, 并以 GTID 的方式与 A 主库和 B 主库同步,那么现在的 slave 中就记录有两条 GTID 信息. 在导入带有新 GTID 信息的库时, 会报错, 要求你清除掉目标数据库实例中所有的 GTID 信息. 在这种情况下, 问题就比较严重了, 因为我的这台数据库已经和两台主库建立主从关系, 现在为了导入一个新库, 需要 reset 掉所有同步信息(GTID 信息)
这个时候你有两个选择:
--set-gtid-purged=OFF
的参数禁止🚫导出 GTID 信息,再 load 进目标数据库mysql> reset slave all;
mysql> reset master;
清空所有 GTID 信息之后就可以导入了最宽松的模式, 即使有错误既不会报错也不会有警告⚠️
宽松模式,对插入数据进行校验,如果不符合定义类型或长度,对数据类型调整或截断保存,报warning警告
严格模式,当向mysql数据库插入数据时,进行数据的严格校验,保证错误数据不能插入,报error错误。用于事物时,会进行事物的回滚
严格模式,进行数据的严格校验,错误数据不能插入,报error错误
no_engine_subtitution的作用:mysql 在create table 时可以指定engine子句(指定存储引擎),如果把引擎指定成一个并不存在的引擎, 这个时候mysql可以有两种行为供选择
如果 sql_mode 存在 no_engine_subtitution 的时候 ===> 直接报错
如果 sql_mode 不存在 no_engine_subtitution 的时候 ===> 把表的存储引擎替换成innodb
1 | mysql> select @@sql_mode; |
SET [GLOBAL|SESSION] sql_mode='modes'
1 | mysql> set sql_mode=`NO_FIELD_OPTIONS,HIGH_NOT_PRECEDENCE`; |
1 | mysql> set global sql_mode=`NO_FIELD_OPTIONS,HIGH_NOT_PRECEDENCE` |
1 | ➜ ~ vim /etc/my.cnf |
参考文档:
在一台 MySQL5.7 的服务器上磁盘使用空间突然爆满, 查看 mysql 数据目录下的文件发现,有个叫
ibtmp1
的文件大小达到了160GB.
后经过查询得知, ibtmp1
文件是 MySQL5.7的新特性,MySQL5.7使用了独立的临时表空间来存储临时表数据,但不能是压缩表。临时表空间在实例启动的时候进行创建,shutdown的时候进行删除。即为所有非压缩的innodb临时表提供一个独立的表空间,默认的临时表空间文件为ibtmp1,位于数据目录。我们可通过innodb_temp_data_file_path参数指定临时表空间的路径和大小,默认12M。只有重启实例才能回收临时表空间文件ibtmp1的大小。create temporary table和using temporary table将共用这个临时表空间
1 | mysql> show variables like 'innodb_temp_data_file_path'; |
物理文件
1 | ➜ ~ du -sh ibtmp1 |
释放这个临时表空间的唯一办法是重启数据库
官方文档: https://dev.mysql.com/doc/refman/5.7/en/innodb-parameters.html#sysvar_innodb_temp_data_file_path
在配置文件中配置有
binglog_format=row
的数据库产生的 binglog 日志是不能以正常的mysqlbinlog logfile
的方式打开的, 默认情况下只能看到一些经过base-64编码的信息
1 | mysqlbinlog -v -v --base64-output=DECODE-ROWS mysql-bin.000003 |
使用 mysqlbinlog 命令查看 binlog 日志时出现
mysqlbinlog: unknown variable 'default-character-set=utf8mb4'
的报错, 原因是在 mysql 的配置文件中, 我设置默认字符集为utf8mb4
此字符集为 utf8 的扩展字符集,支持保存 emoji😈 表情, 解决方案如下
1 | ➜ ~ mysqlbinlog mysql-bin.000256 |
原因是mysqlbinlog这个工具无法识别binlog中的配置中的default-character-set=utf8这个指令
解决的办法有两个:
/etc/my.cnf
中配置的default-character-set = utf8mb4
修改为character-set-server = utf8mb4
但是这种修改方法需要重启数据库, 在线上业务库中使用这种方法查看 binlog 日志并不划算~mysqlbinlog --no-defaults mysql-bin.000256
完美解决~