On Mon, Apr 21, 2014 at 08:25:50AM -0600, Lloyd Brown wrote:
At the moment:
mysql select count(*) from File;
+---+
| count(*) |
+---+
| 287794478 |
+---+
1 row in set (0.00 sec)
Definitely more than I expected. Although, I have to say, RAM usage on
Alan,
I understand. I've been meaning to get started with learning Postgres
for several years, but there always seems to be something more urgent
that takes my attention away. At the moment, it's storage system
failures, which is kinda a big deal, so for now I'll have to be content
with the
On 04/24/2014 11:37 AM, Lloyd Brown wrote:
Alan,
I understand. I've been meaning to get started with learning Postgres
for several years, but there always seems to be something more urgent
that takes my attention away. At the moment, it's storage system
failures, which is kinda a big
On 24/04/14 17:37, Lloyd Brown wrote:
Alan,
I understand. I've been meaning to get started with learning Postgres
for several years, but there always seems to be something more urgent
that takes my attention away.
If you're using RH/Debian/Ubuntu then you can get it running fairly
quickly
I second what Alan says ... I waited a long time too and it was a bit
harder to get PostgreSQL work with Bacula (permissions and such all of
which are documented in the manual), but I definitely would not go back.
PostgreSQL 9.1 or later is particularly good with Bacula.
Best regards,
Kern
On
On 21/04/14 15:25, Lloyd Brown wrote:
Definitely more than I expected. Although, I have to say, RAM usage on
this host isn't really much of a concern. At the moment, the mysqld
process is only using just over 1GB of RAM, and this host has 128G.
Possibly I need to tune MySQL to keep more of
Hello,
If the optimizations of MySQL do not work out, my experience with
*very* large Bacula databases agrees with what Alan wrote below.
You have to be careful though, PostgreSQL out of the box is
*horribly* tuned for Bacula so you *must* change about 7
On 04/19/2014 09:10 PM, Alan Brown wrote:
On 18/04/14 23:49, Lloyd Brown wrote:
Are the tables in MyISAM or InnoDB format?
At the moment, MyISAM. I'd wondered if I could safely convert to
InnoDB, since that's generally going to have better locking
characteristics, etc.
It's easy enough
On 18/04/14 23:49, Lloyd Brown wrote:
Are the tables in MyISAM or InnoDB format?
At the moment, MyISAM. I'd wondered if I could safely convert to
InnoDB, since that's generally going to have better locking
characteristics, etc.
It's easy enough to change, but
How large are the tables? In
On 18/04/14 23:49, Lloyd Brown wrote:
At the moment, MyISAM. I'd wondered if I could safely convert to
InnoDB, since that's generally going to have better locking
characteristics, etc.
As I've stated here before, it is my considered opinion that MyISAM
should no longer be in use in
Hi, all.
I'm trying to diagnose some overall slowness issues with some of our
backups. In this case, the SD, FD, and Dir, are all running on one
host. The storage being backed up from is NFS (or similarly) mounted,
and the backup destination is some SAS-attached disks on this particular
host.
On Fri, 18 Apr 2014 09:18:55 -0600, Lloyd Brown said:
Hi, all.
I'm trying to diagnose some overall slowness issues with some of our
backups. In this case, the SD, FD, and Dir, are all running on one
host. The storage being backed up from is NFS (or similarly) mounted,
and the backup
On 04/18/2014 04:44 PM, Martin Simmons wrote:
The second query is related to pruning (probably autoprune unless you are
using the prune command on the console). This is normal while jobs are
running.
Autoprune. Definitely autoprune.
Are the tables in MyISAM or InnoDB format?
At the
13 matches
Mail list logo
