Skip to main content

table restore in version 7.2 error

  • January 11, 2016
  • 3 replies
  • 15 views
colin_loghin
Forum|alt.badge.img+2

Hi, 

I am testing the single table restore on version  vertica-7.2.1-0.x86_64 . 

 

The restore script is as below:

 

vbr --task restore --config-file vbr.ini  --restore-objects=dc.translate --archive=20151227_110005

 

I have multiple backups and i have tried with more than 1. I have also tried restoring different objects , objects that have existed in the database for a long time.  I invariably receive 

 

Starting object restore of database db.

Participating nodes: v_db_node0001,v_db_node0002,v_db_node0003,v_db_node0004,v_db_node0005,v_db_node0006,v_db_node0007,v_db_node0008,v_db_node0009,v_db_node0010,v_db_node0011,v_db_node0012,v_db_node0013,v_db_node0014,v_db_node0015.

Objects to restore: dc.translate.

Restoring from restore point: backup_vertica01_09_20151227_110005

Loading snapshot catalog from backup.

Extracting objects from catalog.

Error: Extracting objects from catalog failed.

Restore FAILED.

 

I looked into the vbr log files  and i see the following message : 

 

2016-01-11 12:07:48 localhost vbr Extracting objects from catalog.

2016-01-11 12:07:49 localhost vbr Node v_db_node0004: extract subset catalog.

2016-01-11 12:07:49 localhost vbr Node v_db_node0009: extract subset catalog.

...

2016-01-11 12:08:04 localhost vbr Error status returned from extract-snapshot: -11

....

2016-01-11 12:08:06 localhost vbr Error status returned from extract-snapshot: -11

2016-01-11 12:08:09 localhost vbr Error: Extracting objects from catalog failed.

  Restore FAILED.

 

Any idea why the object to be restored is not being located in the subset catalog ? 

 

Thank you. 

 

    3 replies

    SruthiA
    Forum|alt.badge.img+1
    • SruthiA
    • Participating Frequently
    • January 11, 2016

    Hi,

     

    run vbr/py with --debug 3 . This will print additional information in teh vbr.log. It is possible that the table you are trying to restore has some foreign key constraint defined - in which case, you must restore that table as well.

     

    Thank you,

    Sruthi

    colin_loghin
    Forum|alt.badge.img+2
    • colin_loghin
    • Author
    • Participating Frequently
    • January 12, 2016

    Thanks for the debug hint Sruthi. In the mean time, I was told that we have some segfaults in /var/log/messages that are coming from extract_snapshot process, which is nothing but a symlink to the vertica binary. 

     

    The debug option did not yield more actionable info though. 

     

    2016-01-11 19:27:41 10.214.2.21 remote_procedure Executing: /opt/vertica/bin/extract-snapshot /mnt/db/db/v_db_node0011_catalog tmp_20160111_192712 tmp_20160111_192712.ctlg 0 backup_vertica01_09 dc.translate

    2016-01-11 19:27:41 localhost vbr Error status returned from extract-snapshot: -11

     

    In /var/log/messages we see

     

    Jan 11 19:27:40 vertica01 kernel: extract-snapsho[36033]: segfault at 18 ip 000000000309f834 sp 00007ffd374cf0b0 error 4 in vertica[400000+445f000]

     

    The table is a very simple 1 row , 2 integer columns containing -1 ,1 values. I specifically went for a simpler usecase when the more complicated one failed with the same error. 

     

    Still puzzled, but now we know there is a segfault. 

    colin_loghin
    Forum|alt.badge.img+2
    • colin_loghin
    • Author
    • Participating Frequently
    • January 12, 2016

    I have just created a support case to track the issue. I was expecting that others ran into the same problem and would add their comments, but no other feedback yet.

     

     

    Still scrolling?
    Ask a question
    Terms & ConditionsAccessibility statement