Monthly Archives: January 2019

docker中将MySQL运行在容器中失败提示“ InnoDB : Error 22 with aio_write”的解决办法

Posted on by

今天利用docker容器创建mysql8.0的时候(window系统），指定了本地宿主机器的一个目录为容器mysql的datadir目录，发现创建失败了。

创建命令：

$ docker run -d --name mysql81 -v /e/container/mysql/mysql81/datadir:/var/lib/mysql -e MYSQL_ROOT_PASSWORD=123456 -p 33081:3306 mysql

错误提示：

$ docker logs mysql81
2019-01-26T03:05:42.567230Z 0 [Warning] [MY-011070] [Server] 'Disabling symbolic links using --skip-symbolic-links (or equivalent) is the default. Consider not using this option as it' is deprecated and will be removed in a future release.
2019-01-26T03:05:42.567618Z 0 [System] [MY-010116] [Server] /usr/sbin/mysqld (mysqld 8.0.13) starting as process 1
2019-01-26T03:05:42.572006Z 0 [Warning] [MY-010159] [Server] Setting lower_case_table_names=2 because file system for /var/lib/mysql/ is case insensitive
2019-01-26T03:05:42.832344Z 1 [ERROR] [MY-012592] [InnoDB] Operating system error number 22 in a file operation.
2019-01-26T03:05:42.832473Z 1 [ERROR] [MY-012596] [InnoDB] Error number 22 means 'Invalid argument'
2019-01-26T03:05:42.832556Z 1 [ERROR] [MY-012646] [InnoDB] File ./#innodb_temp/temp_1.ibt: 'aio write' returned OS error 122. Cannot continue operation
2019-01-26T03:05:42.832609Z 1 [ERROR] [MY-012981] [InnoDB] Cannot continue operation.

解决办法：

docker run -u 1000:50 -d --name mysql81 -v /e/container/mysql/mysql81/datadir:/var/lib/mysql -e MYSQL_ROOT_PASSWORD=123456 -p 33081:3306 mysql --innodb-use-native-aio=0

参数：

-u 表示运行实例的用户，这里的 1000:50 表示的是docker这个用户
–innodb-use-native-aio=0 为MySQL的参数，作用是启用异步操作功能，提高MySQL性能

注意：
上面使用了docker运行了mysql实例，则如果进入到容器内部进行一些其它需要高级权限的操作的话，如apt update则会提示权限不足的情况。

参考：https://github.com/docker-library/mysql/issues/371

docker build . 命令后面的.是什么意思

Posted on by

今天来公司自己构建了一个Dockerfile,放在一个经常用到的项目目录里，内容如下：

# This is a comment
FROM ubuntu:14.04
MAINTAINER Docker Newbee <newbee@docker.com>
RUN apt-get -qq update
RUN apt-get -qqy install ruby ruby-dev
RUN gem install sinatra

然后执行

sudo docker build -t "cfanbo/test:v2" .

发现在构建的时候发送给 docker daemon 竟然有4G多，超极大。首先的第一反映出问题了。一个ubuntu镜像也没有这么大呀，况且现在还没有开始从远程pull 镜像呢。

那到底什么情况了呢？经过一翻搜索，发现在docker build . 的时候，会将当前目录里的内容发送给 docker daemon。只需要加一个 .dockerignore 文件，将其它内容排除掉就可以了，类似于git中的.gitignore文件的作用。

后面就想通过docker build -h 命令查看一下相关的参数，发现对于Dockerfile 文件位置需要 -f 参数指定，并非上面命令后面的.符号。那就有些疑惑了，原来学习的时候一直把.当作当前目录指定的。难道.有其它的作用，后面查看了一些文档，发现一直对 docker build 命令的过程不太了解。通过查找了一些资料才发现它的真正作用。

Docker 在运行时分为 Docker引擎（服务端守护进程） 以及 客户端工具，我们日常使用各种 docker 命令，其实就是在使用客户端工具与 Docker 引擎 进行交互。

那么当我们使用 docker build 命令来构建镜像时，这个构建过程其实是在 Docker引擎 中完成的，而不是在本机环境。

那么如果在 Dockerfile 中使用了一些 COPY 等指令来操作文件，如何让 Docker引擎 获取到这些文件呢？

这里就有了一个镜像构建上下文的概念，当构建的时候，由用户指定构建镜像的上下文路径，而 docker build 会将这个路径下所有的文件都打包上传给 Docker 引擎，引擎内将这些内容展开后，就能获取到所有指定上下文中的文件了(参考下方docker架构图)。

比如说 dockerfile 中的 COPY ./package.json /project，其实拷贝的并不是本机目录下的 package.json 文件，而是 docker引擎中展开的构建上下文中的文件，所以如果拷贝的文件超出了构建上下文的范围，Docker引擎是找不到那些文件的。


Docker构架

所以 docker build . 最后的 . 号，其实是在指定镜像构建过程中的上下文环境的目录。

理解了上面的这些概念，就更方便的去理解 .dockerignore 文件的作用了。

为验证.的作用，我们可以创建一个空的目录，在目录里执行 

docker build -f /home/tom/Dockerfile .

会发现命令完全正常执行。

python中的@staticmethod和@classmethod区别(整理)

Posted on by

问题：Python中 @staticmethod 和 @classmethod 两种装饰器装饰的函数有什么不同？
原地址：http://stackoverflow.com/questions/136097/what-is-the-difference-between-staticmethod-and-classmethod-in-python

Python其实有3类方法：

  • 静态方法（staticmethod）
  • 类方法（classmethod）
  • 实例方法（instance method）

看一下下面的示例代码：

def foo(x):
    print "executing foo(%s)" %(x)

class A(object):
    def foo(self,x):
        print "executing foo(%s,%s)" %(self,x)

    @classmethod
    def class_foo(cls,x):
        print "executing class_foo(%s,%s)" %(cls,x)

    @staticmethod
    def static_foo(x):
        print "executing static_foo(%s)" %x

a = A()

在示例代码中，先理解下函数里面的 self 和 cls。这个 self 和 cls 是对类或者实例的绑定，对于一般的函数来说我们可以这么调用foo(x)，这个函数就是最常用的，它的工作和任何东西（类、实例）无关。对于实例方法，我们知道在类里每次定义方法的时候都需要绑定这个实例，就是foo(self,x)，为什么要这么做呢？因为实例方法的调用离不开实例，我们需要把实例自己传给函数，调用的时候是这样的a.foo(x)（其实是foo(a,x)）。类方法一样，只不过它传递的是类而不是实例， 如A.class_foo(x)。注意这里的 self 和 cls 可以替换别的参数，但是python的约定是这两个，尽量不要更改。

对于静态方法其实和普通的方法一样，不需要对谁进行绑定，唯一的区别是调用时候需要使用a.static_foo(x)或A.static_foo()来调用。

\实例方法类方法静态方法
a = A()a.foo(x)a.class_foo(x)a.static_foo(x)
A不可用A.class_foo(x)A.static_foo(x)

那么对于类方法和静态方法都可以不实例对象来调用，那两者的区别又有哪些呢？

从它们的使用上来看

  • @staticmethod 不需要表示自身对象的self和自身类的cls参数，就跟使用函数一样。
  • @classmethod 也不需要self参数，但第一个参数需要是表示自身类的cls参数。

如果在@staticmethod中要调用到这个类的一些属性方法，只能直接 类名.属性名或 类名.方法名。

而@classmethod因为持有 cls 参数，可以来调用类的属性，类的方法，实例化对象等，避免硬编码。

代码:

class A(object):
    bar = 1
    def foo(self):
        print 'foo'
 
    @staticmethod
    def static_foo():
        print 'static_foo'
        print A.bar
 
    @classmethod
    def class_foo(cls):
        print 'class_foo'
        print cls.bar
        cls().foo()
 
A.static_foo()
A.class_foo()
输出
static_foo
1

class_foo
1
foo

摘自：
https://www.cnblogs.com/taceywong/p/5813166.html
https://blog.csdn.net/handsomekang/article/details/9615239