Japin

今天遇到一个 git 远程仓库分支同步的问题，主要的诉求是将两个远程仓库的分支同步到一致状态。起初，项目只是在 GitHub 上进行维护，后期又在 GitLab 上创建了该项目，并且两个仓库之间的分支情况有所不同。我们可以使用如下命令同步两个远程仓库之间的分支信息。

1
2
3

$ git fetch --all -p
$ git push github "refs/remotes/gitlab/*:refs/heads/*"
$ git push gitlab "refs/remotes/github/*:refs/heads/*"

备注： github 指向远端的 GitHub 项目地址，同理，gitlab 指向远端的 GitLab 项目地址。

PostgreSQL 标榜自己为最先进 (Most Advance) 的开源关系数据库，它支持大部分 SQL 标准并且提供了许多其他现代特性：复杂查询、外键、触发器、视图、事务完整性、MVCC。同样，PostgreSQL 可以用许多方法扩展，比如，通过增加新的数据类型、函数、操作符、聚集函数、索引。PostgreSQL 被设计为易于扩展，因此通过插件我们可以很容易的扩展 PostgreSQL 数据库。本文就从编写一个简单的斐波那契的数据库扩展来介绍 PostgreSQL 插件的编写。

本文主要收集日常工作中经常使用的 PostgreSQL 相关的命令；其中，主要包含相关的系统函数、使用技巧等。本文将持续更新！！！

备注： 主要基于 PostgreSQL 10 及其后续版本。

Python 的 gettext 模块为应用程序提供了国际化 (Internationalization, I18N) 和本地化 (Localization, L10N) 的服务。该模块提供了两类 APIs：(a) 支持 GNU gettext 的基本 API；(b) 适合 Python 的并且基于类的 API。本文主要针对第二类 API 进行介绍。

为了向 Python 程序提供多语言消息，我们需要按以下步骤进行：

1. 使用包装函数对程序中所有可以翻译的字符串进行标记；
2. 使用 xgettext 在标记的文件上生成原始消息目录或 POT 文件；
3. 将 POT 文件复制到特定的区域设置目录并进行翻译（需要使用专用的编辑器）；
4. 导入并使用 gettext 模块，以便正确转换消息字符串。

在上一篇中我介绍了如何安装和使用列存数据库 cstore_fdw。接着，我将在本篇中介绍 cstore_fdw 是如何实现的。

Cstore_fdw 是基于 PostgreSQL 开发的一款列存数据库，它采用 ORC 作为低层的物理存储格式 (有部分改动)，使用 protobuf 进行序列化并采用 PostgreSQL 外部插件的形式集成到数据库中。Cstore_fdw 包含 3 个头文件以及 5 个源文件：

• cstore_compression.c - 该文件包含 cstore_fdw 使用的压缩和解压缩的算法实现。
• cstore_fdw.c - 该文件包含列存扫描、分析以及复制数据到 cstore_fdw 外部表的函数的定义。它使用了 cstore_reader 和 cstore_writer 提供的 API 接口来读写 cstore 文件。
• cstore_fdw.h - 该文件包含 cstore_fdw 使用的类型及函数声明。
• cstore_metadata_serialization.c - 该文件包含 cstore_fdw 序列化和反序列化元数据的函数的实现。
• cstore_metadata_serialization.h - 该文件包含 cstore_fdw 序列化和反序列化元数据的函数的声明。
• cstore_reader.c - 该文件包含读取 cstore 文件的函数定义。它包括读取文件元数据，row stripes 以及跳跃不相关的数据块或列数据。
• cstore_version_compat.h - 该文件包含用于编写与 PostgreSQL 版本无关的代码宏。
• cstore_writer.c - 该文件包含写入 cstore 文件的函数定义。它包括写入文件元数据，row stripes 以及计算跳跃块节点信息。

无论何时，PostgreSQL 总是在集群的数据目录 pg_wal 下面维护一个 Write Ahead Log 日志记录。该日志记录了数据文件的所有变化。当数据库系统发生崩溃时，数据库系统可以通过重放最新检查点之后的 WAL 日志条目来恢复数据库的一致性。在 PostgreSQL 中，我们通过将文件系统级的备份与 WAL 日志的备份相结合可以实现三种策略的数据库备份。当需要进行数据库恢复时，我们先恢复文件系统的备份，随后通过重放备份的 WAL 日志使得数据库进入到当前状态。尽管该方法过于复杂，但是它拥有以下好处：

