Loading

MongoDB日志解析及使用Monstache同步过程中注意事项

MongoDB 中有几种日志?

MongoDB 中有 4 种日志，分别是系统日志、Journal 日志、oplog 主从日志、慢查询日志等。这些日志记录着 MongoDB 数据库不同方面的踪迹。

系统日志

系统日志在 MongoDB 数据库中很重要，它记录着 MongoDB 启动和停止的操作，以及服务器在运行过程中发生的任何异常信息。

配置系统日志的方法比较简单，在启动 mongod 时指定 logpath 参数即可

```shell
mongod -logpath=/data/log/mongodb/serverlog.log -logappend
```

系统日志会向 logpath 指定的文件持续追加。

日志等。这些日志记录着 MongoDB 数据库不同方面的踪迹。

Journal 日志

journaling(日记) 日志功能则是 MongoDB 里面非常重要的一个功能 ， 它保证了数据库服务器在意外断电 、 自然灾害等情况下数据的完整性。它通过预写式的 redo 日志为 MongoDB 增加了额外的可靠性保障。开启该功能时, MongoDB 会在进行写入时建立一条 Journal 日志, 其中包含了此次写入操作具体更改的磁盘地址和字节。因此一旦服务器突然停机，可在启动时对日记进行重放，从而重新执行那些停机前没能够刷新到磁盘的写入操作。

MongoDB 配置 WiredTiger 引擎使用内存缓冲区来保存 journal 记录, WiredTiger 根据以下间隔或条件将缓冲的日志记录同步到磁盘

日志等。这些日志记录着 MongoDB 数据库不同方面的踪迹。

固定集合 (Capped Collection)

MongoDB 中的普通集合是动态创建的，而且可以自动增长以容纳更多的数据。MongoDB 中还有另一种不同类型的集合，叫做固定集合。固定集合需要事先创建好，而且它的大小是固定的。固定集合的行为类型与循环队列一样。如果没有空间了，最老的文档会被删除以释放空间，新插入的文档会占据这块空间。

oplog 主从日志

Replica Sets 复制集用于在多台服务器之间备份数据。MongoDB 的复制功能是使用操作日志 oplog 实现的，操作日志包含了主节点的每一次写操作。oplog 是主节点的 local 数据库中的一个固定集合。备份节点通过查询这个集合就可以知道需要进行复制的操作。
一个 mongod 实例中的所有数据库都使用同一个 oplog，也就是所有数据库的操作日志 (插入，删除，修改) 都会记录到 oplog 中

MongoDB oplog 详解

oplog 简介

oplog 是 local 库下的一个固定集合，Secondary 就是通过查看 Primary 的 oplog 这个集合来进行复制的。每个节点都有 oplog，记录这从主节点复制过来的信息，这样每个成员都可以作为同步源给其他节点。
Oplog 可以说是 Mongodb Replication 的纽带了。

副本集数据同步的过程

副本集中数据同步的详细过程：Primary 节点写入数据，Secondary 通过读取 Primary 的 oplog 得到复制信息，开始复制数据并且将复制信息写入到自己的 oplog。如果某个操作失败（只有当同步源的数据损坏或者数据与主节点不一致时才可能发生），则备份节点停止从当前数据源复制数据。如果某个备份节点由于某些原因挂掉了，当重新启动后，就会自动从 oplog 的最后一个操作开始同步，同步完成后，将信息写入自己的 oplog，由于复制操作是先复制数据，复制完成后再写入 oplog，有可能相同的操作会同步两份，不过 MongoDB 在设计之初就考虑到这个问题，将 oplog 的同一个操作执行多次，与执行一次的效果是一样的。

  • 作用：
    　　当 Primary 进行写操作的时候，会将这些写操作记录写入 Primary 的 Oplog 中，而后 Secondary 会将 Oplog 复制到本机并应用这些操作，从而实现 Replication 的功能。
    　　同时由于其记录了 Primary 上的写操作，故还能将其用作数据恢复。
    　　可以简单的将其视作 Mysql 中的 binlog。

oplog 的增长速度

oplog 是固定大小，他只能保存特定数量的操作日志，通常 oplog 使用空间的增长速度跟系统处理写请求的速度相当，如果主节点上每分钟处理 1KB 的写入数据，那么 oplog 每分钟大约也写入 1KB 数据。如果单次操作影响到了多个文档（比如删除了多个文档或者更新了多个文档）则 oplog 可能就会有多条操作日志。db.testcoll.remove() 删除了 1000000 个文档，那么 oplog 中就会有 1000000 条操作日志。如果存在大批量的操作，oplog 有可能很快就会被写满了。

  • 大小：
    　　Oplog 是一个 capped collection。
    　　在 64 位的 Linux, Solaris, FreeBSD, and Windows 系统中，Mongodb 默认将其大小设置为可用 disk 空间的 5%（默认最小为 1G，最大为 50G），或也可以在 mongodb 复制集实例初始化之前将 mongo.conf 中 oplogSize 设置为我们需要的值。
    　　local.oplog.rs 一个 capped collection 集合. 可在命令行下使用 --oplogSize 选项设置该集合大小尺寸.
    　　但是由于 Oplog 其保证了复制的正常进行，以及数据的安全性和容灾能力。

