Understanding Vertica Epochs

名词解释：
Epoch：An epoch is 64-bit number that represents a logical time stamp for the data in Vertica。也就是一个64位的逻辑时间戳。

Epoch概述

Epoch是一个64bit的数字，用以表示vertica数据库中数据的逻辑时间戳。每行数据都有一个隐式存储的列，用于记录提交的epoch。

=> CREATE TABLE testdata (a INT, b INT);
=> INSERT INTO testdata VALUES (1,2);
=> INSERT INTO testdata VALUES (3,4);
=> COMMIT;
=> INSERT INTO testdata VALUES (5,6);
COMMIT;
--查询
=> SELECT a,b,epoch FROM testdata;a | b | epoch
---+---+-------1 | 2 |  18983 | 4 |  18985 | 6 |  1899
(3 rows)

当系统的逻辑状态更改或使用DML操作（INSERT，UPDATE，MERGE，COPY或DELETE）提交数据时，epoch会更新。EPOCHS系统表包含每个closed epoch的日期和时间，以及其对应的epoch number。此信息使您可以确定哪些时间段与哪个时期有关：

=> SELECT * FROM epochs;epoch_close_time         | epoch_number
-------------------------------+--------------2015-11-09 17:47:21.013641+00 |         13502015-11-09 18:03:30.454707+00 |         13512015-11-09 18:04:48.329494+00 |         13712015-11-09 18:18:42.796702+00 |         13722015-11-09 18:19:52.738018+00 |         13922015-11-09 18:26:43.655577+00 |         13932015-11-11 15:21:47.918074+00 |         13942015-11-11 15:23:16.80952+00  |         18972015-11-20 18:13:20.324436+00 |         18982015-11-20 18:13:20.372756+00 |         1899
(10 rows)

Epochs的类型

epoch图是一个介于AHM及LE之间的epoch列表，epoch图存储在数据库catalog中。如下图所示：

current epoch(CE)

当执行commit操作后，当前current epoch将会成为一个last epoch。The current_epoch at the time of the COMMIT is the epoch for that DML。

=> SELECT CURRENT_EPOCH FROM SYSTEM;
CURRENT_EPOCH
---------------
629415 (1 row)=> INSERT INTO test VALUES (10,20); COMMIT;
OUTPUT
--------
1
(1 row)COMMIT
=> SELECT current_epoch FROM SYSTEM;current_epoch
---------------629416
(1 row)

每次commit后，current_epoch都会增加。

Latest Epoch (LE)

The latest epoch is the most recently closed epoch。当前epoch（CE）提交后，会成为最新的epoch（LE）。

Checkpoint Epoch (CPE)

每个投影的CPE时间是WOS中没有数据时的LE。这是可以恢复投影的点。在将数据从WOS移到ROS时，Tuple Mover 移出操作使投影CPE更新。可以在PROJECTION_CHECKPOINT_EPOCHS系统表中看到投影的CPE。

=> SELECT node_name, projection_schema schema, projection_name p_name, is_up_to_date UTD, checkpoint_epoch CPE, would_recover WR, is_behind_ahm BAHM from projection_checkpoint_epochs;node_name        |  schema | p_name                   |   UTD |    CPE    | WR    | BAHM
------------------------+---------+--------------------------+-------+-----------+-------+-----v_test_israel_node0001 | public  |   product_dimension_b1   |   t   |    1347   |   f   |   fv_test_israel_node0003 | public  |   product_dimension_b1   |   t   |    1347   |   f   |   fv_test_israel_node0002 | public  |   product_dimension_b1   |   t   |    1347   |   f   |   fv_test_israel_node0002 | store   |   store_dimension_b1     |   t   |    1347   |   f   |   fv_test_israel_node0003 | store   |   store_dimension_b1     |   t   |    1347   |   f   |   fv_test_israel_node0001 | store   |   store_dimension_b1     |   t   |    1347   |   f   |   fv_test_israel_node0002 | public  |   promotion_dimension_b1 |   t   |    1347   |   f   |   fv_test_israel_node0001 | public  |   promotion_dimension_b1 |   t   |    1347   |   f   |   fv_test_israel_node0003 | public  |   promotion_dimension_b1 |   t   |    1347   |   f   |   fv_test_israel_node0001 | public  |   warehouse_dimension_b1 |   t   |    1347   |   f   |   fv_test_israel_node0002 | public  |   warehouse_dimension_b1 |   t   |    1347   |   f   |   fv_test_israel_node0003 | public  |   warehouse_dimension_b1 |   t   |    1347   |   f   |   f

Last Good Epoch (LGE)

所有节点上的最小CPE称为LGE。 LGE是指可以手动恢复的最近的epoch。 LGE由磁盘上所有数据的快照组成。如果集群异常关闭，LGE之后的数据将丢失。 Tuple Mover更新CPE并设置新的LGE。如果Tuple Mover失败，则数据不会从WOS移到ROS。因此，数据不会更新CPE和LGE。每个节点都有一个LGE，即节点上投影的最小检查点时间。 Vertica根据节点LGE计算集群LGE，以便集群LGE利用数据K-safety来呈现最高可用的LGE。要查看集群的LGE，请使用以下命令：

=> SELECT GET_LAST_GOOD_EPOCH();GET_LAST_GOOD_EPOCH
---------------------1347
(1 row)

可以通过检查恢复时期来验证每个节点LGE：

