最近我们有一个 SQL 需要导入到 PostgreSQL ，但数据格式使用的是用： -- -- TOC entry 7877 (class 0 OID 21961) -- Dependencies: 904 -- Data for Name: upload_references; Type: TABLE DATA; Schema: public; Owner: - -- COPY public.upload_references (id, upload_id, target_type, target_id, created_at, updated_at) FROM stdin; 45698 760 Post 667 2023-05-05 04:11:35.947138 2023-05-05 04:11:35.947156 42396 6674 Post 3903 2023-05-05 01:59:37.447183 2023-05-05 01:59:37.447202 45699 761 Post 667 2023-05-05 04:11:35.947163 2023-05-05 04:11:35.947167 \. 这样的格式。     这样的格式只能使用 psql 来进行导入。 注意到上面有一个 COPY FROM stdin; 这个是 psql 的专用导入格式。 导入的命令为： psql -h 127.0.0.1 -p 5433 -U username -W -d database name < dump.sql 我们在导入的命令中加入了不少的参数。 有关 psql 的参数列表，请参考文章：PostgreSQL: Documentation: 15: psql. 上面的参数中： -h 服务器地址 -p 数据库服务器运行端口 -U 登录用户名 -W 登录密码 -d 数据库名 当导入开始后，在控制台上，会出现导入结果。 数据提示 在导入的数据库，中我们发现 PostgreSQL 使用的 COPY Stdin。 在数据的默认有一个数据终止符 \.。     这个数据终止符是不能丢的。   https://www.isharkfly.com/t/postgresql-psql-sql/14720

Discourse 提供了较为完善的日志查看方式。 用得最多的可能就是 Logster 的基于 Web 的 UI 了。 Logster Discourse 的错误日志面板用的是 logster，采集的是 Rails/Rack 的日志，正常应该用 Rails::Logger 但是 discourse 做了封装。 正常的访问地址为你的域名后面添加 logs。 例如，可以访问域名后面添加 logs 的地址。     但需要注意的是，你需要登录系统，具有系统管理员的访问权限才可以。 否则将会出现页面没有找到的错。 系统日志 和所有系统一样，Discourse 使用了 nginx 为 Web 服务器。 这个日志不会显示在 logster 上面的。 你需要进入你的服务器后才能看到。 Discourse 做了系统的优化，把系统使用的日志卷给映射出来了，你并不需要进入容器才能看到日志。 举个例子，我们希望看见 nginx 的 access 访问日志。 那么在你的服务器上可以直接访问： /var/discourse/shared/standalone/log/var-log/nginx 这个地址就可以了。     所有容器中的日志，也可以通过上面的路径查看到，你并不需要进入 Discourse 的容器内。 https://www.isharkfly.com/t/discourse/14715

在需要了解 Discourse 如何访问数据库之前我们需要了解的是 Discourse 的所有软件都使用的是 Docker 容器。 因此我们必须要进入到 Docker 容器后才能访问 Discourse 内部的东西。 进入 Discourse 容器 进入 Discourse 容器的命令是 cd /var/discourse/ ./launcher enter app 进入 PostgreSQL 进入容器后再运行 sudo -u postgres psql discourse 命令就可以进入 psql 的控制台了。 在这个控制界面中，你可以输入 SQL 语句进行查询了。 例如我们可以运行 select count(*) from topics; 这个 SQL 来查看当前你的运行实例中有多少个主题。   在 Discourse 容器内部运行查询的命令和如何进入后执行 SQL。   https://www.isharkfly.com/t/discourse/14716

根据官方的这个主题：Configure an S3 compatible object storage provider for uploads - sysadmin - Discourse Meta Discourse 可以支持很多不同的对象存储。     感觉上是只要和 S3 兼容的基本上都能用。 建议 从对象存储的角度考虑，还是建议使用 S3。 因为这个 S3 的对象存储可以 CloudFont 进行集成，不仅仅是提供对象存储，同时还可以提供 CDN 服务。 对于其他的对象存储，没有怎么用过，所以不是非常熟悉。 我们，使用的 S3 对象存储，对我们来说可以获得非常大的存储空间，同时不依赖程序的重新部署，想象下你的 Discourse 可能有超过 10 万的主题，平均下来，每个主题可能有 1 个图片或者附件。 这样你的附件也轻轻松松超过 10 万。 对于这个数据量，我们认为还是属于比较基本的数据量。 对比 Discourse 的官方，昨天我们才发的帖子，估计目前的数据量应该超过了 27 万。 因为 Discourse 的设计，主题的 ID 使用数据库的 Sequence 来进行自增的。     对于一个网站的数据量，Discourse 还是比较好估计的。   https://www.isharkfly.com/t/discourse/14717