• 我们不需要完全一致的文件系统备份作为起点。备份中的任何内部不一致都将通过日志重放进行更正 (这与崩溃恢复期间发生的情况没有显着差异)。因此，我们不需要文件系统快照功能，只需要 tar 或类似的归档工具。
• 没有必要一直重放 WAL 条目到最后。我们可以在任何时候停止重放并拥有当时数据库的一致快照。因此，该技术支持时间点恢复 (Point-in-Time Recovery, PITR)。为此，我们可以将数据库还原到自从进行基本备份以后的任何状态。
• 如果我们持续地将一系列 WAL 日志文件提供给另一台已加载相同基本备份文件的计算机，此时，我们就拥有了一个热备系统：在任何时候我们都可以启动这台机器，它将拥有与原数据库几乎一致的状态。

与普通文件系统备份技术一样，该方法只能支持恢复整个数据库集群，而不能用于恢复其子集。同时，它也需要更多的归档空间：基本的文件系统备份可能很庞大，繁忙的系统将生成许多必须归档的 WAL 流量。尽管如此，在多数情况下，它仍然是需要高可靠性的首选备份技术。

我们需要一系列连续归档 WAL 日志文件，这些文件至少可以延伸到备份的开始时间，从而确保连续归档 (许多数据库供应商也称为“在线备份”) 成功恢复。

二进制文件是以二进制格式存储的文件，它是计算机可读的，人类不直接阅读二进制文件。所有的可执行程序都以二进制文件存储。那我们该如何编辑二进制文件呢？在我使用的 Emacs 编辑器中提供了一个 hexl-mode 的主模式来编辑二进制文件。本文记录了 Emacs 中编辑二进制文件的基本操作。

Cstore_fdw 是 Citus Data 开发的一款开放源码的 PostgreSQL 列存扩展插件。列存储在数据批量导入的分析场景能够提供更好的性能。Cstore_fdw 通过只读取磁盘上相关的列数据来提升性能，同时，由于每列的数据来自同一个域，因此更利于数据压缩，cstore_fdw 提供 6~10 倍的数据压缩能力，从而减小了对磁盘存储的需求。

Cstore_fdw 采用 Optimized Row Columnar (ORC) 格式作为其数据的物理存储格式。ORC 优化了 Facebook 的 RCFile 存储格式，并具有以下优点：

• 压缩 (Compression) - 大约减少了 2~4 倍的内存和磁盘存储空间。易于扩展以支持不同的编码。
• 列投影 (Column Projections) - 仅仅读取与该查询有关的数据列，提高了 I/O 效率。
• 跳跃索引 (Skip Indexes) - 为每个行组 (Row Groups) 存储其最大值和最小值，并利用他们来跳过不相关的数据行。

除此之外，cstore_fdw 使用了 PostgreSQL 的数据类型和 fdw API 编程接口，这样做的好处有以下几点：

• 支持 40+ 的 PostgreSQL 数据类型，用户也可以创建并使用新的类型。
• 统计信息收集，PostgreSQL 使用这些统计信息来评估不同的查询计划并选择最优查询计划的来执行。
• 配置简单，用户只需要创建外部表并导入数据，之后就可以使用 SQL 进行查询。

域名系统 (Domain Name System, DNS) 是为连接到互联网或专用网络的计算机、服务或其他资源提供的一个分散且分级的命名系统。他可以理解为域名和 IP 地址相互映射的一个分布式数据库，通过域名系统，用户可以使用相对容易记忆的域名来访问互联网，而不用去记忆难以理解的 IP 字符串，由域名到 IP 地址转换的过程则被叫做域名解析。下图给出了一个典型的域名分级系统 (图片来源于维基百科)。

今天在 CentOS 上遇到一个奇怪的问题，ping 程序在 root 用户下能正常使用，但是在非 root 用户下则出现如下错误：

1
2

user@host:~ $ ping 127.0.0.1
ping: socket: Permission denied

在 StackExchage 上也有人遇到了类似的问题，他需要在 PHP 中调用 ping 命令，并且他通过执行 setenforce 0 可以让 ping 命令正常使用，但是经我测试发现这种方法对我无效。

之后在 LinuxQuestions 上发现有人指出 ping 命名将创建原始套接字而非 TCP 套接字，然而 Linux 系统对于普通用户创建原开套接字是禁止的，因此我们就看到了文章开始的错误，针对这一问题他也提出了解决方案，即为 ping 命令添加 suid 权限。

1
2
3

user@host:~ $ chmod +s /bin/ping
user@host:~ $ ls -al /bin/ping
-rwsr-xr-x 1 root root 64424 Mar 10  2017 /bin/ping