Moving MySQL Group Replication instances to Docker container on macOS

前提条件,已经在自己的macOS操作系统中设置成功了都运行在本地的3节点MySQL Group Replication集群,如何设置,可以参考官方文档中的Deploying Group Replication in Single-Primary Mode。 假设在我们的macOS上已经实现了如下了架构的3节点MGR集群,我们的目标是将这三个数据库全部挪到docker容器中去运行,并且可以互相通信,仍然是MGR集群。 Docker on macOS 接下来我们把MySQL放在一边,先介绍一下在macOS中的docker架构,在macOS中,docker的实现跟在其它Linux系统中略有不同,在其它Linux系统中,操作系统本身就是docker容器的宿主机,docker镜像都是直接存储在宿主机本身的文件系统中,比如我们通过docker info命令可以看到docker的根目录是: $ docker info|grep “Docker Root Dir” Docker Root Dir: /var/lib/docker 但是在macOS下,我们直接查看这个目录,其实是根本不存在的。 $ ls /var/lib/docker ls: /var/lib/docker: No such file or directory Docker宿主机是谁 那么这个目录到底在哪里?实际上是在一个QEMU虚拟机中,当我们在macOS中安装完docker并启动,就是启动了一个虚拟机,这个虚拟机的整个内容全部都在一个文件里,可以在docker程序属性界面中看到这个文件的路径,比如在我的机器上,路径就是/Users/Kamus/Library/Containers/com.docker.docker/Data/com.docker.driver.amd64-linux/Docker.qcow2,该文件通常比较大,特别是安装了多个docker镜像之后,会轻易占用到数十GB的空间。 如上图所示,就是Disk image location的位置。 从上图中同样可以看到,这个虚拟机被限制只能使用2颗CPU和2GB内存。 那么,我们是否可以登录这个虚拟机来确认这点呢?使用macOS自带的screen命令可以登录该台虚拟机。如下,可以看到这是一个拥有非常新的Linux 4.9.38版本内核的虚拟机,在这个虚拟机中才有/var/lib/docker目录,只有2颗CPU,总共有2GB内存。 $ screen /Users/Kamus/Library/Containers/com.docker.docker/Data/com.docker.driver.amd64-linux/tty / # uname -a Linux moby 4.9.38-moby #1 SMP…

MySQL Enterprise Audit in Oracle MySQL Cloud Service

Oracle Cloud Service似乎是唯一个即使你只提交了创建RDS服务的请求,也会自动帮你创建一个虚拟主机,并且提供主机登录权限的服务提供商,也许这就是Oracle一直在宣称的IaaS+PaaS的整合。 在创建MySQL Cloud Service时,会要求提供一个SSH登录密钥,所有的Oracle云服务主机登录用户都是opc,因此在服务创建完毕,收到通知邮件之后,就可以通过以下命令登录到云主机上。 ssh -i id_rsa_oracle_cloud_enmotech opc@your_host_ip 登录到主机以后,屏幕欢迎词是个小惊喜,Oracle贴心得显示了MySQL运行状态和存储使用量的提示。 在比较了多方的RDS之后,Oracle MySQL Cloud Service确实如一直以来宣传的那样,提供了最多的安全选件功能,如果我们用MySQL Workbench登录到数据库中,在Server Status页面可以看到:SSL连接,PAM验证,密码校验,数据库审计等多种安全功能全部是开启的。 而与之相比,阿里云MySQL RDS提供的安全功能就少的可怜了。说少不合适,是一项安全功能都没开启。 Oracle对于数据库安全性的看重确实超越了大多数数据库提供商,而这也带来了一些小麻烦。 在创建MySQL云服务的时候,需要指定数据库root用户的密码,这个密码有比较强的安全要求,需要有大写、小写英文字母,有数字,同时还需要有特殊字符(比如#)。因此在后续创建Login Path时,在mysql_config_editor命令提示输入密码的时候,需要在密码前后加上双引号(比如”Passw#rd”),否则会一直出现拒绝访问的提示。 –opc用户没有办法直接登录MySQL,需要切换到oracle用户 [opc@mysql-cloud-mysql-1 ~]$ mysql -uroot -p Please switch to “oracle” user to use mysql client [opc@mysql-cloud-mysql-1 ~]$ sudo su – oracle –使用密码直接登录是没有问题的 [oracle@mysql-cloud-mysql-1 ~]$ mysql -uroot -p Enter password: Welcome to the MySQL…

How to Set MySQL Group Replication into Multi-Primary Mode

在MySQL 5.7.17版本中发布的MySQL Group Replication(后文简称为MGR)被很多人称为MySQL复制方案的正规军,可以一举取代现在的MySQL Replication,Semisynchronous replication,甚至是可以取代之前最成功的MySQL集群方案Galera。 MGR有两种模式,一种是Single-Primary,一种是Multi-Primary,单主或者多主。 在前一种模式Single-Primary中,无论集群中有多少个节点,只有一个节点允许写入,其它节点都是只读的,这个允许写入的节点被称为主节点,只有当这个主节点出现问题从集群中被踢出,才会在剩余的节点中选举出另外一个节点成为新的主节点,并且将该节点置为可写模式。 这个过程可以通过log清晰地看到。 2017-03-16T02:04:32.689278Z 0 [Note] Plugin group_replication reported: ‘getstart group_id 4317e324’ 2017-03-16T02:04:33.081743Z 0 [Note] Plugin group_replication reported: ‘Unsetting super_read_only.’ 2017-03-16T02:04:33.081756Z 28 [Note] Plugin group_replication reported: ‘A new primary was elected, enabled conflict detection until the new primary applies all relay logs’ 而在后一种模式Multi-Primary中,所有的节点都是主节点,都可以同时被读写,看上去这似乎更好,但是因为多主的复杂性,在功能上如果设置了多主模式,则会有一些使用的限制,比如不支持Foreign Keys with Cascading Constraints。 在多主模式下,集群中的节点退出集群,也不再会出现重新选举的动作,因为本来所有的节点都是Primary节点。 前面这些并不是本文的重点,实际上在5.7.17的官方文档中有详细地描述如何设置Single-Primary…