How to login the VM of Docker Desktop for Mac

Docker for macOS的宿主机在哪里?

我们之前在MOVING MYSQL GROUP REPLICATION INSTANCES TO DOCKER CONTAINER ON MACOS这篇文章中提过在Docker for macOS中,容器的宿主机并不是macOS本身,而是在macOS中运行的一个虚拟机。虚拟机的路径可以通过查看Docker Desktop的配置界面获知。
NewImage

如果我们想登录这台虚拟机应该怎么做?

方法一

使用screen命令。实际上在上面那篇文章中我们提到过这个方法。
比如在上图中我们看到虚拟机的文件路径是:

/Users/Kamus/Library/Containers/com.docker.docker/Data/vms/0/Docker.raw

进入到这个文件的所在目录。可以看到tty这个软链接文件。

$ cd /Users/Kamus/Library/Containers/com.docker.docker/Data/vms/0
$ ls -l
total 31067864
srwxr-xr-x  1 Kamus  staff            0  7  4 12:22 00000002.000005f4
srwxr-xr-x  1 Kamus  staff            0  7  4 12:22 00000002.00001000
srwxr-xr-x  1 Kamus  staff            0  7  4 12:22 00000002.00001001
srwxr-xr-x  1 Kamus  staff            0  7  4 12:22 00000002.0000f3a5
srwxr-xr-x  1 Kamus  staff            0  7  4 12:22 00000003.000005f5
srwxr-xr-x  1 Kamus  staff            0  7  4 12:22 00000003.00000948
-rw-r--r--@ 1 Kamus  staff  63999836160  7  7 12:51 Docker.raw
-rw-r--r--  1 Kamus  staff       215040  7  4 12:22 config.iso
srwxr-xr-x  1 Kamus  staff            0  7  4 12:22 connect
lrwxr-xr-x  1 Kamus  staff           17  7  4 12:22 guest.000005f5 -> 00000003.000005f5
lrwxr-xr-x  1 Kamus  staff           17  7  4 12:22 guest.00000948 -> 00000003.00000948
-rw-r--r--  1 Kamus  staff         2303  7  4 12:22 hyperkit.json
-rw-r--r--  1 Kamus  staff            4  7  4 12:22 hyperkit.pid
drwxr-xr-x  2 Kamus  staff           64 11 21  2018 log
-rw-r--r--  1 Kamus  staff           36 11 21  2018 nic1.uuid
lrwxr-xr-x  1 Kamus  staff           12  7  4 12:22 tty -> /dev/ttys000

screen该文件即可连接到虚拟机的输出窗口中。

$ screen tty

screen之后可能终端界面会悬停,按一下Ctrl+c,即可显示出已经登录到了虚拟机中。

linuxkit-025000000001:~# uname -a
Linux linuxkit-025000000001 4.9.125-linuxkit #1 SMP Fri Sep 7 08:20:28 UTC 2018 x86_64 Linux

登出screen界面可以使用Ctrl+a d(同时按住Ctrl和a,然后放开再按下d),重新登入,可以使用screen -r,如果要彻底结束screen,可以使用Ctrl+a k。

方法二

还可以使用更优雅的方式,临时建一个最小化的debian容器,指定容器运行在pid=host命名空间下,然后该容器运行nsenter命令。如果之前没有安装过依赖的debian镜像,那么会首先自动下载这个镜像,镜像很小,只有101MB。

$ docker run -it --rm --privileged --pid=host debian nsenter -t 1 -m -u -n -i sh
Unable to find image 'debian:latest' locally
latest: Pulling from library/debian
6f2f362378c5: Pull complete
Digest: sha256:118cf8f3557e1ea766c02f36f05f6ac3e63628427ea8965fb861be904ec35a6f
Status: Downloaded newer image for debian:latest

/ # uname -a
Linux linuxkit-025000000001 4.9.125-linuxkit #1 SMP Fri Sep 7 08:20:28 UTC 2018 x86_64 Linux

如果说觉得101MB的debian镜像还是太大了,那么可以选择下载Alpine Linux镜像,这个镜像只有5.56MB。

$ docker run -it --rm --privileged --pid=host alpine:edge nsenter -t 1 -m -u -n -i sh

详细解释一下这条命令为什么就会登录进macOS中作为宿主机的VM里面。
–rm表示在退出的时候就自动删除该容器;
–privileged表示允许该容器访问宿主机(也就是我们想要登录的VM)中的各种设备;
–pid=host表示允许容器共享宿主机的进程命名空间(namespace),或者通俗点儿解释就是允许容器看到宿主机中的各种进程;
这些是docker在启动容器时候的参数设置,但是仅仅依靠这些参数还无法让我们直接登录到宿主机VM中,接下来解释最主要的nsenter命令。

nsenter是一个小工具允许我们进入一个指定的namespace然后运行指定的命令,ns=namespace,enter=进入。
namespace是容器技术的根基,基本上可以认为namespace就是一组隔离的资源,不同的进程可以看到不同的系统资源这里这里有比较详细的关于namespace的介绍。
可以从操作系统的/proc/[pid]/ns目录下一窥全貌。比如我们进入pid=1的ns目录下。可以看到有一共8种namespace。

# pwd
/proc/1/ns
# ls -l
total 0
lrwxrwxrwx 1 root root 0 Jul  8 12:51 cgroup -> cgroup:[4026531835]
lrwxrwxrwx 1 root root 0 Jul  8 12:51 ipc -> ipc:[4026531839]
lrwxrwxrwx 1 root root 0 Jul  8 12:51 mnt -> mnt:[4026531840]
lrwxrwxrwx 1 root root 0 Jul  8 12:51 net -> net:[4026531889]
lrwxrwxrwx 1 root root 0 Jul  8 12:51 pid -> pid:[4026531836]
lrwxrwxrwx 1 root root 0 Jul  8 12:51 pid_for_children -> pid:[4026531836]
lrwxrwxrwx 1 root root 0 Jul  8 12:51 user -> user:[4026531837]
lrwxrwxrwx 1 root root 0 Jul  8 12:51 uts -> uts:[4026531838]