支持主题的数量和 ID 使用的数据类型有关。 根据我们从 Discourse 上 dump 出来的 SQL，我们看到 Discourse 的官方使用 Integer 作为 ID 的数据类型。     随后，我们查看了 pgsql 的官方文档，integer 是 4 字节的，能够存储的最大值为：2147483647。     对 Discourse 来说，这个值应该是够用了。 对数据量来说，应该还是不太可能有机会出现溢出的情况。 https://www.isharkfly.com/t/discourse/14718

近期，我们在对 Discourse 进行恢复的时候，我们发现新的备份可能会导致不是所有的数据都能恢复到服务上。 这时候我们应该考虑让 Discourse 保留多少备份的问题？ 在默认情况下，我们设置 Discourse 的备份是保留 5 个。这是官方的默认值。     现在我们觉得这个值应该是太低了，如果系统运行故障，你希望找到以前老的备份，可能找不到。 建议值 我们建议这个至少应该保留 90 天到半年以上。 通常我们不会追太久的数据，但是丢数据了也非常麻烦，尤其是不少网站访问频率比较高的情况下。 所以这个值我会设置到 600， 让服务器上保留 600个备份，因为我们每天备份 1 次，所以这里能够差不多保留 2 年的数据。 Discourse 最多只能每天备份，Discourse 没有办法做到上午和下午同时备份。   https://www.isharkfly.com/t/discourse/14714/1

Discourse 对上传的附件会进行清理，对于一些没有任何被引用的附件，Discourse 会认为是垃圾而清理掉。 原因应该是为了降低存储空间的使用，但是我们目前使用的是 S3 ，所以对存储空间并没有太多的要求。 根据官方的说法，如果满足下面的条件的上传附件将会被清理掉： https://github.com/discourse/discourse/blob/master/app/jobs/scheduled/clean_up_uploads.rb TL;DR: an image is orphaned if and only if it’s not referenced in the latest version of a post in a draft in a queued post in a logo site setting in a custom emoji in a theme in a user avatar/background/card image in a category logo/background image 官方的讨论地址为：How to make an image orphaned so that it gets removed? - support - Discourse Meta 通过代码，我们会看到，Discourse 使用了一个查询来判断附件是否被引用。 这个表是：upload_references 如果附件没有被关联到主题中，这个附件就会被认为是没有关联的附件而被清理掉。     根据我们备份恢复的情况来看，我们估计可能是这个表 upload_references 丢数据了，导致 uploads 中标的数据被清理掉了。 本地查询 我们本地查询了下操作前 3 天的记录。 发现这个表中有：9000 多条记录。     服务器查询 同时，我们对服务器上的表进行了查询。 查询结果返回的是：6000 多。 很明显这里有差距，那肯定是在恢复的过程中可能丢数据了。 我们需要做的就是把本地表中的数据恢复到服务器上。   运行 SQL： select count(*) from upload_references; 来查看下服务器上的记录，貌似服务器上的参考引用全部被恢复了。 因为我们禁用了自动清理程序，所以我们现在应该可以把自动清理进程打开了。   https://www.isharkfly.com/t/discourse/14713

今天登录表以后，发现数据又被清理了部分。 然后我们又重新使用 SQL 导入了数据。 这个让我们感觉 Discourse 的系统中应该设置了自动清理程序，在这个自动清理程序中会对认为没有使用的附件或者图片进行清理。 因为我们更换了存储空间，所以这会导致自动清理程序可能会出现误判，因为路径或者存储空间有了变化，导致 Discourse 认为存储不对。 所以，我们认为当你更换存储桶或者空间以后，最好不要启用这个清理进程。 在附件下面，我们选择了取消了删除未被引用的上传附件。     希望这个设置能够保持老的附件不被清理。 等过一段时间以后，我们再来查看下附件数量以便于确定这个功能。   https://www.isharkfly.com/t/discourse/14712

