On Apr 29, 2010, at 10:35 PM, troxlinux wrote: > > 2010/4/29 Jernej Porenta <jernej.pore...@arnes.si>: >> >> If your server has plenty of space, that does not mean that your database >> has plenty of space. Check your database! > > if I have sufficient space, that way it is not the problem
you should check your innodb settings to be sure you have enough space for DB. >> >> $timestamp_fmt_mysql should be 1 only if you set msgs.time_iso field to >> TIMESTAMP. But sql schema you've sent, does NOT have it, so don't change it, >> unless you are going to change the schema. Read the documentation again... > > ok but in my new schema i have this : > > CREATE TABLE msgs ( > partition_tag integer DEFAULT 0, -- see $sql_partition_tag > mail_id varbinary(12) NOT NULL PRIMARY KEY, -- long-term unique mail id > secret_id varbinary(12) DEFAULT '', -- authorizes release of mail_id > am_id varchar(20) NOT NULL, -- id used in the log > time_num integer unsigned NOT NULL, -- rx_time: seconds since Unix epoch > time_iso char(16) NOT NULL, -- rx_time: ISO8601 UTC ascii time > sid bigint unsigned NOT NULL, -- sender: maddr.id > policy varchar(255) DEFAULT '', -- policy bank path (like macro %p) > client_addr varchar(255) DEFAULT '', -- SMTP client IP address (IPv4 or v6) > size integer unsigned NOT NULL, -- message size in bytes > content binary(1), If you would read the documentation carefully, you would read this (from Readme.sql.mysql): Instead of declaring a time_iso field in table msgs as a string: time_iso char(16) NOT NULL, one may want to declare is as: time_iso TIMESTAMP NOT NULL DEFAULT 0, in which case $timestamp_fmt_mysql *MUST* be set to 1 in amavisd.conf to avoid MySQL inability to accept ISO 8601 timestamps with zone Z and ISO date/time delimiter T; failing to set $timestamp_fmt_mysql makes MySQL store zero time on INSERT and write current local time on UPDATE if auto-update is allowed, which is different from the intended mail timestamp (localtime vs. UTC, off by seconds) >> >> If you have deleted the database, then you will be probably be just fine for >> a while, but after a while, you will run out of space in your database and >> the same thing will happen again. You should monitor your database usage >> (especially Innodb_pool) more often... > > if it creates new db because I must provide a fast solution, I am not > appropriate it, but for that reason I am reviewing docu. > > when you talk about (especially Innodb_pool) ? is this > > what I do not understand that is what db determines the space of my db? > In InnoDB space you should check variables like innodb_data_file_path and innodb_data_home_dir. You should have something like this in your configs innodb_data_file_path = ibdata1:2000M;ibdata2:2000M;ibdata3:100M:autoextend:max:2000M Please read the documentation before setting such complex things. LP, Jernej ------------------------------------------------------------------------------ _______________________________________________ AMaViS-user mailing list AMaViS-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amavis-user AMaViS-FAQ:http://www.amavis.org/amavis-faq.php3 AMaViS-HowTos:http://www.amavis.org/howto/
