Re: [Dbmail] multiple DBs and ACL checks

[Aaron Stone]

Unless Perdition sits right in the protocol session and is proxying on a
per-command basis so that it sends some commands to one server and some
to another -- and I have no idea how that would work -- then, no, you
cannot connect to a shared mailbox on another partition. It is a neat
idea, though! but the code would probably be absolutely brutal.

Aaron

On Tue, 2007-07-31 at 22:07 -0700, Jonathan Fealy wrote:
> As a user logs into another instance, the user should be created 
> automatically in the dbmail_users table. However, the dbmail_acl table 
> is usually configured to be locked into a row being existent in the 
> users table. Either the user needs to login to that server to create the 
> record, or you the admin need to create a correct user on that box 
> before adding the acl. This would make constant changes/add to acl's 
> difficult and tedious. Once setup, I think it should work ok provided 
> that your proxy is doing things correctly and that when the user is 
> selecting a folder from a different instance that connection is being 
> done with the connected user's credentials.
> 
> -Jon
> 
> WJCarpenter wrote:
> > jf> DBMail doesn't currently work in multiple databases at one
> > jf> time. Thus you would end up with multiple instances of dbmail
> > jf> databases and applications running. The LDAP authentication would
> > jf> allow you to have 1 central location for user/pass combos, however
> > jf> your users would need to always log into the same instance of
> > jf> databases/apps to even see the same content as before. Regular TCP
> >
> > Thanks.  I think you may have misunderstood what I'm thinking of (not
> > least because I didn't go into detail on that part).  I intend to do
> > load balancing with an IMAP proxy like perdition which will
> > transparently connect my users to the correct server.  Incoming mail
> > will similarly be fanned out by my MTA's local delivery mechanism.
> >
> > So, I fully expect there to be one dbmail instance controlling exactly
> > one MySQL instance, and I don't expect the dbmail instances to know
> > anything about each other.  If my front end connects to a dbmail
> > instance and tries to access a given folder (belonging to someone
> > else), will the ACL system freak because the connecting user doesn't
> > have a mailstore in that dbmail instance?
> >
> > ___
> > DBmail mailing list
> > DBmail@dbmail.org
> > https://mailman.fastxs.nl/mailman/listinfo/dbmail
> >
> >
> >   
> 
> 
> 
> ___
> DBmail mailing list
> DBmail@dbmail.org
> https://mailman.fastxs.nl/mailman/listinfo/dbmail

___
DBmail mailing list
DBmail@dbmail.org
https://mailman.fastxs.nl/mailman/listinfo/dbmail

Re: [Dbmail] multiple DBs and ACL checks

[Jonathan Fealy]

As a user logs into another instance, the user should be created 
automatically in the dbmail_users table. However, the dbmail_acl table 
is usually configured to be locked into a row being existent in the 
users table. Either the user needs to login to that server to create the 
record, or you the admin need to create a correct user on that box 
before adding the acl. This would make constant changes/add to acl's 
difficult and tedious. Once setup, I think it should work ok provided 
that your proxy is doing things correctly and that when the user is 
selecting a folder from a different instance that connection is being 
done with the connected user's credentials.


-Jon

WJCarpenter wrote:

jf> DBMail doesn't currently work in multiple databases at one
jf> time. Thus you would end up with multiple instances of dbmail
jf> databases and applications running. The LDAP authentication would
jf> allow you to have 1 central location for user/pass combos, however
jf> your users would need to always log into the same instance of
jf> databases/apps to even see the same content as before. Regular TCP

Thanks.  I think you may have misunderstood what I'm thinking of (not
least because I didn't go into detail on that part).  I intend to do
load balancing with an IMAP proxy like perdition which will
transparently connect my users to the correct server.  Incoming mail
will similarly be fanned out by my MTA's local delivery mechanism.

So, I fully expect there to be one dbmail instance controlling exactly
one MySQL instance, and I don't expect the dbmail instances to know
anything about each other.  If my front end connects to a dbmail
instance and tries to access a given folder (belonging to someone
else), will the ACL system freak because the connecting user doesn't
have a mailstore in that dbmail instance?

___
DBmail mailing list
DBmail@dbmail.org
https://mailman.fastxs.nl/mailman/listinfo/dbmail


  




___
DBmail mailing list
DBmail@dbmail.org
https://mailman.fastxs.nl/mailman/listinfo/dbmail

Re: [Dbmail] multiple DBs and ACL checks

[WJCarpenter]

jf> DBMail doesn't currently work in multiple databases at one
jf> time. Thus you would end up with multiple instances of dbmail
jf> databases and applications running. The LDAP authentication would
jf> allow you to have 1 central location for user/pass combos, however
jf> your users would need to always log into the same instance of
jf> databases/apps to even see the same content as before. Regular TCP

Thanks.  I think you may have misunderstood what I'm thinking of (not
least because I didn't go into detail on that part).  I intend to do
load balancing with an IMAP proxy like perdition which will
transparently connect my users to the correct server.  Incoming mail
will similarly be fanned out by my MTA's local delivery mechanism.

So, I fully expect there to be one dbmail instance controlling exactly
one MySQL instance, and I don't expect the dbmail instances to know
anything about each other.  If my front end connects to a dbmail
instance and tries to access a given folder (belonging to someone
else), will the ACL system freak because the connecting user doesn't
have a mailstore in that dbmail instance?

___
DBmail mailing list
DBmail@dbmail.org
https://mailman.fastxs.nl/mailman/listinfo/dbmail

Re: [Dbmail] multiple DBs and ACL checks

[Jonathan Fealy]

DBMail doesn't currently work in multiple databases at one time. Thus 
you would end up with multiple instances of dbmail databases and 
applications running. The LDAP authentication would allow you to have 1 
central location for user/pass combos, however your users would need to 
always log into the same instance of databases/apps to even see the same 
content as before. Regular TCP Load balancing would be very bad. Your 
users, once on a particular server, would only be able to see other 
mailboxes in the same instance. There has been talk of allowing one 
instance of the app to open multiple connections to different database 
servers, but that is for database clustering where 1 server is the write 
server, and server 2+ are read only servers.


I'm not sure if you will be having multiple companies on the same server 
or not, but if so, keeping your users seperated by domain is probably 
your best bet. You could then manually balance out your users by putting 
3 small domains on one server and 2 medium size on another and a huge 
one all by itself, etc.


Hope that helps
-Jon


WJCarpenter wrote:

I have in mind a deployment where I would provision users in a
particular MySQL instance until it gets to some capacity level that
I'm comfortable with.  After that, I'd create a new MySQL instance on
another server and start provisioning users into that.  Lather, rinse,
repeat.

Assuming I use a single logical LDAP directory for authentication,
groups, etc, would ACLs work correctly for sharing mailboxes?  In
other words, user Alice has her mailstore in MySQL database A.  User
Bob has his mailstore in MySQL database B.  Can Bob grant access to a
folder to Alice and expect it to work?

(I know this *should* work.  I'm just wondering if there is some
secret "gotcha" in dbmail that will sink the idea.)

Thanks.

___
DBmail mailing list
DBmail@dbmail.org
https://mailman.fastxs.nl/mailman/listinfo/dbmail


  




___
DBmail mailing list
DBmail@dbmail.org
https://mailman.fastxs.nl/mailman/listinfo/dbmail

[Dbmail] multiple DBs and ACL checks

[WJCarpenter]

I have in mind a deployment where I would provision users in a
particular MySQL instance until it gets to some capacity level that
I'm comfortable with.  After that, I'd create a new MySQL instance on
another server and start provisioning users into that.  Lather, rinse,
repeat.

Assuming I use a single logical LDAP directory for authentication,
groups, etc, would ACLs work correctly for sharing mailboxes?  In
other words, user Alice has her mailstore in MySQL database A.  User
Bob has his mailstore in MySQL database B.  Can Bob grant access to a
folder to Alice and expect it to work?

(I know this *should* work.  I'm just wondering if there is some
secret "gotcha" in dbmail that will sink the idea.)

