Restore failed

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Restore failed

Pedro Alves-2


Hey there


Getting issues with lucid backup / restore. Same version, different
machines, one 64 and one 32 bits.


pedro@nicola:bin$ ./sqllineEngine
Connecting to jdbc:luciddb:
Connected to: LucidDB (version 0.9.3)
Driver: LucidDbJdbcDriver (version 0.9)
Autocommit status: true
Transaction isolation: TRANSACTION_REPEATABLE_READ
sqlline version 1.0.8-eb by Marc Prud'hommeaux
0: jdbc:luciddb:> CALL
SYS_ROOT.RESTORE_DATABASE_WITHOUT_CATALOG('/path/to/fullbackup');
Error: System call failed:  Read from backup file
/home/pedro/projectos/stonegate/db/fullbackup/FennelDataDump.dat.gz failed:
No such file or directory (state=,code=0)
0: jdbc:luciddb:>




Any tips?



--
Pedro Alves

------------------------------------------------------------------------------
Benefiting from Server Virtualization: Beyond Initial Workload
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve
application availability and disaster protection. Learn more about boosting
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
_______________________________________________
luciddb-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/luciddb-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Restore failed

ngoodman

Getting issues with lucid backup / restore. Same version, different
machines, one 64 and one 32 bits.

Pedro,

Backup/Restore will only work properly on the same architecture; mixing 32 and 64 bits won't work.  There IS however, the EXPORT_SCHEMA_TO_FILE which is a *logical* export of the data/structures that can be read back in using the Flat File Foreign Data connector on another server.

We've got some other stuff that would help with in the upcoming 0.9.4 release (http://pub.eigenbase.org/wiki/LucidDbSysRoot_GENERATE_DDL_FOR) that will allow you to export your entire DDL and then run it on the new LucidDB in conjunction with the EXPORT_SCHEMA_TO_FILE.

Also, and perhaps the easiest, you can simply connect the Lin64 instance to the Lin32 instance (via SYS_JDBC connector) and replicate the data over directly (INSERT INTO NEWTABLE SELECT * FROM LIN32.OLDTABLE).

Let me know if you need anything more Pedro!

Nicholas Goodman
Founder, CEO
DynamoBI Corporation
[hidden email]

------------------------------------------------------------------------------
Benefiting from Server Virtualization: Beyond Initial Workload
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve
application availability and disaster protection. Learn more about boosting
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
_______________________________________________
luciddb-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/luciddb-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Restore failed

Julian Hyde
In reply to this post by Pedro Alves-2
> Getting issues with lucid backup / restore. Same version, different
> machines, one 64 and one 32 bits.

Might it be this issue:

http://fennel-developers.1374754.n2.nabble.com/Tuple-Accessor-alignment-chan
ge-tc6285189.html

It's always dangerous to assume that a problem is related to another problem
one saw a few days previously. But this 32- versus 64-bit alignment issue
can only really occur in two ways: if you are writing data across a network,
or if you are reading data in one architecture that was written in another
architecture.

Julian


------------------------------------------------------------------------------
Benefiting from Server Virtualization: Beyond Initial Workload
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve
application availability and disaster protection. Learn more about boosting
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
_______________________________________________
luciddb-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/luciddb-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Restore failed

Pedro Alves-2
In reply to this post by ngoodman



Connecting both of them is not an option - I'm transferring a big db to
work locally over a very slow network. I honestly wouldn't expect a backup
/ restore to be arch dependent (maybe a note on the wiki?)



Is it an option just to rsync the catalog dir?



-pedro



On Wed, Apr 20, 2011 at 08:46:47AM -0700, Nicholas Goodman wrote:

>      Getting issues with lucid backup / restore. Same version, different
>      machines, one 64 and one 32 bits.
>
>    Pedro,
>    Backup/Restore will only work properly on the same architecture; mixing 32
>    and 64 bits won't work.  There IS however, the EXPORT_SCHEMA_TO_FILE which
>    is a *logical* export of the data/structures that can be read back in
>    using the Flat File Foreign Data connector on another server.
>    We've got some other stuff that would help with in the upcoming 0.9.4
>    release ([1]http://pub.eigenbase.org/wiki/LucidDbSysRoot_GENERATE_DDL_FOR)
>    that will allow you to export your entire DDL and then run it on the new
>    LucidDB in conjunction with the EXPORT_SCHEMA_TO_FILE.
>    Also, and perhaps the easiest, you can simply connect the Lin64 instance
>    to the Lin32 instance (via SYS_JDBC connector) and replicate the data over
>    directly (INSERT INTO NEWTABLE SELECT * FROM LIN32.OLDTABLE).
>    Let me know if you need anything more Pedro!
>    Nicholas Goodman
>    Founder, CEO
>    DynamoBI Corporation
>    [2][hidden email]
>
> References
>
>    Visible links
>    1. http://pub.eigenbase.org/wiki/LucidDbSysRoot_GENERATE_DDL_FOR
>    2. mailto:[hidden email]

> ------------------------------------------------------------------------------
> Benefiting from Server Virtualization: Beyond Initial Workload
> Consolidation -- Increasing the use of server virtualization is a top
> priority.Virtualization can reduce costs, simplify management, and improve
> application availability and disaster protection. Learn more about boosting
> the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
> _______________________________________________
> luciddb-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/luciddb-users


--
Pedro Alves

------------------------------------------------------------------------------
Benefiting from Server Virtualization: Beyond Initial Workload
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve
application availability and disaster protection. Learn more about boosting
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
_______________________________________________
luciddb-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/luciddb-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Restore failed

ngoodman
On Apr 20, 2011, at 3:13 PM, Pedro Alves wrote:

> Connecting both of them is not an option - I'm transferring a big db to
> work locally over a very slow network. I honestly wouldn't expect a backup
> / restore to be arch dependent (maybe a note on the wiki?)
I've added a bullet on the wiki about the architecture specific nature of the physical backup.

Physical backup and restore (including incremental) is done at a physical level and is highly optimized.  Restore is close to the speed of "cp" which is great.  However, Fennel storage (db.dat) is architecture (lin/win) specific (think word size, data bit addressing sizes, etc).  If it were the same architecture, you'd be impressed I'm sure!  ;)

Again, if the physical backup/restore won't work because of your architecture differences, and you have a slow network.  You can do a LOGICAL backup/restore.

First, outlined in the Wiki above is to do a logical export (http://pub.eigenbase.org/wiki/LucidDbSysRoot_EXPORT_SCHEMA_TO_FILE) and then tar/gzip that output and scp those over.

Second, you can also do table by table, with inline compression with WRITE_ROWS_TO_FILE and READ_ROWS_TO_FILE
http://pub.eigenbase.org/wiki/AppLib_WRITE_ROWS_TO_FILE
http://pub.eigenbase.org/wiki/LucidDbAppLib_READ_ROWS_FROM_FILE

In both cases (READ/WRITE table functions or EXPORT_SCHEMA_TO_FILE UPD) you'll need to (re)create your tables on the new LucidDB.  You can explore exporting/importing the catalog (via XMI) but I'm betting / hoping you have your DDL lying around.

> Is it an option just to rsync the catalog dir?
Nope... the db.dat is architecture specific.  Copying won't work across arch's either.

Nick
------------------------------------------------------------------------------
Benefiting from Server Virtualization: Beyond Initial Workload
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve
application availability and disaster protection. Learn more about boosting
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
_______________________________________________
luciddb-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/luciddb-users
Loading...