[rt-users] Upgrade from 3.6.3 to 3.8.4 - image attachments missing/corrupt

[Justin Hayes]

I didn't mean the whole attachments table. Putting that in the  
filesystem would be crazy. I was more talking about files you manually  
attach (word docs, images etc). These tend to me more throwaway for me  
than the text of the replies/comments themselves, and we don't have  
anywhere near as many.... They could just live in the filesystem in  
neat subdirectories and be retrieved when someone actually clicks on  
one to look at. Backup would be easy - just rsync/tar/other option of  
your choice.

But as long as mysql can handle the large DB sizes then I guess it's  
fine where it is :D

Justin

On 17 Sep 2009, at 00:33, Aaron Guise wrote:

> I fully agree Tom,  SQL Servers totally own the filesystem  
> equivalent in this regard.  Our attachments table is huge and it  
> would be rather difficult to keep a track of them all and ensure  
> every last one is backed up without the MySQL storage system :-)
>
> Regards,
> Aaron Guise
>   07 838 7793
> 027 212 6638
> aaron at guise.net.nz
>
>
>
>
> On Thu, Sep 17, 2009 at 11:00 AM, Tom Lahti <toml at bitstatement.net>  
> wrote:
> Justin Hayes wrote:
> > Thanks Aaron. I've always wondered why file attachments are stored  
> in
> > the db at all. I'd have thought those would have been better  
> placed out
> > in the filesystem.
>
> Egads! What if the storage database is not local to the web server?   
> How will
> you perform comprehensive backups?  What if your RT has a million  
> attachments,
> or more?  Not to mention the performance hit of using a filesystem  
> as a
> database, especially with high concurrency at the HTTP level.
>
> I have a custom database application designed specifically to store  
> PDFs in
> the database.  It has 30 million documents in it, the database  
> storage is over
> 4TB.  The web-based front-end for it is efficient enough to saturate a
> 100MBit/sec Internet connection with a single Core-2 duo web  
> server.  When I
> tested this against our old filesystem version of the application, it
> outperformed the filesystem by more than 100%.  Backup is done by  
> dumping the
> database in chunks in a rotating schedule.  Scalability can be  
> accomplished
> with simple replication to additional read-only SQL servers and  
> using a SQL
> relay to dispatch SQL commands in a load-balancing fashion.
>
> --
> -- ============================
>   Tom Lahti
>   BIT Statement LLC
>
>   (425)251-0833 x 117
>   http://www.bitstatement.net/
> -- ============================
> _______________________________________________
> http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
>
> Community help: http://wiki.bestpractical.com
> Commercial support: sales at bestpractical.com
>
>
> Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
> Buy a copy at http://rtbook.bestpractical.com
>


-------------------------------------------------
Justin Hayes
Orbis Support Manager
justin.hayes at orbisuk.com




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20091019/9c99ae7b/attachment.htm>