Thanks.

___
DBmail mailing list
DBmail@dbmail.org
https://mailman.fastxs.nl/mailman/listinfo/dbmail

Re: [Dbmail] Changelog

[Josh Marshall]

Hi,

As a 2.2.5 user, should I care about these indexes? Will they be used in 
that version? When I upgrade to 2.2.6 (when released) will these indexes 
get created automatically?


Thanks.

http://nfg3.nfgs.net/cgi-bin/gitweb.cgi?p=dbmail.git;a=commitdiff;h=8ae82ff426114dc2fc648273a40f053d0cc6e8bc
  


___
DBmail mailing list
DBmail@dbmail.org
https://mailman.fastxs.nl/mailman/listinfo/dbmail

R: R: R: [Dbmail] Advantages of innodb_file_per_table (was:

[Andrea Brancatelli]

I already did it. I also did some layout, take a look at the wiki and let me
know if it's ok.

I'll try to write up some more things in the optimization tricks section. 

-Messaggio originale-
Da: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Per conto
di Aaron Stone
Inviato: martedì 31 luglio 2007 23.12
A: DBMail mailinglist
Oggetto: Re: R: R: [Dbmail] Advantages of innodb_file_per_table (was:

Thanks! Ok, will do :-)

On Tue, Jul 31, 2007, Andrea Brancatelli <[EMAIL PROTECTED]> said:

> Ok, i'll write some more rants about optimizing innodb tomorrow if i have
> some more time.
> 
> Please fix my English before reproduce it :-)
> 
> -Messaggio originale-
> Da: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Per conto
> di Aaron Stone
> Inviato: marted� 31 luglio 2007 20.50
> A: DBMail mailinglist
> Oggetto: Re: R: [Dbmail] Advantages of innodb_file_per_table (was:
> 
> Great writeup. Now on the wiki at:
> 
> http://dbmail.org/dokuwiki/doku.php?id=mysql_notes
> 
> I left a space where we should include more information about configuring
> InnoDB parameters for good performance. This does tend to be a FAQ, and
> the bits of information we do have about it are scattered all over the
> place.
> 
> Aaron
> 
> 
> On Tue, Jul 31, 2007, Andrea Brancatelli <[EMAIL PROTECTED]> said:
> 
>> Just an addendum.
>> 
>> With innodb_file_per_table whenever you delete a table or a database, the
>> whole .idb file gets deleted so you instantly get your space back. Maybe
I
>> wasn't clear enough on this in the latest lines of my mail.
>> 
>> -Messaggio originale-
>> Da: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Per
conto
>> di Andrea Brancatelli
>> Inviato: marted� 31 luglio 2007 17.16
>> A: 'DBMail mailinglist'
>> Oggetto: R: [Dbmail] Advantages of innodb_file_per_table (was:
>> Tabledbmail_messages is full)
>> 
>> I partially explained in my last email.
>> 
>> Let me try to summarize everything. 
>> 
>> WITHOUT innodb_file_per_table:
>>  - you have one shared tablespace for all the tables. This gives you the
>> advantage of limiting the space your db will be using (unless you
activate
>> the autoextend) but give you the disadvantage of preallocating all the
> space
>> you'll be using
>>  - the problem everyone is having is because on the autoextend. Actually
>> it's conceptually wrong to use the autoextend when you have a single
>> tablespace, because whenever your DB will grow, the tablespace will grow,
>> but it will never get smaller, even when you delete a table or when you
> run
>> an optimize
>>  - the optimize table issue is pretty simple. When you run optimize
table,
>> it simple re-create the whole table you're creating, writing all the
datas
>> sequentially. This gives you a certain degree of speed when you'll be
>> accessing datas later, but may be a problem because at a certain moment
(a
>> second before the optimize finish) you'll end up having 2 copies of the
> same
>> table: the old one, and the new temporary one that will be renamed as the
>> new one. If you are using the shared tablespace with the autoextend this
>> will probably mean that your shared tablespace will GROW because the
> amount
>> of datas will double, and when the optimize will finish the old table
will
>> be deleted and all the hypothetically-free space will just sit there
> waiting
>> to be used. This is the key point. InnoDB doesn't free the disk space
>> because it just wait for the space to be used again, because it's
designed
>> to be used in an environment where you preallocate the space for the db.
> So
>> since you preallocated it, why should you care about freeing it?
>> 
>> 
>> WITH innodb_file_per_table:
>>  - you have one (actually two) file per each InnoDB table. Each
> table/index
>> file will stay in the database directory (which _to me_ appears as
another
>> big advantage)
>>  - when you add a table you get another .idb file. Whenever your table
> grow,
>> the idb file grows, and your filesystem space decrease
>>  - the optimize process here gets interesting. When you run optimize
table
>> the innodb engine will start to create a NEW .idb file with a temporary
>> name, using only the space it actually needs to store the datas. When the
>> optimize table has ended, it will delete the old .idb file and rename the
>> temporary one to the correct name. this mean that if your old table's
.idb
>> file had grown up to 3, 4, 5, 100 GB but you have only 100 MB of datas in
>> it, the new .idb file will be 100MB while the one that will be deleted
was
>> 3, 4, 5, 100GB.
>> 
>> 
>> That's it in term of space. In terms of speed or whatever else I can't
say
>> if there's any advantage as I haven't done any testing myself, but what I
>> can assure you for sure is that, having any .idb in every directory you
> can
>> mount directory from different HDs or RAIDs for different DBs thus having
>> better racing conditions within the same MySQL server.
>> 
>> Probably you could achieve the same result having more than one s

R: R: [Dbmail] Advantages of innodb_file_per_table (was:Table dbmail_messages is full)

[Andrea Brancatelli]

The are various performance tests around the net concerning the
innodb_file_per_table topic but I think they are basically very useless.

There is a wide bunch of factors that can have a strong influence on the
real usage of both situation. Let me draw a couple:

1) preallocating the space gives you (well, may give you) better
distribution across the physical drive... as long as you preallocate the
space when the drive is empty. In this case you'll get less interaction
between the "real" filesystem and the database as basically the DB's data's
is always in the same place.
2) on the contrary having the different .idb files per each table will have
a strong interaction with the rest of the filesystem. If you have a lot of
files coming and going on your drive you'll probably have an high
fragmentation of free space, so the growing .idb will get fragmentized as
well.

In general we could do some benchmarks but I think they will be totally
useless because the ballpark is so much different from situation to
situation. Testing it with nothing else than MySQL running will give you a
very wrong environment, while testing it with "something else" running will
give something that hardly reflects on other people usage.

Maybe we can do DOZENS of benchmark and then try to draw a medium value ;-)

Personally I think it all comes down to easiness of administration, and as
of this _I_ had much better feelings with file_per_table.

Opinions are like balls: everyone's got their own.

-Messaggio originale-
Da: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Per conto
di Peter Rabbitson
Inviato: martedì 31 luglio 2007 22.26
A: DBMail mailinglist
Oggetto: Re: R: [Dbmail] Advantages of innodb_file_per_table (was:Table
dbmail_messages is full)

Andrea Brancatelli wrote:
>
> 
> 
> Summarizing everything:
> 
>  - If you have a single DB server: use a shared InnoDB tablespace
> preallocating the space and disabling the autoextend. Using the optimize
> table will give you a better optimization of the tables, and you'll have
no
> problem with the space as it's already allocated up to a fixed size
> 
>  - If you have a machine with various tasks going on, like a mail server,
> web server, db server and whatever, use the innodb_file_per_table. Usigon
> the optimize table you'll reclaim your space back whenever you delete
> anything or whenever any table will significantly decrease in size.
> 
> 
> Doubt? Question? Fear? Panic?
> 
> 

Excellent writeup! So basically it helps avoid juggling around 50GB+ 
files. One question though - does it make any difference in performance? 
You said that you have not done any benchmarking - did anyone else on 
the list? When one has 15GB of email, performance counts.
___
DBmail mailing list
DBmail@dbmail.org
https://mailman.fastxs.nl/mailman/listinfo/dbmail

