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 |  1898
 3 | 4 |  1898
 5 | 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 |         1350
 2015-11-09 18:03:30.454707+00 |         1351
 2015-11-09 18:04:48.329494+00 |         1371
 2015-11-09 18:18:42.796702+00 |         1372
 2015-11-09 18:19:52.738018+00 |         1392
 2015-11-09 18:26:43.655577+00 |         1393
 2015-11-11 15:21:47.918074+00 |         1394
 2015-11-11 15:23:16.80952+00  |         1897
 2015-11-20 18:13:20.324436+00 |         1898
 2015-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   |   f
 v_test_israel_node0003 | public  |   product_dimension_b1   |   t   |    1347   |   f   |   f
 v_test_israel_node0002 | public  |   product_dimension_b1   |   t   |    1347   |   f   |   f
 v_test_israel_node0002 | store   |   store_dimension_b1     |   t   |    1347   |   f   |   f
 v_test_israel_node0003 | store   |   store_dimension_b1     |   t   |    1347   |   f   |   f
 v_test_israel_node0001 | store   |   store_dimension_b1     |   t   |    1347   |   f   |   f
 v_test_israel_node0002 | public  |   promotion_dimension_b1 |   t   |    1347   |   f   |   f
 v_test_israel_node0001 | public  |   promotion_dimension_b1 |   t   |    1347   |   f   |   f
 v_test_israel_node0003 | public  |   promotion_dimension_b1 |   t   |    1347   |   f   |   f
 v_test_israel_node0001 | public  |   warehouse_dimension_b1 |   t   |    1347   |   f   |   f
 v_test_israel_node0002 | public  |   warehouse_dimension_b1 |   t   |    1347   |   f   |   f
 v_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 1347
        Node 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
  • 0
    点赞
  • 3
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值