table restore in version 7.2 error
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.
Comments
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
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.
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.