___
DBmail mailing list
DBmail@dbmail.org
https://mailman.fastxs.nl/mailman/listinfo/dbmail

Re: R: R: [Dbmail] Advantages of innodb_file_per_table (was:

[Aaron Stone]

Thanks! Ok, will do :-)

On Tue, Jul 31, 2007, Andrea Brancatelli <[EMAIL PROTECTED]> said:

> Ok, i'll write some more rants about optimizing innodb tomorrow if i have
> some more time.
> 
> Please fix my English before reproduce it :-)
> 
> -Messaggio originale-
> Da: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Per conto
> di Aaron Stone
> Inviato: marted� 31 luglio 2007 20.50
> A: DBMail mailinglist
> Oggetto: Re: R: [Dbmail] Advantages of innodb_file_per_table (was:
> 
> Great writeup. Now on the wiki at:
> 
> http://dbmail.org/dokuwiki/doku.php?id=mysql_notes
> 
> I left a space where we should include more information about configuring
> InnoDB parameters for good performance. This does tend to be a FAQ, and
> the bits of information we do have about it are scattered all over the
> place.
> 
> Aaron
> 
> 
> On Tue, Jul 31, 2007, Andrea Brancatelli <[EMAIL PROTECTED]> said:
> 
>> Just an addendum.
>> 
>> With innodb_file_per_table whenever you delete a table or a database, the
>> whole .idb file gets deleted so you instantly get your space back. Maybe I
>> wasn't clear enough on this in the latest lines of my mail.
>> 
>> -Messaggio originale-
>> Da: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Per conto
>> di Andrea Brancatelli
>> Inviato: marted� 31 luglio 2007 17.16
>> A: 'DBMail mailinglist'
>> Oggetto: R: [Dbmail] Advantages of innodb_file_per_table (was:
>> Tabledbmail_messages is full)
>> 
>> I partially explained in my last email.
>> 
>> Let me try to summarize everything. 
>> 
>> WITHOUT innodb_file_per_table:
>>  - you have one shared tablespace for all the tables. This gives you the
>> advantage of limiting the space your db will be using (unless you activate
>> the autoextend) but give you the disadvantage of preallocating all the
> space
>> you'll be using
>>  - the problem everyone is having is because on the autoextend. Actually
>> it's conceptually wrong to use the autoextend when you have a single
>> tablespace, because whenever your DB will grow, the tablespace will grow,
>> but it will never get smaller, even when you delete a table or when you
> run
>> an optimize
>>  - the optimize table issue is pretty simple. When you run optimize table,
>> it simple re-create the whole table you're creating, writing all the datas
>> sequentially. This gives you a certain degree of speed when you'll be
>> accessing datas later, but may be a problem because at a certain moment (a
>> second before the optimize finish) you'll end up having 2 copies of the
> same
>> table: the old one, and the new temporary one that will be renamed as the
>> new one. If you are using the shared tablespace with the autoextend this
>> will probably mean that your shared tablespace will GROW because the
> amount
>> of datas will double, and when the optimize will finish the old table will
>> be deleted and all the hypothetically-free space will just sit there
> waiting
>> to be used. This is the key point. InnoDB doesn't free the disk space
>> because it just wait for the space to be used again, because it's designed
>> to be used in an environment where you preallocate the space for the db.
> So
>> since you preallocated it, why should you care about freeing it?
>> 
>> 
>> WITH innodb_file_per_table:
>>  - you have one (actually two) file per each InnoDB table. Each
> table/index
>> file will stay in the database directory (which _to me_ appears as another
>> big advantage)
>>  - when you add a table you get another .idb file. Whenever your table
> grow,
>> the idb file grows, and your filesystem space decrease
>>  - the optimize process here gets interesting. When you run optimize table
>> the innodb engine will start to create a NEW .idb file with a temporary
>> name, using only the space it actually needs to store the datas. When the
>> optimize table has ended, it will delete the old .idb file and rename the
>> temporary one to the correct name. this mean that if your old table's .idb
>> file had grown up to 3, 4, 5, 100 GB but you have only 100 MB of datas in
>> it, the new .idb file will be 100MB while the one that will be deleted was
>> 3, 4, 5, 100GB.
>> 
>> 
>> That's it in term of space. In terms of speed or whatever else I can't say
>> if there's any advantage as I haven't done any testing myself, but what I
>> can assure you for sure is that, having any .idb in every directory you
> can
>> mount directory from different HDs or RAIDs for different DBs thus having
>> better racing conditions within the same MySQL server.
>> 
>> Probably you could achieve the same result having more than one shared
>> tablespace, but frankly I have no experience with this.
>> 
>> 
>> Summarizing everything:
>> 
>>  - If you have a single DB server: use a shared InnoDB tablespace
>> preallocating the space and disabling the autoextend. Using the optimize
>> table will give you a better optimization of the tables, and you'll have
> no
>> problem with the space as it's already allocated up to a fixed size
>> 

R: R: [Dbmail] Advantages of innodb_file_per_table (was:

[Andrea Brancatelli]

Ok, i'll write some more rants about optimizing innodb tomorrow if i have
some more time.

Please fix my English before reproduce it :-)

-Messaggio originale-
Da: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Per conto
di Aaron Stone
Inviato: martedì 31 luglio 2007 20.50
A: DBMail mailinglist
Oggetto: Re: R: [Dbmail] Advantages of innodb_file_per_table (was:

Great writeup. Now on the wiki at:

http://dbmail.org/dokuwiki/doku.php?id=mysql_notes

I left a space where we should include more information about configuring
InnoDB parameters for good performance. This does tend to be a FAQ, and
the bits of information we do have about it are scattered all over the
place.

Aaron


On Tue, Jul 31, 2007, Andrea Brancatelli <[EMAIL PROTECTED]> said:

> Just an addendum.
> 
> With innodb_file_per_table whenever you delete a table or a database, the
> whole .idb file gets deleted so you instantly get your space back. Maybe I
> wasn't clear enough on this in the latest lines of my mail.
> 
> -Messaggio originale-
> Da: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Per conto
> di Andrea Brancatelli
> Inviato: marted� 31 luglio 2007 17.16
> A: 'DBMail mailinglist'
> Oggetto: R: [Dbmail] Advantages of innodb_file_per_table (was:
> Tabledbmail_messages is full)
> 
> I partially explained in my last email.
> 
> Let me try to summarize everything. 
> 
> WITHOUT innodb_file_per_table:
>  - you have one shared tablespace for all the tables. This gives you the
> advantage of limiting the space your db will be using (unless you activate
> the autoextend) but give you the disadvantage of preallocating all the
space
> you'll be using
>  - the problem everyone is having is because on the autoextend. Actually
> it's conceptually wrong to use the autoextend when you have a single
> tablespace, because whenever your DB will grow, the tablespace will grow,
> but it will never get smaller, even when you delete a table or when you
run
> an optimize
>  - the optimize table issue is pretty simple. When you run optimize table,
> it simple re-create the whole table you're creating, writing all the datas
> sequentially. This gives you a certain degree of speed when you'll be
> accessing datas later, but may be a problem because at a certain moment (a
> second before the optimize finish) you'll end up having 2 copies of the
same
> table: the old one, and the new temporary one that will be renamed as the
> new one. If you are using the shared tablespace with the autoextend this
> will probably mean that your shared tablespace will GROW because the
amount
> of datas will double, and when the optimize will finish the old table will
> be deleted and all the hypothetically-free space will just sit there
waiting
> to be used. This is the key point. InnoDB doesn't free the disk space
> because it just wait for the space to be used again, because it's designed
> to be used in an environment where you preallocate the space for the db.
So
> since you preallocated it, why should you care about freeing it?
> 
> 
> WITH innodb_file_per_table:
>  - you have one (actually two) file per each InnoDB table. Each
table/index
> file will stay in the database directory (which _to me_ appears as another
> big advantage)
>  - when you add a table you get another .idb file. Whenever your table
grow,
> the idb file grows, and your filesystem space decrease
>  - the optimize process here gets interesting. When you run optimize table
> the innodb engine will start to create a NEW .idb file with a temporary
> name, using only the space it actually needs to store the datas. When the
> optimize table has ended, it will delete the old .idb file and rename the
> temporary one to the correct name. this mean that if your old table's .idb
> file had grown up to 3, 4, 5, 100 GB but you have only 100 MB of datas in
> it, the new .idb file will be 100MB while the one that will be deleted was
> 3, 4, 5, 100GB.
> 
> 
> That's it in term of space. In terms of speed or whatever else I can't say
> if there's any advantage as I haven't done any testing myself, but what I
> can assure you for sure is that, having any .idb in every directory you
can
> mount directory from different HDs or RAIDs for different DBs thus having
> better racing conditions within the same MySQL server.
> 
> Probably you could achieve the same result having more than one shared
> tablespace, but frankly I have no experience with this.
> 
> 
> Summarizing everything:
> 
>  - If you have a single DB server: use a shared InnoDB tablespace
> preallocating the space and disabling the autoextend. Using the optimize
> table will give you a better optimization of the tables, and you'll have
no
> problem with the space as it's already allocated up to a fixed size
> 
>  - If you have a machine with various tasks going on, like a mail server,
> web server, db server and whatever, use the innodb_file_per_table. Usigon
> the optimize table you'll reclaim your space back whenever you delete
> anything or whenev

Re: R: [Dbmail] Advantages of innodb_file_per_table (was: Table dbmail_messages is full)

[Peter Rabbitson]

Andrea Brancatelli wrote:




Summarizing everything:

 - If you have a single DB server: use a shared InnoDB tablespace
preallocating the space and disabling the autoextend. Using the optimize
table will give you a better optimization of the tables, and you'll have no
problem with the space as it's already allocated up to a fixed size

 - If you have a machine with various tasks going on, like a mail server,
web server, db server and whatever, use the innodb_file_per_table. Usigon
the optimize table you'll reclaim your space back whenever you delete
anything or whenever any table will significantly decrease in size.


Doubt? Question? Fear? Panic?




Excellent writeup! So basically it helps avoid juggling around 50GB+ 
files. One question though - does it make any difference in performance? 
You said that you have not done any benchmarking - did anyone else on 
the list? When one has 15GB of email, performance counts.

___
DBmail mailing list
DBmail@dbmail.org
https://mailman.fastxs.nl/mailman/listinfo/dbmail

Re: [Dbmail] Changelog

[Marc Dirix]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

No problems at my postgres server, maybe something leftover in the  
table hirarchie from before

2.2?

Marc

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (Darwin)

iD8DBQFGr5n52M1B/aDfmXsRAhlyAKCFyGZCFqZu5MrQY96EghdJVHsAvwCfQdUi
HLTqHanayqgmh5+I56pY+QQ=
=HVY0
-END PGP SIGNATURE-
___
DBmail mailing list
DBmail@dbmail.org
https://mailman.fastxs.nl/mailman/listinfo/dbmail

Re: [Dbmail] Changelog

[Paul J Stevens]

Michael Monnerie wrote:

>> btw, FTI is not an option for the headervalue field.
> 
> FTI? Whats that?

full text index.


-- 
  
  Paul Stevens  paul at nfg.nl
  NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31
  The Netherlandshttp://www.nfg.nl
___
DBmail mailing list
DBmail@dbmail.org
https://mailman.fastxs.nl/mailman/listinfo/dbmail

Re: R: [Dbmail] Advantages of innodb_file_per_table (was:

[Aaron Stone]

Great writeup. Now on the wiki at:

http://dbmail.org/dokuwiki/doku.php?id=mysql_notes

I left a space where we should include more information about configuring
InnoDB parameters for good performance. This does tend to be a FAQ, and
the bits of information we do have about it are scattered all over the
place.

Aaron


On Tue, Jul 31, 2007, Andrea Brancatelli <[EMAIL PROTECTED]> said:

> Just an addendum.
> 
> With innodb_file_per_table whenever you delete a table or a database, the
> whole .idb file gets deleted so you instantly get your space back. Maybe I
> wasn't clear enough on this in the latest lines of my mail.
> 
> -Messaggio originale-
> Da: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Per conto
> di Andrea Brancatelli
> Inviato: marted� 31 luglio 2007 17.16
> A: 'DBMail mailinglist'
> Oggetto: R: [Dbmail] Advantages of innodb_file_per_table (was:
> Tabledbmail_messages is full)
> 
> I partially explained in my last email.
> 
> Let me try to summarize everything. 
> 
> WITHOUT innodb_file_per_table:
>  - you have one shared tablespace for all the tables. This gives you the
> advantage of limiting the space your db will be using (unless you activate
> the autoextend) but give you the disadvantage of preallocating all the space
> you'll be using
>  - the problem everyone is having is because on the autoextend. Actually
> it's conceptually wrong to use the autoextend when you have a single
> tablespace, because whenever your DB will grow, the tablespace will grow,
> but it will never get smaller, even when you delete a table or when you run
> an optimize
>  - the optimize table issue is pretty simple. When you run optimize table,
> it simple re-create the whole table you're creating, writing all the datas
> sequentially. This gives you a certain degree of speed when you'll be
> accessing datas later, but may be a problem because at a certain moment (a
> second before the optimize finish) you'll end up having 2 copies of the same
> table: the old one, and the new temporary one that will be renamed as the
> new one. If you are using the shared tablespace with the autoextend this
> will probably mean that your shared tablespace will GROW because the amount
> of datas will double, and when the optimize will finish the old table will
> be deleted and all the hypothetically-free space will just sit there waiting
> to be used. This is the key point. InnoDB doesn't free the disk space
> because it just wait for the space to be used again, because it's designed
> to be used in an environment where you preallocate the space for the db. So
> since you preallocated it, why should you care about freeing it?
> 
> 
> WITH innodb_file_per_table:
>  - you have one (actually two) file per each InnoDB table. Each table/index
> file will stay in the database directory (which _to me_ appears as another
> big advantage)
>  - when you add a table you get another .idb file. Whenever your table grow,
> the idb file grows, and your filesystem space decrease
>  - the optimize process here gets interesting. When you run optimize table
> the innodb engine will start to create a NEW .idb file with a temporary
> name, using only the space it actually needs to store the datas. When the
> optimize table has ended, it will delete the old .idb file and rename the
> temporary one to the correct name. this mean that if your old table's .idb
> file had grown up to 3, 4, 5, 100 GB but you have only 100 MB of datas in
> it, the new .idb file will be 100MB while the one that will be deleted was
> 3, 4, 5, 100GB.
> 
> 
> That's it in term of space. In terms of speed or whatever else I can't say
> if there's any advantage as I haven't done any testing myself, but what I
> can assure you for sure is that, having any .idb in every directory you can
> mount directory from different HDs or RAIDs for different DBs thus having
> better racing conditions within the same MySQL server.
> 
> Probably you could achieve the same result having more than one shared
> tablespace, but frankly I have no experience with this.
> 
> 
> Summarizing everything:
> 
>  - If you have a single DB server: use a shared InnoDB tablespace
> preallocating the space and disabling the autoextend. Using the optimize
> table will give you a better optimization of the tables, and you'll have no
> problem with the space as it's already allocated up to a fixed size
> 
>  - If you have a machine with various tasks going on, like a mail server,
> web server, db server and whatever, use the innodb_file_per_table. Usigon
> the optimize table you'll reclaim your space back whenever you delete
> anything or whenever any table will significantly decrease in size.
> 
> 
> Doubt? Question? Fear? Panic?
> 
> 
> -Messaggio originale-
> Da: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Per conto
> di Peter Rabbitson
> Inviato: marted� 31 luglio 2007 16.52
> A: DBMail mailinglist
> Oggetto: [Dbmail] Advantages of innodb_file_per_table (was: Table
> dbmail_messages is full)
>

Re: [Dbmail] Table dbmail_messages is full

[Aaron Stone]

Marc was likely referring to a disk quota applied to the 'mysql' user who
probably owns all MySQL data on your system. If it were a DBMail quota,
you would have seen mail logs stating that a message was rejected for a
user being over quota, not MySQL errors indicating something horribly
wrong.

Are you sure you are prepared to build an email system for 250 million
accounts? This is some pretty important, and basic, system administration
information that you need to be aware of.

Aaron

On Tue, Jul 31, 2007, Sascha Braun <[EMAIL PROTECTED]> said:

> No, the accounts which where recieving the mails, where not
> quoting. There must be another cause.
> 
> Am Dienstag, den 31.07.2007, 11:28 +0200 schrieb Marc Dirix:
>> quota?
>> 
>> 


___
DBmail mailing list
DBmail@dbmail.org
https://mailman.fastxs.nl/mailman/listinfo/dbmail

Re: [Dbmail] Changelog

[Michael Monnerie]

On Dienstag, 31. Juli 2007 Paul J Stevens wrote:
> > # CREATE INDEX dbmail_headervalue_3 ON
> > dbmail_headervalue(headervalue); FEHLER:  Indexzeile benötigt 26104
> > Bytes, Maximalgröße ist 8191
> >
> > Anybody got an idea what to do now?
>
> Nothing? In mysql you can do a index on the first x characters of a
> field. I'm sure something similar is possible in pgsql, but I haven't
> had time to figure it out yet. For now, just comment the line
> involved.

Other way round: What if I had that index, and got an entry that big? 
Crash? Doesn't insert, DB error? Sounds like something should be done 
there.

Yes, it's possible to define an index on substring, I believe. I just 
wanted to outline this, as it can be a problem when you have that index 
and try to insert a big field later.

> btw, FTI is not an option for the headervalue field.

FTI? Whats that?

mfg zmi
-- 
// Michael Monnerie, Ing.BSc-  http://it-management.at
// Tel: 0676/846 914 666  .network.your.ideas.
// PGP Key: "curl -s http://zmi.at/zmi.asc | gpg --import"
// Fingerprint: EA39 8918 EDFF 0A68 ACFB  11B7 BA2D 060F 1C6F E6B0
// Keyserver: www.keyserver.net   Key-ID: 1C6FE6B0


signature.asc
Description: This is a digitally signed message part.
___
DBmail mailing list
DBmail@dbmail.org
https://mailman.fastxs.nl/mailman/listinfo/dbmail

Re: [Dbmail] Changelog

[Paul J Stevens]

Michael Monnerie wrote:
> On Dienstag, 31. Juli 2007 Paul J Stevens wrote:
>> They were posted on the list. Also you can pickup the change:
>>
> http://nfg3.nfgs.net/cgi-bin/gitweb.cgi?p=dbmail.git;a=commitdiff;h=8ae82ff426114dc2fc648273a40f053d0cc6e8bc
> 
> I've tried to create the missing indices, but one is not possible:
> # CREATE INDEX dbmail_headervalue_3 ON dbmail_headervalue(headervalue);
> FEHLER:  Indexzeile benötigt 26104 Bytes, Maximalgröße ist 8191
> 
> Anybody got an idea what to do now?

Nothing? In mysql you can do a index on the first x characters of a
field. I'm sure something similar is possible in pgsql, but I haven't
had time to figure it out yet. For now, just comment the line involved.

btw, FTI is not an option for the headervalue field.


-- 
  
  Paul Stevens  paul at nfg.nl
  NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31
  The Netherlandshttp://www.nfg.nl
___
DBmail mailing list
DBmail@dbmail.org
https://mailman.fastxs.nl/mailman/listinfo/dbmail

Re: [Dbmail] Really offtopic question :P

[[EMAIL PROTECTED]]

Jorge Bastos wrote:

Guys, don't kill me, but if want to only do it after answer me :P
 
Beside MSOutlook, does anyone know another email client with MAPI support?
 
Jorge



___
DBmail mailing list
DBmail@dbmail.org
https://mailman.fastxs.nl/mailman/listinfo/dbmail
  

cc:Mail:P

___
DBmail mailing list
DBmail@dbmail.org
https://mailman.fastxs.nl/mailman/listinfo/dbmail

R: [Dbmail] Advantages of innodb_file_per_table (was: Tabledbmail_messages is full)

[Andrea Brancatelli]

Just an addendum.

With innodb_file_per_table whenever you delete a table or a database, the
whole .idb file gets deleted so you instantly get your space back. Maybe I
wasn't clear enough on this in the latest lines of my mail.

-Messaggio originale-
Da: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Per conto
di Andrea Brancatelli
Inviato: martedì 31 luglio 2007 17.16
A: 'DBMail mailinglist'
Oggetto: R: [Dbmail] Advantages of innodb_file_per_table (was:
Tabledbmail_messages is full)

I partially explained in my last email.

Let me try to summarize everything. 

WITHOUT innodb_file_per_table:
 - you have one shared tablespace for all the tables. This gives you the
advantage of limiting the space your db will be using (unless you activate
the autoextend) but give you the disadvantage of preallocating all the space
you'll be using
 - the problem everyone is having is because on the autoextend. Actually
it's conceptually wrong to use the autoextend when you have a single
tablespace, because whenever your DB will grow, the tablespace will grow,
but it will never get smaller, even when you delete a table or when you run
an optimize
 - the optimize table issue is pretty simple. When you run optimize table,
it simple re-create the whole table you're creating, writing all the datas
sequentially. This gives you a certain degree of speed when you'll be
accessing datas later, but may be a problem because at a certain moment (a
second before the optimize finish) you'll end up having 2 copies of the same
table: the old one, and the new temporary one that will be renamed as the
new one. If you are using the shared tablespace with the autoextend this
will probably mean that your shared tablespace will GROW because the amount
of datas will double, and when the optimize will finish the old table will
be deleted and all the hypothetically-free space will just sit there waiting
to be used. This is the key point. InnoDB doesn't free the disk space
because it just wait for the space to be used again, because it's designed
to be used in an environment where you preallocate the space for the db. So
since you preallocated it, why should you care about freeing it?


WITH innodb_file_per_table:
 - you have one (actually two) file per each InnoDB table. Each table/index
file will stay in the database directory (which _to me_ appears as another
big advantage)
 - when you add a table you get another .idb file. Whenever your table grow,
the idb file grows, and your filesystem space decrease
 - the optimize process here gets interesting. When you run optimize table
the innodb engine will start to create a NEW .idb file with a temporary
name, using only the space it actually needs to store the datas. When the
optimize table has ended, it will delete the old .idb file and rename the
temporary one to the correct name. this mean that if your old table's .idb
file had grown up to 3, 4, 5, 100 GB but you have only 100 MB of datas in
it, the new .idb file will be 100MB while the one that will be deleted was
3, 4, 5, 100GB.


That's it in term of space. In terms of speed or whatever else I can't say
if there's any advantage as I haven't done any testing myself, but what I
can assure you for sure is that, having any .idb in every directory you can
mount directory from different HDs or RAIDs for different DBs thus having
better racing conditions within the same MySQL server.

Probably you could achieve the same result having more than one shared
tablespace, but frankly I have no experience with this.


Summarizing everything:

 - If you have a single DB server: use a shared InnoDB tablespace
preallocating the space and disabling the autoextend. Using the optimize
table will give you a better optimization of the tables, and you'll have no
problem with the space as it's already allocated up to a fixed size

 - If you have a machine with various tasks going on, like a mail server,
web server, db server and whatever, use the innodb_file_per_table. Usigon
the optimize table you'll reclaim your space back whenever you delete
anything or whenever any table will significantly decrease in size.


Doubt? Question? Fear? Panic?


-Messaggio originale-
Da: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Per conto
di Peter Rabbitson
Inviato: martedì 31 luglio 2007 16.52
A: DBMail mailinglist
Oggetto: [Dbmail] Advantages of innodb_file_per_table (was: Table
dbmail_messages is full)

Hi,
Sorry for hijacking the thread. Can someone clarify what is the 
advantage of using innodb_file_per_table versus one infinitely growing 
tablespace?

Thanks

Peter
___
DBmail mailing list
DBmail@dbmail.org
https://mailman.fastxs.nl/mailman/listinfo/dbmail

___
DBmail mailing list
DBmail@dbmail.org
https://mailman.fastxs.nl/mailman/listinfo/dbmail


___
DBmail mailing list
DBmail@dbmail.org
https://mailman.fastxs.nl/mailman/listinfo/dbmail

R: [Dbmail] Advantages of innodb_file_per_table (was: Table dbmail_messages is full)

[Andrea Brancatelli]

I partially explained in my last email.

Let me try to summarize everything. 

WITHOUT innodb_file_per_table:
 - you have one shared tablespace for all the tables. This gives you the
advantage of limiting the space your db will be using (unless you activate
the autoextend) but give you the disadvantage of preallocating all the space
you'll be using
 - the problem everyone is having is because on the autoextend. Actually
it's conceptually wrong to use the autoextend when you have a single
tablespace, because whenever your DB will grow, the tablespace will grow,
but it will never get smaller, even when you delete a table or when you run
an optimize
 - the optimize table issue is pretty simple. When you run optimize table,
it simple re-create the whole table you're creating, writing all the datas
sequentially. This gives you a certain degree of speed when you'll be
accessing datas later, but may be a problem because at a certain moment (a
second before the optimize finish) you'll end up having 2 copies of the same
table: the old one, and the new temporary one that will be renamed as the
new one. If you are using the shared tablespace with the autoextend this
will probably mean that your shared tablespace will GROW because the amount
of datas will double, and when the optimize will finish the old table will
be deleted and all the hypothetically-free space will just sit there waiting
to be used. This is the key point. InnoDB doesn't free the disk space
because it just wait for the space to be used again, because it's designed
to be used in an environment where you preallocate the space for the db. So
since you preallocated it, why should you care about freeing it?


WITH innodb_file_per_table:
 - you have one (actually two) file per each InnoDB table. Each table/index
file will stay in the database directory (which _to me_ appears as another
big advantage)
 - when you add a table you get another .idb file. Whenever your table grow,
the idb file grows, and your filesystem space decrease
 - the optimize process here gets interesting. When you run optimize table
the innodb engine will start to create a NEW .idb file with a temporary
name, using only the space it actually needs to store the datas. When the
optimize table has ended, it will delete the old .idb file and rename the
temporary one to the correct name. this mean that if your old table's .idb
file had grown up to 3, 4, 5, 100 GB but you have only 100 MB of datas in
it, the new .idb file will be 100MB while the one that will be deleted was
3, 4, 5, 100GB.


That's it in term of space. In terms of speed or whatever else I can't say
if there's any advantage as I haven't done any testing myself, but what I
can assure you for sure is that, having any .idb in every directory you can
mount directory from different HDs or RAIDs for different DBs thus having
better racing conditions within the same MySQL server.

Probably you could achieve the same result having more than one shared
tablespace, but frankly I have no experience with this.


Summarizing everything:

 - If you have a single DB server: use a shared InnoDB tablespace
preallocating the space and disabling the autoextend. Using the optimize
table will give you a better optimization of the tables, and you'll have no
problem with the space as it's already allocated up to a fixed size

 - If you have a machine with various tasks going on, like a mail server,
web server, db server and whatever, use the innodb_file_per_table. Usigon
the optimize table you'll reclaim your space back whenever you delete
anything or whenever any table will significantly decrease in size.


Doubt? Question? Fear? Panic?


-Messaggio originale-
Da: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Per conto
di Peter Rabbitson
Inviato: martedì 31 luglio 2007 16.52
A: DBMail mailinglist
Oggetto: [Dbmail] Advantages of innodb_file_per_table (was: Table
dbmail_messages is full)

Hi,
Sorry for hijacking the thread. Can someone clarify what is the 
advantage of using innodb_file_per_table versus one infinitely growing 
tablespace?

Thanks

Peter
___
DBmail mailing list
DBmail@dbmail.org
https://mailman.fastxs.nl/mailman/listinfo/dbmail

___
DBmail mailing list
DBmail@dbmail.org
https://mailman.fastxs.nl/mailman/listinfo/dbmail

[Dbmail] Advantages of innodb_file_per_table (was: Table dbmail_messages is full)

[Peter Rabbitson]

Hi,
Sorry for hijacking the thread. Can someone clarify what is the 
advantage of using innodb_file_per_table versus one infinitely growing 
tablespace?


Thanks

Peter
___
DBmail mailing list
DBmail@dbmail.org
https://mailman.fastxs.nl/mailman/listinfo/dbmail

R: [Dbmail] Changelog

[Andrea Brancatelli]

First of all I'd install an english copy of pgsql :-)

Eheh sorry just joking but I couldn't resist... :-

-Messaggio originale-
Da: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Per conto
di Michael Monnerie
Inviato: martedì 31 luglio 2007 16.30
A: DBMail mailinglist
Oggetto: Re: [Dbmail] Changelog

On Dienstag, 31. Juli 2007 Paul J Stevens wrote:
> They were posted on the list. Also you can pickup the change:
> 
http://nfg3.nfgs.net/cgi-bin/gitweb.cgi?p=dbmail.git;a=commitdiff;h=8ae82ff4
26114dc2fc648273a40f053d0cc6e8bc

I've tried to create the missing indices, but one is not possible:
# CREATE INDEX dbmail_headervalue_3 ON dbmail_headervalue(headervalue);
FEHLER:  Indexzeile benötigt 26104 Bytes, Maximalgröße ist 8191

Anybody got an idea what to do now?

mfg zmi
-- 
// Michael Monnerie, Ing.BSc-  http://it-management.at
// Tel: 0676/846 914 666  .network.your.ideas.
// PGP Key: "curl -s http://zmi.at/zmi.asc | gpg --import"
// Fingerprint: EA39 8918 EDFF 0A68 ACFB  11B7 BA2D 060F 1C6F E6B0
// Keyserver: www.keyserver.net   Key-ID: 1C6FE6B0

___
DBmail mailing list
DBmail@dbmail.org
https://mailman.fastxs.nl/mailman/listinfo/dbmail

Re: [Dbmail] Changelog

[Michael Monnerie]

On Dienstag, 31. Juli 2007 Paul J Stevens wrote:
> They were posted on the list. Also you can pickup the change:
> 
http://nfg3.nfgs.net/cgi-bin/gitweb.cgi?p=dbmail.git;a=commitdiff;h=8ae82ff426114dc2fc648273a40f053d0cc6e8bc

I've tried to create the missing indices, but one is not possible:
# CREATE INDEX dbmail_headervalue_3 ON dbmail_headervalue(headervalue);
FEHLER:  Indexzeile benötigt 26104 Bytes, Maximalgröße ist 8191

Anybody got an idea what to do now?

mfg zmi
-- 
// Michael Monnerie, Ing.BSc-  http://it-management.at
// Tel: 0676/846 914 666  .network.your.ideas.
// PGP Key: "curl -s http://zmi.at/zmi.asc | gpg --import"
// Fingerprint: EA39 8918 EDFF 0A68 ACFB  11B7 BA2D 060F 1C6F E6B0
// Keyserver: www.keyserver.net   Key-ID: 1C6FE6B0


signature.asc
Description: This is a digitally signed message part.
___
DBmail mailing list
DBmail@dbmail.org
https://mailman.fastxs.nl/mailman/listinfo/dbmail

R: R: [Dbmail] Table dbmail_messages is full

[Andrea Brancatelli]

This is false. 

 

When using innodb_file_per_table “optimize table ” gets mapped to
“alter table  type=InnoDB” and the later command will issue a create
from select that will result in a totally clean table, optimized and will
free al the unused space. Try it by yourself, I can assure you it works: I
just shrinked a 3GB .idb file to 500MB with this trick.

 

Furthermore, in the unlucky case you didn’t use the innodb_file_per_table at
first (you unlucky!) you can enable it and then later issue an alter table
 type=InnoDB. It will result in a new .idb file with just that table
inside. From that moment on the optimize table trick will perfectly work.
Later on when you’ll have done the alter table on every table to take them
all out of the single innodb tablespace/file (which won’t decrease when
tables will be getting out of it), you can just trash it and manually
reclaim all your disk space.

 

>From http://dev.mysql.com/doc/refman/5.0/en/optimize-table.html :

 

For InnoDB tables, OPTIMIZE TABLE is mapped to ALTER TABLE, which rebuilds
the table to update index statistics and free unused space in the clustered
index.

 

See also: http://dev.mysql.com/doc/refman/5.1/en/multiple-tablespaces.html

 

  _  

Da: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Per conto
di Curtis Maurand
Inviato: martedì 31 luglio 2007 15.29
A: DBMail mailinglist
Oggetto: Re: R: [Dbmail] Table dbmail_messages is full

 


mysqloptimize against an innodb table will not reclaim disk space.  if
anything, you're innodb file will grow.  In fact it can end up twice as
large as when you started.  its one of the drawbacks of innodb tables.

if you want to reclaim diskspace change the table type to myisam, then run
mysqloptimize against the innodb table then alter the table back to innodb.

Curtis

Andrea Brancatelli wrote:
> I strongly suggest you to use the innodb_file_per_table and to run an
> optimize table dbmail_messages (and not only, also the others) from time
> to
> time to free some disk space.
> 
> ciaociao
> 
> -Messaggio originale-
> Da: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Per conto
> di Sascha Braun
> Inviato: martedì 31 luglio 2007 15.10
> A: DBMail mailinglist
> Oggetto: Re: [Dbmail] Table dbmail_messages is full
> 
> Is that the value you where asking for?
> 
> innodb_data_file_path = ibdata1:10M:autoextend:max:128M
> 
> I am now changing the max value, I hope i recognized everything
> correctly.
> 
> Best Regards,
> 
> Sascha Braun
> 
> Am Dienstag, den 31.07.2007, 16:30 +0400 schrieb alexander benaguev:
>> give us "my.cnf", please
>>
>> alexander
>> ___
>> DBmail mailing list
>> DBmail@dbmail.org
>> https://mailman.fastxs.nl/mailman/listinfo/dbmail
> 
> ___
> DBmail mailing list
> DBmail@dbmail.org
> https://mailman.fastxs.nl/mailman/listinfo/dbmail
> 
> ___
> DBmail mailing list
> DBmail@dbmail.org
> https://mailman.fastxs.nl/mailman/listinfo/dbmail
> 


-- 
Curtis Maurand
Head Honcho
Xyonet Hosting Services
Biddeford, ME 04005
mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]

___
DBmail mailing list
DBmail@dbmail.org
https://mailman.fastxs.nl/mailman/listinfo/dbmail

Re: R: [Dbmail] Table dbmail_messages is full

[Curtis Maurand]

mysqloptimize against an innodb table will not reclaim disk
space.  if anything, you're innodb file will grow.  In fact it
can end up twice as large as when you started.  its one of the
drawbacks of innodb tables.

if you want to reclaim diskspace
change the table type to myisam, then run mysqloptimize against the innodb
table then alter the table back to innodb.

Curtis

Andrea Brancatelli wrote:
> I strongly suggest you to use the
innodb_file_per_table and to run an
> optimize table
dbmail_messages (and not only, also the others) from time
> to
> time to free some disk space.
> 
> ciaociao
> 
> -Messaggio originale-
> Da:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Per conto
> di Sascha Braun
> Inviato: martedì 31 luglio 2007
15.10
> A: DBMail mailinglist
> Oggetto: Re: [Dbmail]
Table dbmail_messages is full
> 
> Is that the value you
where asking for?
> 
> innodb_data_file_path =
ibdata1:10M:autoextend:max:128M
> 
> I am now changing the
max value, I hope i recognized everything
> correctly.
>

> Best Regards,
> 
> Sascha Braun
> 
> Am Dienstag, den 31.07.2007, 16:30 +0400 schrieb alexander
benaguev:
>> give us "my.cnf", please
>>
>> alexander
>>
___
>> DBmail
mailing list
>> DBmail@dbmail.org
>>
https://mailman.fastxs.nl/mailman/listinfo/dbmail
> 
>
___
> DBmail mailing
list
> DBmail@dbmail.org
>
https://mailman.fastxs.nl/mailman/listinfo/dbmail
> 
>
___
> DBmail mailing
list
> DBmail@dbmail.org
>
https://mailman.fastxs.nl/mailman/listinfo/dbmail
> 


-- 
Curtis Maurand
Head Honcho
Xyonet Hosting
Services
Biddeford, ME 04005
mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
___
DBmail mailing list
DBmail@dbmail.org
https://mailman.fastxs.nl/mailman/listinfo/dbmail

Re: [Dbmail] Table dbmail_messages is full

[alexander benaguev]

Sascha Braun wrote:

Yes! You did it! Thank you very much.


you are welcome=)
___
DBmail mailing list
DBmail@dbmail.org
https://mailman.fastxs.nl/mailman/listinfo/dbmail

R: [Dbmail] Table dbmail_messages is full

[Andrea Brancatelli]

I strongly suggest you to use the innodb_file_per_table and to run an
optimize table dbmail_messages (and not only, also the others) from time to
time to free some disk space.

ciaociao

-Messaggio originale-
Da: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Per conto
di Sascha Braun
Inviato: martedì 31 luglio 2007 15.10
A: DBMail mailinglist
Oggetto: Re: [Dbmail] Table dbmail_messages is full

Is that the value you where asking for?

innodb_data_file_path = ibdata1:10M:autoextend:max:128M

I am now changing the max value, I hope i recognized everything
correctly.

Best Regards,

Sascha Braun

Am Dienstag, den 31.07.2007, 16:30 +0400 schrieb alexander benaguev:
> give us "my.cnf", please
> 
> alexander
> ___
> DBmail mailing list
> DBmail@dbmail.org
> https://mailman.fastxs.nl/mailman/listinfo/dbmail

___
DBmail mailing list
DBmail@dbmail.org
https://mailman.fastxs.nl/mailman/listinfo/dbmail

___
DBmail mailing list
DBmail@dbmail.org
https://mailman.fastxs.nl/mailman/listinfo/dbmail

Re: [Dbmail] Table dbmail_messages is full

[Sascha Braun]

Yes! You did it! Thank you very much. I simply had to change the table
restriction on;

innodb_data_file_path = ibdata1:10M:autoextend:max:128M

to 

innodb_data_file_path = ibdata1:10M:autoextend:max:6192M

Not the dbmail_messages table can grow up to six gigabyte.

Wow, thats perfect :))