接下来我们通过一个例子来直观的感受一下namespace和nsenter的功能,由于没有现成的操作系统命令可以修改一个namespace用于演示,所以我们需要先在nbrownuk下载一段c函数源码,我们演示UTS namespace,这个相对直观,所以只需要下载invoke_ns3.c即可。
UTS namespace中包含了hostname,我们的演示计划是给一个进程设置一个新的hostname,然后用nsenter进入该进程的namespace查看。

下载完invoke_ns3.c之后,需要编译。

# gcc -o invoke_ns3 ./invoke_ns3.c
# ls -l
total 28
-rwxr-xr-x 1 root root 71928 Jul  8 13:41 invoke_ns3
-rw-r--r-- 1 root root  4603 Jul  8 13:38 invoke_ns3.c

使用新的hostname启动一个bash进程,15842是执行invoke_ns3命令的进程,而15843则是bash进程,接下来我们只需要用nsenter进入15843进程验证一下即可。

# ./invoke_ns3 -vu newhostname bash
Parent: PID of parent is 15842
Parent: PID of child is 15843
 Child: PID of child is 15843
 Child: executing command bash ...
[root@newhostname root]

启动一个新的终端。可以看到在终端自己的hostname没有变化的情况下,我们用nsenter进入不同的进程,看到的hostname是不同的,其中15843进程中显示的就是上面修改过的主机名。

# hostname
ecs-arm-4xlarge
# nsenter -t 1 -u hostname
ecs-arm-4xlarge
# nsenter -t 15843 -u hostname
newhostname

最后解释一下nsenter命令的选项。回顾一下命令是:nsenter -t 1 -m -u -n -i sh
-t 1: 表示要进入哪个pid,1表示整个操作系统的主进程id
-m: 进入mount namespace,挂载点
-u: 进入UTS namespace,也就是上面我们演示的那个namespace
-n: 进入network namespace,网络
-i: 进入IPC namespace,进程间通信
sh: 表示运行/bin/sh

到此为止:docker加上–pid=host加上nsenter,就让我们登录到了在macOS中作为docker容器宿主机的VM里。

方法三

实际上跟方法二一样,但是在方法二中,需要下载至少是alpine镜像这样的最简化Linux操作系统,虽然这个镜像只有5MB多,已经很小了,但是我们还是可以直接下载网络上其它人提供的单独的nsenter镜像,这样的镜像更小,大约只有几百KB。

walkerlee/nsenter镜像有583KB。

docker run --rm -it --privileged --pid=host walkerlee/nsenter -t 1 -m -u -i -n sh

justincormack/nsenter1镜像更小,只有101KB。

docker run -it --rm --privileged --pid=host justincormack/nsenter1

How to run PostgreSQL 11 in Linux on ARM

我们选择的系统是一个运行在AArch64芯片架构上的CentOS 7.5。

[root@ecs-arm-0005 ~]# uname -a
Linux ecs-arm-0005 4.14.0-49.el7a.aarch64 #1 SMP Tue Apr 10 17:22:26 UTC 2018 aarch64 aarch64 aarch64 GNU/Linux

[root@ecs-arm-0005 ~]# cat /etc/centos-release
CentOS Linux release 7.5.1804 (AltArch)

这台服务器拥有8颗ARMv8(Huawei Kunpeng 916 2.4GHz)的芯片,和29GB的内存,并不是很大的机器。

[root@ecs-arm-0005 ~]# cat /proc/cpuinfo | grep processor|wc -l
8

[root@ecs-arm-0005 ~]# cat /proc/meminfo | grep MemTotal
MemTotal:       29756224 kB

这台服务器有两块磁盘,一块是系统盘vda,一块是超高IO的数据盘vdb。vdb还没有创建文件系统,自然也没有挂载点。

[root@ecs-arm-0005 ~]# lsblk
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
vdb    253:16   0  100G  0 disk
vda    253:0    0   40G  0 disk
├─vda2 253:2    0 39.8G  0 part /
└─vda1 253:1    0  244M  0 part /boot/efi

将vdb格式化为ext4格式的文件系统,挂载到/data目录中。作为后续Pg数据库的数据文件存储位置。

[root@ecs-arm-0005 ~]# mkfs -t ext4 /dev/vdb
mke2fs 1.42.9 (28-Dec-2013)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
6553600 inodes, 26214400 blocks
1310720 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=2174746624
800 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
    32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
    4096000, 7962624, 11239424, 20480000, 23887872

Allocating group tables: done
Writing inode tables: done

[root@ecs-arm-0005 ~]# mkdir /data
[root@ecs-arm-0005 ~]# mount /dev/vdb /data
[root@ecs-arm-0005 ~]# df -h
Filesystem      Size  Used Avail Use% Mounted on
devtmpfs         15G     0   15G   0% /dev
tmpfs            15G     0   15G   0% /dev/shm
tmpfs            15G   22M   15G   1% /run
tmpfs            15G     0   15G   0% /sys/fs/cgroup
/dev/vda2        40G  1.6G   36G   5% /
/dev/vda1       244M  8.6M  236M   4% /boot/efi
tmpfs           2.9G     0  2.9G   0% /run/user/0
/dev/vdb         99G   61M   94G   1% /data