=> SELECT GET_EXPECTED_RECOVERY_EPOCH();
INFO 4544:  Recovery Epoch Computation:
Node Dependencies:
011 - cnt: 253
101 - cnt: 253
110 - cnt: 253
111 - cnt: 239
Nodes certainly in the cluster:Node 0(v_test_israel_node0001), epoch 1347Node 1(v_test_israel_node0002), epoch 1347
Filling more nodes to satisfy node dependencies:
Data dependencies fulfilled, remaining nodes LGEs don't matter:Node 2(v_test_israel_node0003), epoch 1347
--GET_EXPECTED_RECOVERY_EPOCH
-----------------------------1347
(1 row)

Ancient History Mark (AHM)

较大的epoch map可能会增加目录大小。Ancient History Mark是可以从物理存储中清除历史数据的一个标记。您不能在AHM之前运行任何历史查询。默认情况下，Vertica以3分钟的间隔使AHM前进，与LGE相等。当群集中的节点因未刷新的投影而关闭时，AHM不会前进。AHM永远不会大于LGE。要验证AHM，请使用以下命令：

=> SELECT GET_AHM_EPOCH();
GET_AHM_EPOCH
---------------1347
(1 row)

How Epochs Work

通过DML事务的COMMIT（INSERT，UPDATE，MERGE，COPY和DELETE），CE和LE都会前进。 CE移动1时，LE也会移动1，CE成为最LE。根据DML事务的类型，Vertica会执行以下操作：

如果数据是通过INSERT或COPY语句加载的，则每行都有一个代表该行提交时间的epoch。
如果使用DELETE语句删除了数据，则Vertica会创建存储epoch的删除向量。删除向量将位置存储在标记为删除的ROS容器中。

以下命令显示Vertica创建new epochs的过程：

=> CREATE TABLE test_epochs ( c1 int);
CREATE TABLE=> SELECT CURRENT_EPOCH, AHM_EPOCH, LAST_GOOD_EPOCH FROM SYSTEM;CURRENT_EPOCH | AHM_EPOCH | LAST_GOOD_EPOCH
---------------+-----------+-----------------1348 |      1347 |            1347
(1 row)-- Insert new data
=> INSERT INTO test_epochs VALUES (1);OUTPUT
--------1
(1 row)-- Because the INSERT was not committed, no epoch was recorded
=> SELECT epoch, * FROM test_epochs;epoch | c1
-------+----|  1
(1 row)=> COMMIT;
COMMIT-- The COMMIT transaction uses last current epoch and current epoch
-- becomes the latest epoch.=> SELECT epoch, * FROM test_epochs;epoch | c1
-------+----1348 |  1
(1 row)-- Current epoch advances because of the last COMMIT.
=> SELECT CURRENT_EPOCH, AHM_EPOCH, LAST_GOOD_EPOCH FROM SYSTEM;CURRENT_EPOCH | AHM_EPOCH | LAST_GOOD_EPOCH
---------------+-----------+-----------------1349 |      1347 |            1347
(1 row)-- In Vertica, UPDATE is DELETE + INSERT. => UPDATE test_epochs SET c1 = 2 WHERE c1 = 1;OUTPUT
--------1
(1 row)- Because transaction has not been committed, the epoch column is empty.
=> SELECT epoch, * FROM test_epochs;epoch | c1
-------+----|  2
(1 row)=> COMMIT;
COMMIT- After the COMMIT, the last epoch becomes the last current epoch.
=> SELECT epoch, * FROM test_epochs;epoch | c1
-------+----1349 |  2
(1 row)=> SELECT CURRENT_EPOCH, AHM_EPOCH, LAST_GOOD_EPOCH FROM SYSTEM;CURRENT_EPOCH | AHM_EPOCH | LAST_GOOD_EPOCH
---------------+-----------+-----------------1350 |      1348 |            1348
(1 row)

在执行SELECT语句时，Vertica会在 latest epoch中检索数据。 Vertica还会在同一事务中检索未提交的数据。
早于AHM删除的任何数据都可以删除。

Troubleshooting Epoch Issues

Last Good Epoch Does Not Advance

在某些情况下，LGE不会前进。如果LGE前进，您将看到以下结果。当元组移动器将数据从WOS移到ROS时，LGE前进：

=>SELECT CURRENT_EPOCH, LAST_GOOD_EPOCH FROM SYSTEM ;CURRENT_EPOCH   |   LAST_GOOD_EPOCH
---------------+-----------------630384   |       620380

1.如果你发现LGE没有前进，检查数据是否在wos中：

=>SELECT sum(wos_used_bytes) from projection_storage ;sum
-------49152

2.如果wos中有数据，执行moveout操作：

=> SELECT do_tm_task('moveout');

3.如果有静态数据，请检查元组移动器。由于以下原因，元组移动器移出操作失败：

元组移动器无法在表上获取T型锁。
当移出操作无法创建新容器时，由于达到了ROS容器的最大数量，因此发生ROS推回。
在WOS中有超过1024个分区。

可以在vertica.log查找错误原因。

4.replay delete 降低了Tuple Mover的运行速度。要验证元组移动器的移动，请使用以下命令：

SELECT * from tuple_mover_operations where is_executing ;

Ancient History Mark Does Not Advance

有时候，ancient history marker不会前进。在以下情况下，AHM不会前进：
1.有未刷新的投影。使用此方法检查是否有未刷新的投影。

=> SELECT * FROM projections where is_up_to_date = 'f';

2.要刷新的投影是一张大表。
3.集群中有节点down掉了。

Vertica Epoch Functions

Vertica提供以下Epoch系统函数。

GET_AHM_EPOCH
GET_CURRENT_EPOCH
GET_LAST_GOOD_EPOCH
SET_AHM_EPOCH