*handshaking* and *smiling*

Am Dienstag, den 31.07.2007, 16:30 +0400 schrieb alexander benaguev:
> give us "my.cnf", please
> 
> alexander
> ___
> DBmail mailing list
> DBmail@dbmail.org
> https://mailman.fastxs.nl/mailman/listinfo/dbmail

___
DBmail mailing list
DBmail@dbmail.org
https://mailman.fastxs.nl/mailman/listinfo/dbmail

Re: [Dbmail] difference between 'messagesize' and 'rfcsize' in table 'dbmail_physmessage'

[Paul J Stevens]

umask wrote:
> Hi,
> 
> Where difference between fields 'messagesize' and 'rfcsize' in table 
> 'dbmail_physmessage'?

The rfcsize is guaranteed to represent the message size after it's fully
converted to \r\n line-endings. The messagesize is the message's size
with \n lineendings.

-- 
  
  Paul Stevens  paul at nfg.nl
  NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31
  The Netherlandshttp://www.nfg.nl
___
DBmail mailing list
DBmail@dbmail.org
https://mailman.fastxs.nl/mailman/listinfo/dbmail

Re: [Dbmail] Table dbmail_messages is full

[Sascha Braun]

Is that the value you where asking for?

innodb_data_file_path = ibdata1:10M:autoextend:max:128M

