0はじめに
図2は、分析及びクリーニングxlogの生成ロジックの一部であり、処理は直接xlogのパート3を参照サージ。
1 WALアーカイブ
# 在自动的WAL检查点之间的日志文件段的最大数量
checkpoint_segments =
# 在自动WAL检查点之间的最长时间
checkpoint_timeout =
# 缓解io压力
checkpoint_completion_target =
# 日志文件段的保存最小数量，为了备库保留更多段
wal_keep_segments =
# 已完成的WAL段通过archive_command发送到归档存储
archive_mode =
# 强制timeout切换到新的wal段文件
archive_timeout =
max_wal_size =
min_wal_size =
1.1はオープンアーカイブではありません
通常より多くない、いくつかの制御パラメータに従って、ファイルの数
(2 + checkpoint_completion_target) * checkpoint_segments + 1
若しくは
checkpoint_segments + wal_keep_segments + 1ファイル。
ファイルが不要になった場合は、古いセクションでは、名前を変更しないと、短期のログ出力のピークはより多くの結果ならば、使用をカバーしていきます
3 * checkpoint_segments + 1ファイル、削除ファイル。
1.2オープンアーカイブ
ファイルの数：削除アーカイブされたセグメントファイルに成功
実行のPG抽象ビューが無限に長いWALシーケンスログを生成します。各セクション16M、ファイルのこれらのセグメントの名前は、配列中のWAL位置に反映され、値が命名されます。無WALアーカイブでは、通常、システムわずか数セグメントファイルと、その後はリサイクル方法は、もはや高いセグメント番号の名前を変更するために使用されていないセグメントファイルにある作成します。
もしおよびアーカイブコマンドが成功した場合にのみ、archiveコマンドのリターンはゼロ。ゼロの結果を得た後、PostgreSQLはWALセグメントファイルが正常にアーカイブされたセグメントファイルが後で削除されますされていると仮定します。非ゼロ値は、ファイルが、それが成功するまで再試行し、定期的に、アーカイブされていないというのPostgreSQLに指示します。
2 PG-ソース分析
2.1削除ロジック
削除トリガー・アクション
RemoveOldXlogFiles
> CreateCheckPoint
> CreateRestartPoint
wal_keep_segments判断（_logSegNoを変更するには、この関数を呼び出し、その後、RemoveOldXlogFilesを渡します）
static void
KeepLogSeg(XLogRecPtr recptr, XLogSegNo *logSegNo)
{
XLogSegNo segno;
XLogRecPtr keep;
XLByteToSeg(recptr, segno);
keep = XLogGetReplicationSlotMinimumLSN();
/* compute limit for wal_keep_segments first */
if (wal_keep_segments > 0)
{
/* avoid underflow, don't go below 1 */
if (segno <= wal_keep_segments)
segno = 1;
else
segno = segno - wal_keep_segments;
}
/* then check whether slots limit removal further */
if (max_replication_slots > 0 && keep != InvalidXLogRecPtr)
{
XLogSegNo slotSegNo;
XLByteToSeg(keep, slotSegNo);
if (slotSegNo <= 0)
segno = 1;
else if (slotSegNo < segno)
segno = slotSegNo;
}
/* don't delete WAL segments newer than the calculated segment */
if (segno < *logSegNo)
*logSegNo = segno;
}
削除ロジック
static void
RemoveOldXlogFiles(XLogSegNo segno, XLogRecPtr endptr)
{
...
...
while ((xlde = ReadDir(xldir, XLOGDIR)) != NULL)
{
/* Ignore files that are not XLOG segments */
if (strlen(xlde->d_name) != 24 ||
strspn(xlde->d_name, "0123456789ABCDEF") != 24)
continue;
/*
* We ignore the timeline part of the XLOG segment identifiers in
* deciding whether a segment is still needed. This ensures that we
* won't prematurely remove a segment from a parent timeline. We could
* probably be a little more proactive about removing segments of
* non-parent timelines, but that would be a whole lot more
* complicated.
*
* We use the alphanumeric sorting property of the filenames to decide
* which ones are earlier than the lastoff segment.
*/
if (strcmp(xlde->d_name + 8, lastoff + 8) <= 0)
{
if (XLogArchiveCheckDone(xlde->d_name))
# 归档关闭返回真
# 存在done文件返回真
# 存在.ready返回假
# recheck存在done文件返回真
# 重建.ready文件返回假
{
/* Update the last removed location in shared memory first */
UpdateLastRemovedPtr(xlde->d_name);
# 回收 或者 直接删除，清理.done和.ready文件
RemoveXlogFile(xlde->d_name, endptr);
}
}
}
...
...
}
2.2アーカイブロジック
static void
pgarch_ArchiverCopyLoop(void)
{
char xlog[MAX_XFN_CHARS + 1];
# 拿到最老那个没有被归档的xlog文件名
while (pgarch_readyXlog(xlog))
{
int failures = 0;
for (;;)
{
/*
* Do not initiate any more archive commands after receiving
* SIGTERM, nor after the postmaster has died unexpectedly. The
* first condition is to try to keep from having init SIGKILL the
* command, and the second is to avoid conflicts with another
* archiver spawned by a newer postmaster.
*/
if (got_SIGTERM || !PostmasterIsAlive())
return;
/*
* Check for config update. This is so that we'll adopt a new
* setting for archive_command as soon as possible, even if there
* is a backlog of files to be archived.
*/
if (got_SIGHUP)
{
got_SIGHUP = false;
ProcessConfigFile(PGC_SIGHUP);
}
# archive_command没设的话不再执行
# 我们的command没有设置，走的是这个分支
if (!XLogArchiveCommandSet())
{
/*
* Change WARNING to DEBUG1, since we will left archive_command empty to
* let external tools to manage archive
*/
ereport(DEBUG1,
(errmsg("archive_mode enabled, yet archive_command is not set")));
return;
}
# 执行归档命令！
if (pgarch_archiveXlog(xlog))
{
# 成功了，把.ready改名为.done
pgarch_archiveDone(xlog);
/*
* Tell the collector about the WAL file that we successfully
* archived
*/
pgstat_send_archiver(xlog, false);
break; /* out of inner retry loop */
}
else
{
/*
* Tell the collector about the WAL file that we failed to
* archive
*/
pgstat_send_archiver(xlog, true);
if (++failures >= NUM_ARCHIVE_RETRIES)
{
ereport(WARNING,
(errmsg("archiving transaction log file \"%s\" failed too many times, will try again later",
xlog)));
return; /* give up archiving for now */
}
pg_usleep(1000000L); /* wait a bit before retrying */
}
}
}
}
2.3準備生成ロジック
static void
XLogWrite(XLogwrtRqst WriteRqst, bool flexible)
{
...
if (finishing_seg)
{
issue_xlog_fsync(openLogFile, openLogSegNo);
/* signal that we need to wakeup walsenders later */
WalSndWakeupRequest();
LogwrtResult.Flush = LogwrtResult.Write; /* end of page */
# 归档打开 && wal_level >= archive
if (XLogArchivingActive())
# 生成ready文件
XLogArchiveNotifySeg(openLogSegNo);
XLogCtl->lastSegSwitchTime = (pg_time_t) time(NULL);
...
}
2.4概要
- archive_mode限り準備ができたファイルは=とwal_lever> =アーカイブに、常に（XLogWrite関数呼び出しの世代）が生成されます。
- archive_commandが空に設定しているので、その消費者は、外部の制御プログラムから完全に準備ができたファイルです
- PGによって行われて行わ文書処理は、二つの場所が行わ文書処理、およびチェックポイントリスタートポイントがトリガされます
- wal_keep_segmentsとreplication_slot制御によって行わどのように多くの文書処理（KeepLogSeg機能）
蓄積された理由3 WALセグメント（全長要件？）
-
注：いずれの場合ではありません手動で削除ファイルに注意するxlogの
-
注：すぐに準備ができたファイルを生成しませんバック生成されたログのチェックポイントは、xlogの後に次の世代であります
3.1 ReplicationSlot
コピー流路を開き、
-- 流复制插槽
-- 如果restart_lsn和当前XLOG相差非常大的字节数, 需要排查slot的订阅者是否能正常接收XLOG,
-- 或者订阅者是否正常. 长时间不将slot的数据取走, pg_xlog目录可能会撑爆
select pg_xlog_location_diff(pg_current_xlog_location(),restart_lsn), *
from pg_replication_slots;
[削除]
select pg_drop_replication_slot('xxx');
PGは、次のチェックポイントのクリーンアップxlogの後に削除されます
3.2大きなwal_keep_segments
設定パラメータを確認し、このパラメータに注意を払うが、一定の遅延を開き、準備ができxlogのだろう
3.3リサイクル問題
あなたはPG自動回復メカニズムを使用しない場合、データベースは.readyファイルを変更するために、外部のプログラムに依存して回復プロセスを検出する必要があります
（にarchive_mode =にarchive_commandに= ''）
3.4チェックポイントの間隔が長すぎます
設定パラメータをチェック