如果要保证在操作系统重新启动的时候,vdb还会自动挂载到/data目录下,还需要修改/etc/fstab文件,此处不赘述。

因为Pg for ARM的版本并没有发布实现编译好的二进制安装包(实际上也有,但是是比较古老的9.2版本),因此首先我们下载PostgreSQL数据库最新版本11.3的源码。通过编译源码手动安装。

如果在下述过程中发现报错:configure: error: no acceptable C compiler found in $PATH,则表示没有安装gcc编译器,需要通过yum install gcc gcc-c++命令来事先安装。
如果在下述过程中发现报错:configure: error: readline library not found,则表示没有安装readline-devel包,需要通过yum install readline-devel命令来事先安装。
如果在下述过程中发现报错:configure: error: zlib library not found,则表示没有安装zlib-devel包,需要通过yum install zlib-devel命令来事先安装。

总结一下就是需要事先安装以下依赖包。

yum install gcc gcc-c++ readline-devel zlib-devel

从configure到make install都是标准的Linux下编译源码安装的步骤。如果一切正常,在第一步时不会显示任何error,在第二步最后会显示:All of PostgreSQL successfully made. Ready to install.字样。

$ ./configure
$ make
$ su
# make install

成功安装完毕以后,因为我们使用的是默认配置,因此PostgreSQL软件被安装到/usr/local/pgsql目录中。

[root@ecs-arm-0005 postgresql-11.3]# ls -l /usr/local/pgsql
total 16
drwxr-xr-x 2 root root 4096 Jun  4 16:01 bin
drwxr-xr-x 6 root root 4096 Jun  4 16:01 include
drwxr-xr-x 4 root root 4096 Jun  4 16:01 lib
drwxr-xr-x 6 root root 4096 Jun  4 16:01 share

接下来创建postgres用户,而不要使用root用户管理数据库。

# adduser postgres
# passwd postgres

之前我们在/data目录下挂载了100GB的高速IO数据盘,所以下面我们将PostgreSQL数据库的数据文件存储位置指定到/data目录下,并初始化数据库。

# mkdir /data/pgsql/data
# chown postgres /data/pgsql/data
# su - postgres
$ /usr/local/pgsql/bin/initdb -D /data/pgsql/data

初始化数据库的正常显示如下。

[postgres@ecs-arm-0005 ~]$ /usr/local/pgsql/bin/initdb -D /data/pgsql/data
The files belonging to this database system will be owned by user "postgres".
This user must also own the server process.

The database cluster will be initialized with locale "en_US.UTF-8".
The default database encoding has accordingly been set to "UTF8".
The default text search configuration will be set to "english".

Data page checksums are disabled.

fixing permissions on existing directory /data/pgsql/data ... ok
creating subdirectories ... ok
selecting default max_connections ... 100
selecting default shared_buffers ... 128MB
selecting dynamic shared memory implementation ... posix
creating configuration files ... ok
running bootstrap script ... ok
performing post-bootstrap initialization ... ok
syncing data to disk ... ok

WARNING: enabling "trust" authentication for local connections
You can change this by editing pg_hba.conf or using the option -A, or
--auth-local and --auth-host, the next time you run initdb.

Success. You can now start the database server using:

    /usr/local/pgsql/bin/pg_ctl -D /data/pgsql/data -l logfile start

数据库初始化结束以后显示的最后一条命令,告知了如果要启动数据库应该使用的命令。

[postgres@ecs-arm-0005 ~]$ /usr/local/pgsql/bin/pg_ctl -D /data/pgsql/data -l logfile start
waiting for server to start.... done
server started

至此,PostgreSQL 11.3在CentOS 7.5 on ARM上的安装和运行宣告完成。

[postgres@ecs-arm-0005 ~]$ psql
psql (11.3)
Type "help" for help.

postgres=# \db
       List of tablespaces
    Name    |  Owner   | Location
------------+----------+----------
 pg_default | postgres |
 pg_global  | postgres |
(2 rows)

How to modify timezone settings in Docker Container

我们之前从Oracle官方docker仓库中生成的Oracle 19.3镜像,默认的时区并非是中国时区,这会让在查看alertlog等日志文件时比较困惑。

那么如何修改容器中的时区呢?

确认容器中已经包含了tzdata包

$ docker exec -it oracle19c_new rpm -qa|grep tz
tzdata-2019a-1.el7.noarch

通过-e参数设置容器运行的时区参数

$ docker run --name oracle19c_new \
-p 11521:1521 -p 15500:5500 \
-v /Users/Kamus/oracle/oradata/oracle19c:/opt/oracle/oradata \
-e TZ=Asia/Chongqing \
-e ORACLE_SID=ORCLNEW \
oracle/database:19.3.0-ee

检查新生成的容器的时区

$ docker exec -it oracle19c_new date +"%Z %z"
CST +0800

CST+0800表示东8时区,正是设置的中国时区。

如何在MarsEdit中使用Markdown编写文章

一直在寻找一个适合编写完毕以后直接发布到Wordpress中,同时又能完美支持Markdown语法的工具,尝试过Ulysess还有Typora,Ulysess本身对于Markdown的支持很奇怪,当粘贴的代码中有一些Markdown语法的关键字时,会出现很难编辑的情况;而Typora本身确实是很好的Markdown编辑器,但是无法直接将本地编写的文章一键发布到Wordpress中是致命弱点。

Setapp中近期引入了MarsEdit,这是一个较为著名的Blog编写工具,一键发布到Wordpress中是这类工具的标准功能,而稍作配置之后,又可以完美支持Markdown语法。

设置MarsEdit

首先需要设置MarsEdit
NewImage

NewImage

设置Wordpress