I am now changing the max value, I hope i recognized everything
correctly.

Best Regards,

Sascha Braun

Am Dienstag, den 31.07.2007, 16:30 +0400 schrieb alexander benaguev:
> give us "my.cnf", please
> 
> alexander
> ___
> DBmail mailing list
> DBmail@dbmail.org
> https://mailman.fastxs.nl/mailman/listinfo/dbmail

___
DBmail mailing list
DBmail@dbmail.org
https://mailman.fastxs.nl/mailman/listinfo/dbmail

Re: [Dbmail] Changelog

[Paul J Stevens]

Jorge,

They were posted on the list. Also you can pickup the change:

http://nfg3.nfgs.net/cgi-bin/gitweb.cgi?p=dbmail.git;a=commitdiff;h=8ae82ff426114dc2fc648273a40f053d0cc6e8bc


Jorge Bastos wrote:
> Paul,
> For the changelog:
>  
> 2007-07-26  Paul J Stevens <[EMAIL PROTECTED] >
>  
> * sql/mysql/create_tables.mysql, sql/postgresql/create_tables.pgsql,
> sql/sqlite/create_tables.sqlite:
> add missing indexes
>  
>  
> How can i know wich indexes were added? could you posto this in separated?
>  
>  
> Jorge
> 
> 
> 
> 
> ___
> DBmail mailing list
> DBmail@dbmail.org
> https://mailman.fastxs.nl/mailman/listinfo/dbmail