oplog 注意事项：

local.oplog.rs 特殊的集合。用来记录 Primary 节点的操作。
为了提高复制的效率，复制集中的所有节点之间会相互的心跳检测（ping）。每个节点都可以从其他节点上获取 oplog。
oplog 中的一条操作。不管执行多少次效果是一样的

oplog 的大小

第一次启动复制集中的节点时，MongoDB 会建立 Oplog, 会有一个默认的大小，这个大小取决于机器的操作系统

  • rs.printReplicationInfo() 查看 oplog 的状态，输出信息包括 oplog 日志大小，操作日志记录的起始时间。
  • db.getReplicationInfo() 可以用来查看 oplog 的状态、大小、存储的时间范围。

oplog 数据结构

通过下面的命令取出一条 oplog：
shell db.oplog.rs.find().skip(1).limit(1).toArray() 

rs0:PRIMARY> db.oplog.rs.find().skip(1).limit(1).toArray()
[
	{
		"ts" : Timestamp(1586243552, 3),
		"t" : NumberLong(1),
		"h" : NumberLong(0),
		"v" : 2,
		"op" : "c",
		"ns" : "config.$cmd",
		"ui" : UUID("4781aa3b-e371-4a96-a6f5-f59fac22ce06"),
		"wall" : ISODate("2020-04-07T07:12:32.943Z"),
		"o" : {
			"create" : "transactions",
			"idIndex" : {
				"v" : 2,
				"key" : {
					"_id" : 1
				},
				"name" : "_id_",
				"ns" : "config.transactions"
			}
		}
	}
]
  • ts: 8 字节的时间戳，由 4 字节 unix timestamp + 4 字节自增计数表示。这个值很重要，在选举 (如 master 宕机时) 新 primary 时，会选择 ts 最大的那个 secondary 作为新 primary
  • op：1 字节的操作类型
    "i"： insert
    "u"： update
    "d"： delete
    "c"： db cmd
    "db"：声明当前数据库 (其中 ns 被设置成为 => 数据库名称 + '.')
    "n": no op, 即空操作，其会定期执行以确保时效性
  • ns：操作所在的 namespace
  • o：操作所对应的 document，即当前操作的内容（比如更新操作时要更新的的字段 和值）
  • o2: 在执行更新操作时的 where 条件，仅限于 update 时才有该属性
  • 查看 oplog 的信息,通过 "db.printReplicationInfo()" 命令可以查看 oplog 的信息
  • 字段说明：
    configured oplog size： oplog 文件大小
    log length start to end: oplog 日志的启用时间段
    oplog first event time: 第一个事务日志的产生时间
    oplog last event time: 最后一个事务日志的产生时间
    now: 现在的时间
MongoDB server version: 4.2.5
rs0:PRIMARY> db.getReplicationInfo()
{
	"logSizeMB" : 2270.184814453125,
	"usedMB" : 474.85,
	"timeDiff" : 4147617,
	"timeDiffHours" : 1152.12,
	"tFirst" : "Tue Apr 07 2020 15:12:32 GMT+0800 (CST)",
	"tLast" : "Mon May 25 2020 15:19:29 GMT+0800 (CST)",
	"now" : "Mon May 25 2020 15:42:03 GMT+0800 (CST)"
}


rs0:PRIMARY> db.printReplicationInfo()
configured oplog size:   2270.184814453125MB
log length start to end: 4147757secs (1152.15hrs)
oplog first event time:  Tue Apr 07 2020 15:12:32 GMT+0800 (CST)
oplog last event time:   Mon May 25 2020 15:21:49 GMT+0800 (CST)
now:                     Mon May 25 2020 15:44:27 GMT+0800 (CST)

Monstache同步MongoDB到ElasticSearch注意事项

注意，mongodb通过monstache同步到elasticsearch小心查看日志文件（必须输出日志），如果有错误即使不影响同步结果，也要解决，可能或导致mongo产生错误日志，导致日志暴增，致使服务挂掉

mongodb注意

  • 如果mongo开启了安全认证，需要给monstache同步用的用户一个root权限,以使这个用户可以访问admin和local数据库（这里用的比较暴力的办法，我测试通过给只需要同步的数据库用户添加admin、local数据库读写权限，还是继续报错，只能采取了下下策）

monstache配置注意

  • monstache同步配置中要配置enable-oplog：true（默认为change-steam，默认方式理论上）
  • 下面是local数据库表
    rs0:PRIMARY> use local
switched to db local
rs0:PRIMARY> show tables
oplog.rs          # monstache要访问这个表，需要monstache配置为enable-oplog：ture
replset.election
replset.minvalid
replset.oplogTruncateAfterPoint
startup_log

MongoDB日志暴增另一种解决方式（治标不治本）

  • 登入数据库
db.adminCommand( { logRotate : 1 } )
  • 使用系统默认的日志轮转机制存储和轮转日志输出
kill -SIGUSR1 <mongod process id>

参考
官方文档

posted @ 2021-01-06 13:20  Bob-Dylan  阅读(1290)  评论(0)  编辑  收藏  举报