Using Bacula 2.0.3 with MySQL 4.1.20 on a CentOS 4.5 x86 director. Doing a
full backup of a new file system from a 2.0.3/CentOS 4.5/x86_64 client
gives:
28-Jun 12:33 dante-dir: No prior Full backup Job record found.
28-Jun 12:33 dante-dir: No prior or suitable Full backup found in catalog.
The table 'File' is full
I've tried starting mysqld with the big-tables option, but that shouldn't
be needed with this version of mysql, and in any event it doesn't make any
difference. The /var/bacula filesystem has plenty of free space (about
8GB). The bacula mysql database is about
On Thu, 28 Jun 2007, Steve Thompson wrote:
28-Jun 12:33 dante-dir: inca-10_data1.2007-06-28_12.33.36 Fatal error:
sql_create.c:753 Create db File record INSERT INTO File
(FileIndex,JobId,PathId,FilenameId,LStat,MD5) VALUES
(1,1800,8249353,345586,'gR BrMoF IGk B RK P1 A A BAA A BGHokQ
On Thu, 28 Jun 2007, David Romerstein wrote:
On Thu, 28 Jun 2007, Steve Thompson wrote:
28-Jun 12:33 dante-dir: inca-10_data1.2007-06-28_12.33.36 Fatal error:
sql_create.c:753 Create db File record INSERT INTO File
(FileIndex,JobId,PathId,FilenameId,LStat,MD5) VALUES
Helo,
I have the following error:
26-Jun 17:31 Backup-Director: SkipperBackup.2006-06-26_06.00.01 Fatal error:
sql_create.c:734 Create db File record INSERT INTO File
(FileIndex,JobId,PathId,FilenameId,LStat,MD5) VALUES
(486853,1161,8383,10971,'gG 4IL IGk B A A A BkA BAA Q BEjTBI 6XZCc BDh0H3
On Mon, Jun 26, 2006 at 05:35:19PM +0200, Bernhard Suttner wrote:
Helo,
I have the following error:
26-Jun 17:31 Backup-Director: SkipperBackup.2006-06-26_06.00.01 Fatal error:
sql_create.c:734 Create db File record INSERT INTO File
(FileIndex,JobId,PathId,FilenameId,LStat,MD5) VALUES
This worked for me when I hit the limit:
http://jeremy.zawodny.com/blog/archives/000796.html
Be sure to have a recent dump in case anything goes wrong.
-Sebastian
On Feb 1, 2006, at 3:37 PM, Roger Kvam wrote:
27-Jan 00:45 alexandria-dir: LogicBackupAvr32.2006-01-27_00.05.10
Fatal
So it would *seem* that using this option (increasing max_rows) is a
better option that converting to InnoDB, since MyISAM is faster for
inserting. Does this make sense?
Ryan
Sebastian Stark wrote:
This worked for me when I hit the limit:
Am 02.02.2006 um 18:31 schrieb Ryan Sizemore:
So it would *seem* that using this option (increasing max_rows) is a
better option that converting to InnoDB, since MyISAM is faster for
inserting. Does this make sense?
I really don't know, we chose this way because it seemed the least
On Wed, 1 Feb 2006, Daniel Holtkamp wrote:
Hi !
Roger Kvam wrote:
My MySQL database is 6.8G, while the File.MYD is 4.0G
You ran into a mysql-limit there. The File Table apparently uses MyISAM as
storage engine and the max-limit there is 4 GB.
Only by default. It _can_ be increased and
27-Jan 00:45 alexandria-dir: LogicBackupAvr32.2006-01-27_00.05.10 Fatal error:
sql_create.c:732 sql_create.c:732 insert INSERT INTO File
(FileIndex,JobId,PathId,FilenameId,LStat,MD5) VALUES
(55527,829,2825202,2033976,'Bc sHVV IGk B Yc Y CwOuQ WvE BAA C4 BD0Kbs BD0Kbs
BD2MTW A A C','0')
Hi !
Roger Kvam wrote:
My MySQL database is 6.8G, while the File.MYD is 4.0G
You ran into a mysql-limit there. The File Table apparently uses MyISAM
as storage engine and the max-limit there is 4 GB. Fire up
mysql-administrator and change the storage engine to InnoDB then you`re
fine. (On
is there no performance impact ? innodb is not that good at inserting data ...
Le Mercredi 01 Février 2006 16:08, Daniel Holtkamp a écrit :
Hi !
Roger Kvam wrote:
My MySQL database is 6.8G, while the File.MYD is 4.0G
You ran into a mysql-limit there. The File Table apparently uses MyISAM
13 matches
Mail list logo