-- 
  
  Paul Stevens  paul at nfg.nl
  NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31
  The Netherlandshttp://www.nfg.nl
___
DBmail mailing list
DBmail@dbmail.org
https://mailman.fastxs.nl/mailman/listinfo/dbmail

Re: [Dbmail] Table dbmail_messages is full

[alexander benaguev]

give us "my.cnf", please

alexander
___
DBmail mailing list
DBmail@dbmail.org
https://mailman.fastxs.nl/mailman/listinfo/dbmail

Re: [Dbmail] Table dbmail_messages is full

[Sascha Braun]

No, the accounts which where recieving the mails, where not
quoting. There must be another cause.

Am Dienstag, den 31.07.2007, 11:28 +0200 schrieb Marc Dirix:
> quota?
> 
> 
> ___
> DBmail mailing list
> DBmail@dbmail.org
> https://mailman.fastxs.nl/mailman/listinfo/dbmail

___
DBmail mailing list
DBmail@dbmail.org
https://mailman.fastxs.nl/mailman/listinfo/dbmail

Re: [Dbmail] Table dbmail_messages is full

[Marc Dirix]

quota?


___
DBmail mailing list
DBmail@dbmail.org
https://mailman.fastxs.nl/mailman/listinfo/dbmail

Re: [Dbmail] global sieve rules (for all users)