还需要设置Wordpress。在Wordpress中首先先安装Jetpack插件,实际上Jetpack已经基本上变为Wordpress的标准插件了。
在Jetpack插件的设置界面,将“使用Markdown语法编写纯文本文章”的选项勾上。
NewImage

用MarsEdit编写文章的优点

在MarsEdit中可以混用HTML和Markdown标志来编写文章,因此一些容易记忆的Markdown语法,比如标题,这是我最常用的Markdown语法,没有之一。比如代码块,对于写技术文章的人来说,代码块是非常方便的。

Markdown示例

以下是代码块的例子。

package main

import (
    "fmt"
    "database/sql"
    _ "gopkg.in/goracle.v2"

How to build and run Oracle Database 19c on Docker

Oracle官方已经正式发布了Oracle 19.3的dockerfile,在自己的笔记本上安装Oracle数据库,docker方式已然成为最简单的方式之一。另外的一种方式是rpm安装,但是要求操作系统是Linux。对于使用macOS的用户来说,Oracle on docker是非常优秀的体验和测试Oracle数据库的方法。

下载Oracle 19.3.0 for Linux安装盘

在OTN网站上下载最新的Oracle Database 19c for Linux x86-64的安装盘。

下载官方dockerfile

在任意目录下通过git方式将dockerfile下载到本地。这里我们创建了~/oracle目录。

mkdir ~/oracle 
cd ~/oracle
git clone https://github.com/oracle/docker-images.git

将下载的安装盘拷贝到dockerfile相同目录下

cp LINUX.X64_193000_db_home.zip ~/oracle/docker-images/OracleDatabase/SingleInstance/dockerfiles/19.3.0/

构建docker镜像

$ cd ~/oracle/docker-images/OracleDatabase/SingleInstance/dockerfiles 
$ ./buildDockerImage.sh -v 19.3.0 -e 

完成以后可以看到已经有成功构建的Oracle 19c docker image了,同时构建了Oracle Linux 7的基础镜像。

$ docker image ls 
REPOSITORY TAG IMAGE ID CREATED SIZE 
oracle/database 19.3.0-ee 04c75bcbb886 4 minutes ago 6.64GB
oraclelinux 7-slim f7512ac13c1b 3 weeks ago 118MB 

运行容器

完整的运行指南可以在git下来的官方dockerfile目录中找到。

docker-images/OracleDatabase/SingleInstance/README.md 

也可以从github页面中直接阅读 – Oracle Database on Docker

我们创建一个目录,以存储Oracle数据文件。

mkdir -p ~/oracle/oradata/oracle19c 

在第一次运行容器的时候,会自动创建新的数据库,使用-v参数,将之前新创建的目录映射到容器内的/opt/oracle/oradata目录中,这样就完成了将数据文件存储在本机文件系统中,而非docker容器内。

docker run --name oracle19c \
-p 1521:1521 \
-p 5500:5500 \
-v /Users/Kamus/oracle/oradata/oracle19c:/opt/oracle/oradata \
oracle/database:19.3.0-ee 

执行改命令之后,可以注意到第一行的回显列出了自动生成的SYS等用户的密码,本文中是sSNc5GFeSAg=1。

ORACLE PASSWORD FOR SYS, SYSTEM AND PDBADMIN: sSNc5GFeSAg=1 

如果需要修改数据库用户密码,可以在容器运行之后,通过以下命令修改。

docker exec <container name> ./setPassword.sh <your password> 

比如下面的例子,将数据库sys用户密码设置为简单的oracle(当然这不推荐)。

$ docker exec oracle19c ./setPassword.sh oracle
The Oracle base remains unchanged with value /opt/oracle

SQL*Plus: Release 19.0.0.0.0 - Production on Tue May 21 15:30:50 2019
Version 19.3.0.0.0

Copyright (c) 1982, 2019, Oracle.  All rights reserved.


Connected to:
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.3.0.0.0

SQL>
User altered.

SQL>
User altered.

SQL>
Session altered.

SQL>
User altered.

SQL> Disconnected from Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.3.0.0.0

一直到出现以下字样,表示数据库已经正常创建并且可以使用了。

######################### DATABASE IS READY TO USE! ######################### 

默认创建的数据库SID是ORCLCDB,创建的PDB是ORCLPDB1,也可以在第一次docker run的时候,用-e参数来指定SID和PDB的名字。比如:

docker run --name new-oracle19c \ 
-p 1521:1521 -p 5500:5500 \ 
-e ORACLE_SID=ORCL \ 
-e ORACLE_PDB=MYPDB1 \ 
-v /Users/Kamus/oracle/oradata/oracle19c:/opt/oracle/oradata \
oracle/database:19.3.0-ee 

测试容器中的Oracle 19c数据库

在成功运行完docker run命令以后,可以看到容器已经正常运行。

$ docker ps | grep oracle 
b03dae342bf5 oracle/database:19.3.0-ee "/bin/sh -c 'exec $O…" About an hour ago Up About an hour (healthy) 0.0.0.0:1521->1521/tcp, 0.0.0.0:5500->5500/tcp oracle19c 

直接登录容器使用sqlplus做简单的验证。注意使用之前docker run时候回显的用户密码。

$ docker exec -it oracle19c /bin/bash

SQL*Plus: Release 19.0.0.0.0 - Production on Mon May 6 04:42:04 2019
Version 19.3.0.0.0

Copyright (c) 1982, 2019, Oracle.  All rights reserved.


Connected to:
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.3.0.0.0

SQL> show con_id

CON_ID
------------------------------
3
SQL> 

也可以在浏览器中登录Oracle 19c内置的EM Express来通过图形界面访问和监控。

https://localhost:5500/em

Em express 19c

Popularity of open source DBMS versus commercial DBMS (by DB-Engines)

2018年盘点商业数据库VS.开源数据库 – Updated@2019-05-16

本文来源于DB-Engines的年度特别报告-Popularity of open source DBMS versus commercial DBMS。原文链接如下: https://db-engines.com/en/ranking_osvsc

被定义为开源系统的数据库,是全部能够自由获取源码,并且可以在遵循某种许可协议的情况下进行自由使用和改写的。

数据库个数

NewImage
DB-Engines总共列出了347种数据库,其中178种为商业数据库,169种为开源数据库,基本上可以认为是五五开的局面。

数据库流行度

NewImage
根据当年DB-Engines每个月的数据库排名分数进行的分数计算,商业数据库险胜开源数据库,但是分数相差无几。

流行度趋势

NewImage
从2013年开始统计了每一年的流行度,商业数据库一路下行,而开源数据库扶摇直上,从5年前只有1/3的流行度到今年跟商业数据库几乎平分天下,开源产品可谓是改变了世界。

按照数据库类型区分的流行度

NewImage
在宽列数据库,时间序列数据库,文本数据库,键值数据库,搜索引擎,图像数据库这几类数据库中,开源产品均领先于商业产品,很明显,互联网和互联网应用的兴起,海量数据存储和非结构化数据存储的需求,极大地促进了开源产品的产出和受欢迎程度。而从传统的关系型数据开始往后,包括XML数据库,面向对象的数据库等,仍然是商业数据库更受欢迎。

排名前5的商业数据库

NewImage
Oracle依然排名第一,但是微软在云端的更早发力,让SQL Server已经跟Oracle相差无几。

排名前5的开源数据库

NewImage
MySQL仍然排名第一,但是不可否认从2017年开始,PostgreSQL正在迅速地获得更多关注。

Oracle Announces Availability of Oracle Autonomous Transaction Processing(ATP)

在8月7日,Oracle宣布在云上正式上线自治事务处理数据库,这个名词ATP应对于早前发布的ADW(今年3月份Oracle宣布正式上线的自治数据仓库数据库)。 完整的发布会视频链接在这里

全自动

Atp1
Nothing to Learn, Nothing to Do. 这句宣传语在Larry的演讲中被重复了很多次。我们可以将自治数据库想象成自动驾驶,在没有自动驾驶之前,驾驶员要开一辆车从A地到B地,需要先考取驾照,还需要学习很多技巧,并且在开车的过程中仍然需要集中精力,否则容易出差错。但是有了自动驾驶(理想状态中的自动驾驶),我们不再需要驾驶员,乘客只需要告诉车辆我要从A地到B地,车辆就自动寻找最佳路线行驶了,在这个体验中,乘客完全不需要学些任何驾驶技巧,也不需要做任何驾驶的事情。这就是Nothing to Learn, Nothing to Do,那么在最新的Oracle自治数据库中,传统的DBA工作也不再需要了。安装、扩展、优化、安全、高可用、备份恢复等等,这些以往高深的技巧,现在统统不再需要学习,也不再需要DBA手工去做了。 恭喜大家,在传统DBA的职业道路上离失业又近了一步。

真.弹性

Atp2
Larry在整个演讲中,不知道说了多少次AWS,基本上就是盯着AWS打。只会为使用到的基础架构资源付费,没用到的不用付钱。如果把数据库从AWS上迁移到Oracle Cloud上的自治数据库里,承担的成本将减半,特意重点标注了“Guaranteed”,Larry拍着胸脯保证,账单数字一定会减半。

是骡子是马拉出来遛

Atp3
Atp4
Atp5
Larry接着连续用三页PPT叫板AWS,甚至在已经播放到下一环节以后,又请播放人员退回到上一页,持续嘲讽AWS。这就像60等级时候的魔兽世界,熟悉的“3破输出!”,Larry就是战士坦克,释放3个破甲,建立好仇恨,现在,DPS们可以输出了。 Oracle自治数据库,比AWS数据库快5-10倍。Larry,快5-10倍是什么意思?就是我用10秒钟干活的活儿,你AWS要干1分钟,在按照分钟计费的Cloud数据库中,这就意味着我比AWS要便宜5-10倍。 在纯的在线交易测试中,Oracle ATP比Aurora快12倍,在混合负载场景下,Oracle ATP比Aurora快100倍。在这一页上,Larry疯狂嘲讽了AWS,他说,AWS让别人用Aurora,用Redshift,但是他们自己却在用Oracle,在10年前,AWS就说要弃用Oracle数据库,但是到现在他们也没有做到。Larry还顺道一并嘲讽了SAP和Salesforce,他说这几个哥们儿都特别不想用Oracle数据库,但是怎么去也去不掉,因为这件事情真的很难很难,还因为Oracle数据库真的很优秀很优秀。 Oracle自治数据库可以在运行的同时实现安全补丁安装,可以让数据库获得99.995%的可用性,而AWS则做不到这一点,他们没办法在运行的时候为数据库打补丁。因此Oracle比Amazon稳定100倍。好吧,虽然我不知道这100倍的数字是怎么来的,但是Larry显得自信满满。

就是比AWS便宜

Atp6
整个演讲中间还有不少页,提及了Oracle自治数据库的优点,不过本来在这个世界上也确实没有比Oracle数据库单个解决方案更优秀的数据库产品了,因此Oracle数据库只是不断在超越自己,我们就不看了。我们总说,Oracle数据库除了贵没别的毛病,所以Larry在演讲快结尾的时候又再次提及了,这是我们写下来的承诺,能够满足客户业务负载的成本至少比Amazon便宜50%。

人干不过机器

Atp7
Larry在演讲的最后几分钟,举了NetSuite的案例。虽然PPT上的数字有些语焉不详,比如原来的8151个索引和下面的人类专家使用的4663个索引是什么关系?专家调优过的运行时间1172秒是运行了上面全部17542的SQL的总时长吗?但是,没关系,Oracle想说的是,Oracle ATP能够全自动地分析负载并创建更少更合适的索引,获得跟专家调优相近甚至更优的性能。 虽然为了公平起见,我们还是要提一下NetSuite是Oracle收购了的ERP厂商,但是毋庸置疑,人类传统DBA们面临了越来越多的挑战,就像前几天看到的新闻,DOTA2专业电子竞技高手被AI控制的机器完爆,打得找不到北。

免费品尝

Atp8
从Larry发表演讲的那一刻开始,就可以直接在Oracle Cloud网站申请免费测试Oracle ATP,但是在国内访问Oracle Cloud网站,特别是创建了免费账户以后登录进去的网站,遭遇了很强的阻碍。至少到目前为止,我还没有能成功地打开登录之后的第一个页面。欢迎期待我们测试以后的后续文章。

明年19c

Atp9
Larry简短地预报了Oracle数据库的路线图,在2019年一月份,将会发布Oracle 19c,还停留在11g时代的兄弟们,是不是应该感到惭愧了?

All Secondary die, Primary hang? – SQL Server 2017 on Linux

关于AVAILABILITY_MODE

需要注意的是,与Oracle Data Guard不尽相同的概念是,在Always On AG中每个replica上都可以设置自己的AVAILABILITY_MODE。
AVAILABILITY_MODE参数有三个可选值,分别是SYNCHRONOUS_COMMIT、ASYNCHRONOUS_COMMIT和CONFIGURATION_ONLY。

  • SYNCHRONOUS_COMMIT:同步提交,意味着主replica的事务必须等到备replica将变更日志写入磁盘中才可以提交。可以设置包括主replica在内的最多三个replica处于同步提交状态。
  • ASYNCHRONOUS_COMMIT:异步提交,意味着replica无需等待备replica的动作而可以直接提交成功。
  • CONFIGURATION_ONLY:仅同步AG配置元数据。设置为该值的replica仅会从主replica中将AF配置的元数据同步过来,不会同步任何用户表数据。

在一个多节点replica的AG环境中,如果:

  • 主库和其中任何一个备库设置为SYNCHRONOUS_COMMIT,则主库的日志提交必须等待该备库完成日志写入;
  • 主库设置为SYNCHRONOUS_COMMIT,而所有备库都设置为ASYNCHRONOUS_COMMIT,则主库无需等待;
  • 主库设置为ASYNCHRONOUS_COMMIT,则无视备库上该参数的设置,主库均无需等待。

在多节点的AG环境中,假设一个主库配置了两个同步的secondary,那么是不是要等待这两个secondary都完成日志写入才能提交事务呢?此时又引入了required_synchronized_secondaries_to_commit参数。

关于required_synchronized_secondaries_to_commit

required_synchronized_secondaries_to_commit参数是在SQL Server 2017中引入的,这个参数从直观意义上就可以看得出是指定当commit的时候需要有个几个同步的secondary replica存活。

这个参数在三节点的AG集群中,默认值为1,也就是如果至少要存活一个secondary replica,主库上的事务才可以提交,否则commit就会一直等待。这很好理解。
但是不好理解的是,该参数可以手工修改为0,从字面上看应该是说,即使所有secondary replica都不同步了,也是可以允许commit的。

但是实际情况却并非如此,修改为0是不起作用的。通过以下测试可以知道。

首先,设置required_synchronized_secondaries_to_commit参数为0

sudo pcs resource update ag_cluster required_synchronized_secondaries_to_commit=0
[Kamus@centos1 ~]$ sql
1> select name,required_synchronized_secondaries_to_commit from sys.availability_groups;
2> GO
name required_synchronized_secondaries_to_commit
------------------------------ -------------------------------------------
ag1                            0
(1 rows affected)

现在三个节点都是正常状态。

1> select r.replica_server_name,r.availability_mode_desc,r.session_timeout ,rs.connected_state_desc
2> from sys.availability_replicas r,sys.dm_hadr_availability_replica_states rs
3> where r.replica_id=rs.replica_id;
4> GO
replica_server_name            availability_mode_desc         session_timeout connected_state_desc
------------------------------ ------------------------------ --------------- ------------------------------
centos1                        SYNCHRONOUS_COMMIT             10 CONNECTED
centos2                        SYNCHRONOUS_COMMIT             10 CONNECTED
centos3                        SYNCHRONOUS_COMMIT             10 CONNECTED
(3 rows affected)

在主节点上进行Insert,可以成功,这很好。

1> insert into t1 select * from sys.databases;
2> GO
(6 rows affected)

停掉一个secodary replica。显示第二个节点已经DISCONNECTED。

1> select r.replica_server_name,r.availability_mode_desc,r.session_timeout ,rs.connected_state_desc
2> from sys.availability_replicas r,sys.dm_hadr_availability_replica_states rs
3> where r.replica_id=rs.replica_id;
4> GO
replica_server_name availability_mode_desc session_timeout connected_state_desc
------------------------------ ------------------------------ --------------- ------------------------------
centos1 SYNCHRONOUS_COMMIT 10 CONNECTED
centos2 SYNCHRONOUS_COMMIT 10 DISCONNECTED
centos3 SYNCHRONOUS_COMMIT 10 CONNECTED
(3 rows affected)

在主库上进行Insert,还是可以成功,这很好。

1> insert into t1 select * from sys.databases;
2> GO
(6 rows affected)

再停掉一个secodary replica。显示2、3节点都已经DISCONNECTED。

1> select r.replica_server_name,r.availability_mode_desc,r.session_timeout ,rs.connected_state_desc
2> from sys.availability_replicas r,sys.dm_hadr_availability_replica_states rs
3> where r.replica_id=rs.replica_id;
4> GO
replica_server_name availability_mode_desc session_timeout connected_state_desc
------------------------------ ------------------------------ --------------- ------------------------------
centos1 SYNCHRONOUS_COMMIT 10 CONNECTED
centos2 SYNCHRONOUS_COMMIT 10 DISCONNECTED
centos3 SYNCHRONOUS_COMMIT 10 DISCONNECTED
(3 rows affected)

在主库上执行Insert,此时hang住,这很不好。

1> insert into t1 select * from sys.databases;
2> GO

更讨厌的是,对于该表的查询也会hang住,这就更不好了。

2> select count(*) from t1;
3> GO

现在数据库中的等待是什么呢?确实是HADR_SYNC_COMMIT。

1> select STATUS,COMMAND,DATABASE_ID,WAIT_TYPE,WAIT_TIME from sys.dm_exec_requests where command='INSERT';
2> GO
STATUS COMMAND DATABASE_ID WAIT_TYPE WAIT_TIME
------------------------------ ------------------------------ ----------- ------------------------------ -----------
suspended INSERT 5 HADR_SYNC_COMMIT 1670
(1 rows affected)

如果我们更进一步做一个session的xevent trace,可以看到等待的是WaitForHarden,而Harden的意思即是remote replica的日志写入。现在主库在等待一个备库的日志完成写入,然后自己才能提交成功。在正常情况下,当主库不再需要等待备库而可以自行commit的情况下,在xevent trace中应该出现将备库的commit_policy标志为donothing状态,也就是在xevent中应该要出现hadr_db_partner_set_policy事件才是正常的,然而这里并没有出现。

但是我们明明把required_synchronized_secondaries_to_commit参数设置为0了,这很违反常识,不是吗?

结论

在SQL on Linux中如果设置了availability_mode为SYNCHRONOUS_COMMIT,那么必须至少有一个secondary replica(或者一个config node)是存活的,否则priamry replica中就不再允许任DML操作,而尝试对于某表进行DML之后,还会进一步阻塞对于该表的查询。即使设置了required_synchronized_secondaries_to_commit=0也是无效的。也许微软需要更新一下文档,明确说明在多个sync的secondary存在的情况下,该参数即使修改为0也仍然按照1来处理。
这是一个很奇怪的design,因为这强制去掉了当一个集群中所有备库都崩溃时,主库能够自动转为异步提交模式的功能,从而造成了所有备库失效则会影响主库业务正常进行这样一个大问题。
实际上这个design是在SQL on Linux 2017 CU1之后才修改的,在CU1之前还是允许当所有备库都失效以后,主库仍然是可以正常读写的。甚至在现在的文档中仍然保留了这样的描述。


以上文档描述来自:High availability and data protection for availability group configurations

这意味着在SQL Server 2017 CU 1之后,不再支持单纯的read-scale功能的AG了。虽然不太理解微软的SQL Server程序员是怎么考虑这个问题的,但是现状就是如此。

相比起Oracle的Data Guard而言,也就是现在SQL Server的AG只有同步(等同于DG的Maximum protection),异步(等同于DG的Maximum performance)这样两种方式,而缺少了DG的Maximum availability模式。
我只能认为这是一个设计理念的问题,微软的程序员更倾向于关注数据一致性,但是我期望在未来SQL Server可以对此进行改进。

Configuring Always On Availability Groups in SQL Server 2017 on Linux

在之前的预览版中,Public preview of the next release of SQL Server on Linux,Always On Availability Groups还是不支持的功能,但是在最新的SQL Server 2017 on Linux中,该功能已经引入。

准备测试环境的服务器

在Always On AG中如果需要自动Failover至少需要集群中有3台服务器,但是我只是测试功能,因此只使用了两台服务器。并且本文不涉及任何Pacemaker的设置,完全是数据库层面的AG配置。 我使用的是Google Compute Engine的2台VM,最低配的1vCPU,3.75GB内存。 如果要通过远程客户端配置SQL Server,则需要在VPC network的Firewall rules中将1433端口开放,如果是在虚拟机本地的sqlcmd中操作,则无需配置。 操作系统:CentOS7

$ cat /etc/centos-release CentOS Linux release 7.4.1708 (Core) 

在/etc/hosts中配置双方服务器的名称和IP地址的解析,以保证两台机器可以通过服务器名称互相访问。 重要!服务器主机的hostname必须少于等于15个字符,否则在配置过程会出现各种莫名其妙的权限报错。

安装SQL Server

SQL Server for Linux的安装非常简单,可以参考我之前的这篇文章。 Public preview of the next release of SQL Server on Linux

启用AlwaysOn AG功能

执行范围:在所有机器上执行 安装完的SQL Server,默认是没有启用AlwaysOn AG功能的,需要手工开启,开启的方法很简单。开启该功能需要重启数据库实例。

sudo /opt/mssql/bin/mssql-conf set hadr.hadrenabled 1 sudo systemctl restart mssql-server 

启用AlwaysOn_health事件

执行范围:在所有机器上执行 这一步不是必须的。

ALTER EVENT SESSION AlwaysOn_health ON SERVER WITH (STARTUP_STATE=ON); 

创建数据库复制的用户

执行范围:在所有机器上执行

CREATE LOGIN dbm_login WITH PASSWORD = ‘YourPassword’; CREATE USER dbm_user FOR LOGIN dbm_login; 

创建认证

执行范围:在Primary Replica机器上执行

CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'YourPassword'; CREATE CERTIFICATE dbm_certificate WITH SUBJECT = 'dbm'; BACKUP CERTIFICATE dbm_certificate TO FILE = '/var/opt/mssql/data/dbm_certificate.cer' WITH PRIVATE KEY ( FILE = '/var/opt/mssql/data/dbm_certificate.pvk', ENCRYPTION BY PASSWORD = 'YourPassword' ); 

将生成的dbm_certificate.cer和dbm_certificate.pvk文件scp到另外一台服务器的相同位置并修改属主,这台服务器就是Secondary Replica。

cd /var/opt/mssql/data chown mssql:mssql dbm_certificate.* 

然后在这台服务器上导入认证。 执行范围:在Secondary Replica机器上执行

CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'YourPassword'; CREATE CERTIFICATE dbm_certificate AUTHORIZATION dbm_user FROM FILE = '/var/opt/mssql/data/dbm_certificate.cer' WITH PRIVATE KEY ( FILE = '/var/opt/mssql/data/dbm_certificate.pvk', DECRYPTION BY PASSWORD = 'YourPassword' ); 

创建数据库复制的Endpoint

执行范围:在所有机器上执行

CREATE ENDPOINT [Hadr_endpoint] AS TCP (LISTENER_PORT = 5022) FOR DATA_MIRRORING ( ROLE = ALL, AUTHENTICATION = CERTIFICATE dbm_certificate, ENCRYPTION = REQUIRED ALGORITHM AES ); ALTER ENDPOINT [Hadr_endpoint] STATE = STARTED; use master GRANT CONNECT ON ENDPOINT::[Hadr_endpoint] TO [dbm_login]; 

创建Availability Groups

执行范围:在Primary Replica机器上执行

CREATE AVAILABILITY GROUP [ag1] WITH (CLUSTER_TYPE = EXTERNAL) FOR REPLICA ON N'centos1' WITH ( ENDPOINT_URL = N'tcp://centos1:5022', AVAILABILITY_MODE = SYNCHRONOUS_COMMIT, FAILOVER_MODE = EXTERNAL, SEEDING_MODE = AUTOMATIC ), N'centos2' WITH ( ENDPOINT_URL = N'tcp://centos2:5022', AVAILABILITY_MODE = SYNCHRONOUS_COMMIT, FAILOVER_MODE = EXTERNAL, SEEDING_MODE = AUTOMATIC ); ALTER AVAILABILITY GROUP [ag1] GRANT CREATE ANY DATABASE; 

在主库上创建了AG之后,备库需要加入AG。 执行范围:在Secondary Replica机器上执行

ALTER AVAILABILITY GROUP [ag1] JOIN WITH (CLUSTER_TYPE = EXTERNAL); ALTER AVAILABILITY GROUP [ag1] GRANT CREATE ANY DATABASE; 

将数据库加入AG

这里新建一个数据库db1,将它加入到ag1中。由于上面设置的SEEDING_MODE参数为AUTOMATIC,因此这个db1数据库将会在备库实例中自动创建,后续对于该库进行的任何操作也会自动复制到备库中。 执行范围:在Primary Replica机器上执行

CREATE DATABASE [db1]; ALTER DATABASE [db1] SET RECOVERY FULL; BACKUP DATABASE [db1] TO DISK = N'/var/opt/mssql/data/db1.bak'; ALTER AVAILABILITY GROUP [ag1] ADD DATABASE [db1]; 

允许Secondary Replica可以被只读访问

在以上的创建过程中创建出来的AG中的备库是不允许被访问的,如果要访问将会遇到以下错误。 The target database, ‘db1’, is participating in an availability group and is currently not accessible for queries. Either data movement is suspended or the availability replica is not enabled for read access. To allow read-only access to this and other databases in the availability group, enable read access to one or more secondary availability replicas in the group. For more information, see the ALTER AVAILABILITY GROUP statement in SQL Server Books Online. 执行范围:在Primary Replica机器上执行,立刻生效。

use master ALTER AVAILABILITY GROUP ag1 MODIFY REPLICA ON N'centos2' WITH ( SECONDARY_ROLE (ALLOW_CONNECTIONS = ALL ) ); 

测试

在主库中随便创建一张新表,再插入几条记录。

1> use db1 2> select * into t_test from sys.databases; 3> insert into t_test select * from t_test; 4> GO Changed database context to 'db1'. (5 rows affected) (5 rows affected) 

在备库中查询,这张表已经复制成功。

1> use db1 2> select count(*) from t_test; 3> GO Changed database context to 'db1'. ------- 10 (1 rows affected) 

如果在备库中尝试更新数据,将会遇到以下错误。

1> delete from t_test; 2> GO Msg 3906, Level 16, State 2, Server centos2, Line 1 Failed to update database "db1" because the database is read-only. 

监控AG状态

通过以下这些视图可以监控AG中各个部分的状态。 group的监控

select * from sys.availability_groups; select * from sys.availability_groups_cluster; select * from sys.dm_hadr_availability_group_states; 

replica的监控

select * from sys.availability_replicas; select * from sys.dm_hadr_availability_replica_states; select * from sys.dm_hadr_availability_replica_cluster_nodes; select * from sys.dm_hadr_availability_replica_cluster_states; 

在AG中的database的监控

select * from sys.availability_databases_cluster; select * from sys.dm_hadr_database_replica_states; select * from sys.dm_hadr_database_replica_cluster_states; select name,database_id,replica_id,group_database_id from sys.databases; 

参考文档

本文配置步骤的参考文档为: https://docs.microsoft.com/en-us/sql/linux/sql-server-linux-availability-group-configure-ha?view=sql-server-linux-2017