Ruby 和 PgSQL 并不是我非常熟悉的领域。 多年没有花这么多的时间解决一个问题了，从数据的 Dump 到数据导入，到容器的 SQL 执行。 当你想放弃的时候，发现你有的是一种热爱，喜欢体验到问题被解决的感觉，人还是有需要有理想的。 尤其是在你感觉到沮丧和低谷的时候，你一定要相信自己。 Buster Moon 说过 : When you’ve reached rock bottom, there’s only one way to go, and that’s up! 不要放弃，一切问题都是有原因的，也会有解决办法的。 开始阶段 最开始的时候我们只是遇到图片没有显示的问题，一直不知道是什么原因。 后来发现是在 Discourse 的 HTML 没有被正确的重新构建。 后来，我们发现可能是算法，因为 Discourse 的 URL 短算法有可能会导致没有办法进行完全的解码。 问题 当我们继续寻找问题的时候，我们发现没有办法直接查询数据库获得 String 的映射信息。 这时候怎么办呢？我们只对数据库进行查看，这是第一次我们 dump 数据库。 Discourse 使用的是 PgSQL 数据库，这个比 MySQL 要更加复杂，所以我们在本地的计算机中装了一个 PGSQL 数据库实例。 然后把服务器上的备份文件下载到本地后导入到数据库。 我们最后发现 uploads 的表数据量不一样。 最后我们才定位到是因为表丢数据了，虽然不知道具体的原因，但是只要恢复具体的数据问题就能解决了。     因为 Discourse 使用了容器，如何执行 SQL 导入数据又是问题。 我们需要进入 Docker 容器后，然后登录数据库再运行 SQL 才能导入数据。 同时因为文件格式的不一样，甚至没有办法直接运行 SQL 脚本。 经过最后一堆折腾后才解决这个问题，很高兴最后问题解决了。 很长时间没有为了解决一个问题花费这么多时间了，很多人说搞 IT 为什么，调 Bug 为什么。 有时候只是单纯的因为喜欢。   https://www.isharkfly.com/t/topic/14709

我们来说说和数据有关的单位 bit 和 Byte。 在说这这个数据当我之前，大家应该都知道计算机实际上只能处理0和1。 计算机能够把0和1转换为电路中的信号来进行计算，这个其实就是计算机的本质。 单位定义 我们先对需要使用的单位进行一些定义。 bit（比特） bit 就是计算机对数据存储和移动的最小单元，这个只有2个值，0和1。它的简写为小写字母“b”。 作为信息技术的最基本存储单元，因为比特实在太小了，所以大家生活中可能接触不到，在装宽带的时候被忽悠的就是这个单位。 Byte（字节） Byte 是字节的英文写法。它的简写为大写字母“B”。 既然名字叫字节，那肯定跟字符有关系。英文字符通常是一个字节，也就是1B。中文字符因为字符集的问题通常会超过 2 个字节。 这是和中文字符有关的，因为中文字符编码的问题，我们是没有办法把所中文存储在一个字节中的。 所以对亚洲国家用的字符，比如我们以后可能会说到的 CJK，会占到 4 个字节。 转换关系 8 bit 等于 1 byte。 一个字节等于八位。 表达用途 因为 bit 这个单位实在是太小了，用在存储上并不是很好用。 所以我们大致上只需要了解： bit 用在数据通信上，存储上用的是 Byte。 简单来说，和通信有关的都是位，和存储有关的都是字节。 这是因为在数据传输中，交换机和硬件只负责把 0 或者 1 发送到目的地，所以使用位这个单位更好来表示数据传输。 为什么要了解 Bit 和 Byte 现在来说下为什么需要对 Bit 和 Byte 有些基本的了解。 其实我们主要是用来理解下计算机是如何对数据进行计算的。 比如说，在 Java 程序中，我们都会知道有一个数据类型，其实所有的计算机语言都会有数据类型的。 我们拿最常用的 Int 来举例，如果你不知道 Java 的 Int 是多少位的话，你可以随意搜索下应该得到的答案是 Java Int 是 32 位的。 当我们在程序中对 Int 进行计算的时候，就涉及到你需要进行计算的 2 个数字，如何通过位的移动来获得结果，因为我们知道计算机只能处理 Bit 数据。 举例来说，假设我们希望让计算机告诉我们 12 +12 等于多少，首先我们就需要知道 12 在计算机内是怎么存储的，对于数字 12 的整数类型，程序会用一什么 0 和 1 的序列进行存储。 在做加法的时候，程序会通过怎么样的位移动来得到具体的值。 这个过程实际上就是计算机 CPU 处理的过程。 因为我们在程序计算的时候，这部分对大部分程序开发都是透明的，所以我们实际上只需要了解 Bit 和 Byte 直接的一些关系就好了。 因为了解这些关系，能够有助于我们在以后看到一些文献资料的时候了解存储和计算过程，但因实际用得并不多，大部分情况也不会要求你主动去进行位移动计算，因为这是计算机做的事情。 https://www.isharkfly.com/t/bit-byte/14696