[Aaron Stone]

On Tue, 2007-07-31 at 10:33 +0200, Michael Monnerie wrote:
> On Dienstag, 31. Juli 2007 zamri wrote:
> > It makes sense that global sieve rules have top priority over
> > user-defined rules.
> 
> But it could also be defined that the global rules act as a default 
> which can be overruled by user rules. It depends on the site policy (or 
> better: per domain policy).

And certain behaviors will be very different. A fundamental question is,
"What happens to the implicit keep?" Let's say the administrator's
script does a 'fileinto' - is the keep canceled and the user's script
skipped? If not, how does 'fileinto' differ from 'fileinto :copy'?

What about discard? If the administrator discards a message, is that
absolutely final, no chance for the user's script to see it?

There may or may not be obvious answers to these and other questions.
It's mostly a matter of defining some standard and consistent behavior.

Aaron

___
DBmail mailing list
DBmail@dbmail.org
https://mailman.fastxs.nl/mailman/listinfo/dbmail

[Dbmail] Table dbmail_messages is full

[Sascha Braun]

Hi People,

I am still in the development phase of a hole bunch
of projects. As I love to use DBMail as IMAP Service
I spend lots of time on the development, of a nice
webfrontend.

But now, during my tests, with attachments. I allways
did send 1 MB large test emails. The Database grew to
round about 140 MB now DBMail DBMA simply says the
dbmail_messages table is full and does not transport
mails anymore to anywhere.

