关于postgresql容器的信息

postgresql在docker上运行性能怎么样

有一件事触动了我。当我解释和回答Docker初学者提出的问题时，我发现其中一个很普遍，那就是当老的解决方案仍然可以解决现有问题时，大家又在寻找新的解决方案。

工程师有一个癖好，就是忘记他们所知道的，然后他们可以不用做太多改变，而在一个新的范例中很大程度上运用这些已经掌握的知识。所以最终，这篇博客有三个目的：

给你一个例子使用Docker执行使用

提醒你，你在docker到来之前所获得的知识仍然是有用的

帮助你构建将这个知识放到容器中的思维

真的，这篇文章可以被称为备份RDBMS和Docker，但我需要一些具体的例子。因为这篇文章是关于PostgreSQL触发的问题，我决定就这样做。

这里的情况。有一个PostgreSQL服务器运行在一个Docker容器，和你非常满意的这两个很棒的软件的结合。但是你是一个聪明的人，你知道，迟早，您将需要备份的数据库。也许硬件将会失败，或者新的实习生将会失败，你永远不会知道的。所以你决定定期备份数据库。

但是如何做到这一点。PostgreSQL运行在Docker中，并没有明显的方式访问数据。

问题可以归结为对您的PostgreSQL实例运行pg_dump，和你有三种方式实现这一目标。

根据您的版本的Docker，使用nsenter或Docker执行以获得shell在容器内，并将您的数据(使用pg_dump)转储到一个共享卷(postgres容器运行PostgreSQL的名称):

docker exec postgres pg_dump -h db -f /shared/backup.sql

但我们可以做的更好，对吗?理想的流程将涉及能够连接到PostgreSQL无需一个shell的容器。有两种方法可以做到这一点。

首先，用容器的一切方法。你建立一个pg_dump容器(这是一个容器，pg_dump作为它的入口点)，并将其链接到PostgreSQL容器在运行时。这里有一个 pg_dump容器的Dockerfile

用 docker build 构建

注意：建立一个特定的容器pg_dump不是强制性的。Damien如上所述的评论,你重新使用 包含 pg_dump在内的PostgreSQL镜像一点儿问题都没有。我们在这里建立一个容器是因为要练习。

运行：

在你的PostgreSQL postgres的容器中运行。

相关问答

Q1: docker-compose 安装postgres（设置默认用户名，密码，暴露端口）

docker、docker-compose 安装 - 简书 (jianshu.com)

volumes：将本地/user/local/docker/postgre/data挂在到容器中/var/lib/postgresql/data/pgdata

需要修改两个地方：容器内pg_hba.conf 和postgresql.conf 配置文件

由于我们做了映射，只需要修改宿主机的配置即可：

修改pg_hba.conf

修改postgresql.conf

END!

Q2: 通过Docker部署Odoo14

为了保存数据，在容器关闭或者删除后仍然可以使用数据，可以添加数据路径

这样就建立一个名称为db的容器，在PostgreSQL server重启后，连接到db容器的Odoo同时也需要重新启动。

- 指定存储文件的卷，这样容器被删除后数据依然可以保留：

- 指定插件目录

- 指定配置文件，替代容器的配置文件

- 使用多个不同端口的odoo容器

Q3: 如何在Kubernetes中部署一个高可用的PostgreSQL集群环境

虽然 kubernetes 社区一直在努力使得有状态应用成为一等公民，也推出了 statefulset 控制器支持 pod 的顺序部署，稳定的域名访问和存储访问。但鉴于 MySQL 部署运维的多样性和复杂性，在 kubernetes 上部署 MySQL 仍然要面临众多挑战。

1、业务流量入口的配置方式

传统虚拟机环境下，我们通过虚IP的方式，让业务应用都配置事先定义的一个虚IP为链接数据库的地址，然后由高可用服务保证虚IP始终能被路由到master数据库。在kubernetes中，出现了一层网络插件屏蔽了底层网络拓扑，高可用服务管理虚IP的方式需要随之适应调整，比如通过service结合标签完成虚IP的漂移，但service本身是kubernetes提供的一项功能，其可靠性和性能都取决于kubernetes服务的稳定。以性能来说，service是kubeproxy组件通过配置iptables实现的，当iptables规则较多时不可避免的会产生时延，需要我们针对性的解决。

2、容器隔离带来的监控视野问题

在 kubernetes 中，如果将 MySQL 制作为 container 运行在一个 pod 中，container 会将 MySQL 进程和运行环境隔离在一个单独的 namespace 中。监控组件在获取 MySQL 的一些 metirc 时，可能不得不进入与 MySQL 同一个 namespace 中，在部署和设计监控组件时需要考虑到这些限制。

3、存储在 kubernetes 中，支持配置各种不同的存储。

如果使用本地存储 local persistent volume，则需要绑定 MySQL 在一个固定的节点，这就完全浪费了 kubernetes 灵活调度的天然优势；而如果使用远程共享存储，确实是将 MySQL 进程与其存储完全解耦，使得 MySQL 进程可以在任意节点调度，然而考虑到高 I/O 吞吐量的情况，就不是那么美好了。设计时需要考量远程存储是否能够满足 MySQL 的带宽要求。

4、高可用/备份恢复

kubernetes 提供的 statefulset 控制器只能提供最基本的部署，删除功能，无法实现完善的 MySQL 集群高可用/备份恢复操作。对于有状态应用的部署，仍需要定制开发，所以多数公司提供了定制的 operator 来完成应用容器的管理。比如 etcd operator，MySQL operator，后文将为大家详述我测试使用 MySQL operator 的一些记录。