How can that be? I want to build a mail server system
which will be able to at least host 250 Million Mail
Accounts.

So it has to be possible to work with large amounts of
email accounts as well as lots of kilobytes in single
mails.

Please help me. My Development Server still has 7 GB
storage free for storing mysql databases.

Thank you very much!

Sascha

___
DBmail mailing list
DBmail@dbmail.org
https://mailman.fastxs.nl/mailman/listinfo/dbmail

Re: [Dbmail] global sieve rules (for all users)

[Michael Monnerie]

On Dienstag, 31. Juli 2007 zamri wrote:
> It makes sense that global sieve rules have top priority over
> user-defined rules.

But it could also be defined that the global rules act as a default 
which can be overruled by user rules. It depends on the site policy (or 
better: per domain policy).

mfg zmi
-- 
// Michael Monnerie, Ing.BSc-  http://it-management.at
// Tel: 0676/846 914 666  .network.your.ideas.
// PGP Key: "curl -s http://zmi.at/zmi.asc | gpg --import"
// Fingerprint: EA39 8918 EDFF 0A68 ACFB  11B7 BA2D 060F 1C6F E6B0
// Keyserver: www.keyserver.net   Key-ID: 1C6FE6B0


signature.asc
Description: This is a digitally signed message part.
___
DBmail mailing list
DBmail@dbmail.org
https://mailman.fastxs.nl/mailman/listinfo/dbmail

Re: [Dbmail] global sieve rules (for all users)

[zamri]

On 7/31/07, Aaron Stone <[EMAIL PROTECTED]> wrote:
>
> On Mon, Jul 30, 2007, alexander benaguev <[EMAIL PROTECTED]> said:
>
> > umask wrote:
> >> May be Alexander Benaguev have examples of use cases.
> > I don't  have examples, just logic: users can manage they scripts by
> > connecting to timsieved (it's part of dbmail), or they can do this from
> > shell by dbmail-sievecmd. 'cose second case is unlikely, you should
> > shutdown timsieved;)
>
> Users should NEVER have access to dbmail-* commands. ALL of the commands
> potentially give access to ALL user data. They are designed to be run on
> closed servers where none of the users have shell access, or have limited
> shell access. That's why they're in /usr/sbin!
>
> You might write some wrappers around the commands and allow them to be
> called from management scripts, but be damned sure to check that you have
> a -u option, that the value is of the user issuing the command, and that
> you escape the arguments fully (as with all shell commands).
>
> As for sieve script permissions, there might be some interesting use cases
> for restricting user access to edit scripts, and I think it might fit in
> nicely with ideas for system scripts, group/client scripts, system-owned
> user scripts, etc. Let's work out some of the ideas on a wiki page:
> http://dbmail.org/dokuwiki/doku.php?id=sieve
>
> Aaron
> ___
> DBmail mailing list
> DBmail@dbmail.org
> https://mailman.fastxs.nl/mailman/listinfo/dbmail
>

It makes sense that global sieve rules have top priority over user-defined
rules.

-- 
zamri
Linux System Administrator
Kolej ShahPutra Kuantan
Pahang Malaysia
Tel : 609.573.777.7 ext 119
web : http://muhdzamri.blogspot.com
___
DBmail mailing list
DBmail@dbmail.org
https://mailman.fastxs.nl/mailman/listinfo/dbmail

[Dbmail] difference between 'messagesize' and 'rfcsize' in table 'dbmail_physmessage'

[umask]

Hi,

Where difference between fields 'messagesize' and 'rfcsize' in table 
'dbmail_physmessage'?

--
Ilyas
___
DBmail mailing list
DBmail@dbmail.org
https://mailman.fastxs.nl/mailman/listinfo/dbmail