Re: [rt-users] Query Regarding Upgrade to 3.8.4

2009-07-29 Thread Ruslan Zakirov
On Wed, Jul 29, 2009 at 9:20 AM, Duncan McEwandun...@ecs.vuw.ac.nz wrote:
 Hi,

 I recently upgraded our RT installation from 3.8.1 to 3.8.4.  The upgrade
 seemed to go fine, and as far as I can see everything is working well.

 But I have a query relating to the upgrade script etc/upgrade/3.8.4/content.

 We do use Ruslan's RT-Action-NotifyGroup extension (version 0.2) and so
 I'd like to know what effect this upgrade script has on our database.

Do you know that this extension is part of RT 3.8? If you have
extension installed from the CPAN as well then most probably CPAN
version will mask RT's version which has been updated. RT's version
has new features, for example it allow you to use non-user email
address, user name, user email, group name or numeric id in the
argument. With these changes it's really easier to use this action
with rt-crontool.


 As far as I could see from examining the ScripActions table before and
 after running the upgrade script (using rt-setup-database), it made no
 change.  Both before and after the script was run, the Argument value
 for each NotifyGroup or NotifyGroupAsComment action was the numeric id
 of the appropriate group from the Groups table.

 Is this what they are supposed to be?

Yes. This script converts very old format of argument string to the
current. Probably nobody has arguments in this format anymore. Also,
in old version any separator of ids was allowed, but now it's only
comma.


 I tried to understand what the upgrade script is doing, but I got lost
 on the call to Storable::thaw($arg).  I'm not sure why it is trying to
 thaw the value of $arg, when I can't see how that variable would contain
 something previously returned by Storable::freeze().

 In fact I can't see anywhere that $arg is set, so I was wondering whether
 that was a typo and it should actually be $argument, which *is* set three
 lines earlier.  On the off-chance, I tried changing $arg to $argument and
 rerunning the script (on a test database!) but it still had no (apparent)
 effect.

Oh, you're right about argument vs arg. Going to change that, but you
shouldn't worry. Hope nobody has that old format used.

 It's quite likely that I'm missing something obvious here.

 Any assistance with what this upgrade script is trying to achieve, and
 whether or not the current values for the Arguments for those actions
 in our database seem correct would be much appreciated.

Comma separated list of ids is perfectly good argument.


 Thanks,

 Duncan


 ___
 http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

 Community help: http://wiki.bestpractical.com
 Commercial support: sa...@bestpractical.com


 Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
 Buy a copy at http://rtbook.bestpractical.com




-- 
Best regards, Ruslan.
___
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Community help: http://wiki.bestpractical.com
Commercial support: sa...@bestpractical.com


Discover RT's hidden secrets with RT Essentials from O'Reilly Media. 
Buy a copy at http://rtbook.bestpractical.com

[rt-users] SimpleSearch excludes resolved results

2009-07-29 Thread David
Hello,

I am aware of the patches offered here:
http://wiki.bestpractical.com/view/SimpleSearchIncludeResolved

Now, I am referring to the the following thread:
http://lists.bestpractical.com/pipermail/rt-users/2008-September/053928.html

I was curious to know if the feature/patch discussed by Jesse and the
community was somewhere in the development tree ?

Thanks,
___
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Community help: http://wiki.bestpractical.com
Commercial support: sa...@bestpractical.com


Discover RT's hidden secrets with RT Essentials from O'Reilly Media. 
Buy a copy at http://rtbook.bestpractical.com


Re: [rt-users] Migrating from Postgres to MySQL

2009-07-29 Thread Robert Nesius
On Tue, Jul 28, 2009 at 3:56 PM, Kenneth Marshall k...@rice.edu wrote:

 Kage,

 The main advantage is gained by avoiding I/O through the virtual
 disk. The layout of the virtual disk tends to turn most I/O into
 random I/O, even I/O that starts as sequential. The factor of
 10 performance difference between random/sequential I/O causes
 the majority of the performance problem. I have not had personal
 experience with using an NFS mount point to run a database so I
 cannot really comment on that. Good luck with your evaluation.


You're trading head-seeking latencies for network latencies, and those are
almost certainly higher.  Hosting your database server binaries and such
forth in NFS is possible, though again, not optimal both from a performance
and risk standpoint (NFS server drops, your DB binaries vanish, your DB
server drops even though the machine hosting it was fine).

I think hosting databases in NFS can cause serious problems - I seem to
remember older versions of mysql wouldn't support that.  I don't know if
newer ones do...but I do know in the *very large* IT environment I worked
in, all database servers hosted the DBs on their local disks or in
filesystems hosted on disks (SANS?) attached via fibre-channel.

Could solid-state drives side-step the random-access issue with
virtualization, or at least make it suck less? Based on how many people I
know who have said Wow, my SSD died.  I thought those were supposed to be
more reliable? ... I wouldn't bet my service uptime on it. ;)

-Rob
___
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Community help: http://wiki.bestpractical.com
Commercial support: sa...@bestpractical.com


Discover RT's hidden secrets with RT Essentials from O'Reilly Media. 
Buy a copy at http://rtbook.bestpractical.com

Re: [rt-users] SimpleSearch excludes resolved results

2009-07-29 Thread Kevin Falcone
On Wed, Jul 29, 2009 at 07:58:46AM -0400, David wrote:
 I am aware of the patches offered here:
 http://wiki.bestpractical.com/view/SimpleSearchIncludeResolved
 
 Now, I am referring to the the following thread:
 http://lists.bestpractical.com/pipermail/rt-users/2008-September/053928.html
 
 I was curious to know if the feature/patch discussed by Jesse and the
 community was somewhere in the development tree ?

Nothing has hit the repo at this time, you can look at the history
here:

http://github.com/bestpractical/rt/commits/3.8-trunk/lib/RT/Search/Googleish.pm

-kevin
___
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Community help: http://wiki.bestpractical.com
Commercial support: sa...@bestpractical.com


Discover RT's hidden secrets with RT Essentials from O'Reilly Media. 
Buy a copy at http://rtbook.bestpractical.com


Re: [rt-users] Table 'rt3.ObjectCustomFields' doesn't exist

2009-07-29 Thread raymond

Hi,

Thank you for the suggestion.

I'll give that a shot. This is a migration from an old box running 3.2.2 
to a  new server which is rt 3.8.4 fresh 
install.  Will I need to do make upgrade as 
indicated in the 3.8.4 README file?



I am exporting rt 3.2.2 db on old server and importing to the new server 
running rt 3.8.4



mysql -u root -p rt3  oldrt3.2.2.db.sql



raymond





On Wed, 29 Jul 2009, Ruslan Zakirov wrote:


Then you missed one step. You have to upgrade DB first from 3.2.2 to
3.7.89 first. It's `rt-setup-database --action update ...` command
described in more details in UPGRADING.mysql and README files.

On Tue, Jul 28, 2009 at 11:39 PM, raym...@pilotsupplies.com wrote:

Hi Ruslan,


My apologies.  I was upgrading from 3.2.2


raymond



On Tue, 28 Jul 2009, Ruslan Zakirov wrote:


Why do you even need mysqlupgrade.sql if it's fresh install?

On Tue, Jul 28, 2009 at 10:13 PM, raym...@pilotsupplies.com wrote:


ubuntu vmware esx4i with ubuntu 9.04 4GB of memory dual xeon processor

fresh 3.8.4 install, apache2, perl_Mode 2, mysql 5

go error Table 'rt3.ObjectCustomFields' doesn't exist

so I went and commented out the following, see below and proceed with the
install with no other issues.

Am wondering if there are any implications, issues or problems with this
or is there a better way to fix this ?


thanx!



/usr/local/src/rt-3.8.4/etc/upgrade# mysql -u root -p rt3 
mysqlupgrade.sql
Enter password:
ERROR 1146 (42S02) at line 77: Table 'rt3.ObjectCustomFields' doesn't
exist


r...@joeblow:/usr/local/src/rt-3.8.4/etc/upgrade# vi mysqlupgrade.sql

#ALTER TABLE ObjectCustomFields
#   DEFAULT CHARACTER SET utf8;
#ALTER TABLE ObjectCustomFieldValues
#   DEFAULT CHARACTER SET utf8;



--



Regards,

Raymond Wong


Personal motto: P.E.A.C.E
Enjoy the present
Assert your goals
Champion peace
Entrust others
___
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Community help: http://wiki.bestpractical.com
Commercial support: sa...@bestpractical.com


Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
Buy a copy at http://rtbook.bestpractical.com








--



Regards,

Raymond Wong


Personal motto: P.E.A.C.E
Enjoy the present
Assert your goals
Champion peace
Entrust others







--



Regards,

Raymond Wong


Personal motto: P.E.A.C.E
Enjoy the present
Assert your goals
Champion peace
Entrust others___
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Community help: http://wiki.bestpractical.com
Commercial support: sa...@bestpractical.com


Discover RT's hidden secrets with RT Essentials from O'Reilly Media. 
Buy a copy at http://rtbook.bestpractical.com

Re: [rt-users] Migrating from Postgres to MySQL

2009-07-29 Thread Matt Simerson


On Jul 29, 2009, at 7:10 AM, Robert Nesius wrote:

On Tue, Jul 28, 2009 at 3:56 PM, Kenneth Marshall k...@rice.edu  
wrote:

Kage,

The main advantage is gained by avoiding I/O through the virtual
disk. The layout of the virtual disk tends to turn most I/O into
random I/O, even I/O that starts as sequential. The factor of
10 performance difference between random/sequential I/O causes
the majority of the performance problem. I have not had personal
experience with using an NFS mount point to run a database so I
cannot really comment on that. Good luck with your evaluation.

You're trading head-seeking latencies for network latencies,


No.

If this were a standard host environment, that would be true. But in a  
virtual environment, there is the overhead of the disk create/ 
maintenance/update processes of the virtualization engine which  
multiply the overhead of the disk. Just run a disk benchmarking  
utility inside a VE running under any platform that uses disk images  
(vmware, xen, parallels, etc...) and then run those same tests on the  
host node. The difference in performance is often an order of  
magnitude slower for the virtual disks.


Contrast that with NFS performance, which has a small fixed overhead  
imposed by the network (even smaller if you use jumbo frames). If you  
were using a platform with a robust NFS implementation (Solaris,  
FreeBSD), I'd put money on the database performing better on NFS than  
inside most virtual machines. If you're using NFS with Linux, you will  
certainly have performance issues that you won't be able to get past.


If the virtualization environment provides raw disk access to the VE,  
my bet is off. Examples of virtualization platforms that [can] do this  
are FreeBSD jails and Linux OpenVZ. On several occasions, I have built  
VEs for MySQL and mounted a dedicated partition in the VE. Assuming  
you've given adequate resources to the DB VE, that works as well as a  
dedicated machine.


When I arrived at my current position, the SA team had put the  
databases into the VEs that needed them, along with the apps that  
accessed them. Despite having 6 servers to spread the load across,  
they had recurring database performance issues (a few times a week),  
particularly with RT. I resolved all the DB issues by building a  
dedicated machine with 4 disks (two battery backed RAID-1 mirrors) all  
the databases to it. The databases have dedicated spindles as does the  
OS  logging. Despite the resistance to the all our DB eggs in one  
basket approach, the wisdom of that choice is now plainly evident.  
All the performance problems went away and haven't returned.


and those are almost certainly higher.  Hosting your database server  
binaries and such forth in NFS is possible, though again, not  
optimal both from a performance and risk standpoint (NFS server  
drops, your DB binaries vanish, your DB server drops even though the  
machine hosting it was fine).


That's not how NFS works. If the NFS server vanishes, the NFS client  
hangs and waits for it to return. That is a design feature of NFS. The  
consistency of the databases is entirely dependency on the disk  
subsystem of the file server.


I think hosting databases in NFS can cause serious problems - I seem  
to remember older versions of mysql wouldn't support that.  I don't  
know if newer ones do...but I do know in the very large IT  
environment I worked in, all database servers hosted the DBs on  
their local disks or in filesystems hosted on disks (SANS?) attached  
via fibre-channel.


I would never host a database server on anything but RAID protected  
disks with block level access (ie, local disks, iSCSI, etc). Database  
engines have been explicitly designed and optimized for this type of  
disk backend.  That is starting to change, as a few new DB engines  
that are designed for network storage (like SimpleDB). But none I know  
of are production-ready.


Could solid-state drives side-step the random-access issue with  
virtualization, or at least make it suck less?


Haven't tried it yet, but my guess is no.  However, I have put  
databases on SSD disks with excellent results.


Based on how many people I know who have said Wow, my SSD died.  I  
thought those were supposed to be more reliable? ... I wouldn't bet  
my service uptime on it. ;)


There's this thing called RAID, that protects against disk  
failures It works quite well with SSD disks and delivers  
performance numbers for a couple thousand bucks that would otherwise  
take a $150,000+ SAN.


Matt

___
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Community help: http://wiki.bestpractical.com
Commercial support: sa...@bestpractical.com


Discover RT's hidden secrets with RT Essentials from O'Reilly Media. 
Buy a copy at http://rtbook.bestpractical.com

Re: [rt-users] Table 'rt3.ObjectCustomFields' doesn't exist

2009-07-29 Thread Ruslan Zakirov
On Wed, Jul 29, 2009 at 9:21 PM, raym...@pilotsupplies.com wrote:
 Hi,

 Thank you for the suggestion.

 I'll give that a shot. This is a migration from an old box running 3.2.2 to
 a  new server which is rt 3.8.4 fresh install.  Will I need to do make
 upgrade as indicated in the 3.8.4 README file?

Nope, you run `make install` instead of `make upgrade` as you have no
RT files on new server.

 I am exporting rt 3.2.2 db on old server and importing to the new server
 running rt 3.8.4

Don't forget to using --default-charset=binary, both on export and
import. Check exact syntax in mysql's docs. It's important or you can
break every binary attachment.



 mysql -u root -p rt3  oldrt3.2.2.db.sql

mysql --default-charset=binary -u root -p rt3  oldrt3.2.2.db.sql



 raymond





 On Wed, 29 Jul 2009, Ruslan Zakirov wrote:

 Then you missed one step. You have to upgrade DB first from 3.2.2 to
 3.7.89 first. It's `rt-setup-database --action update ...` command
 described in more details in UPGRADING.mysql and README files.

 On Tue, Jul 28, 2009 at 11:39 PM, raym...@pilotsupplies.com wrote:

 Hi Ruslan,


 My apologies.  I was upgrading from 3.2.2


 raymond



 On Tue, 28 Jul 2009, Ruslan Zakirov wrote:

 Why do you even need mysqlupgrade.sql if it's fresh install?

 On Tue, Jul 28, 2009 at 10:13 PM, raym...@pilotsupplies.com wrote:

 ubuntu vmware esx4i with ubuntu 9.04 4GB of memory dual xeon processor

 fresh 3.8.4 install, apache2, perl_Mode 2, mysql 5

 go error Table 'rt3.ObjectCustomFields' doesn't exist

 so I went and commented out the following, see below and proceed with
 the
 install with no other issues.

 Am wondering if there are any implications, issues or problems with
 this
 or is there a better way to fix this ?


 thanx!



 /usr/local/src/rt-3.8.4/etc/upgrade# mysql -u root -p rt3 
 mysqlupgrade.sql
 Enter password:
 ERROR 1146 (42S02) at line 77: Table 'rt3.ObjectCustomFields' doesn't
 exist


 r...@joeblow:/usr/local/src/rt-3.8.4/etc/upgrade# vi mysqlupgrade.sql

 #ALTER TABLE ObjectCustomFields
 #   DEFAULT CHARACTER SET utf8;
 #ALTER TABLE ObjectCustomFieldValues
 #   DEFAULT CHARACTER SET utf8;



 --



 Regards,

 Raymond Wong


 Personal motto: P.E.A.C.E
 Enjoy the present
 Assert your goals
 Champion peace
 Entrust others
 ___
 http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

 Community help: http://wiki.bestpractical.com
 Commercial support: sa...@bestpractical.com


 Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
 Buy a copy at http://rtbook.bestpractical.com






 --



 Regards,

 Raymond Wong


 Personal motto: P.E.A.C.E
 Enjoy the present
 Assert your goals
 Champion peace
 Entrust others





 --



 Regards,

 Raymond Wong


 Personal motto: P.E.A.C.E
 Enjoy the present
 Assert your goals
 Champion peace
 Entrust others



-- 
Best regards, Ruslan.
___
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Community help: http://wiki.bestpractical.com
Commercial support: sa...@bestpractical.com


Discover RT's hidden secrets with RT Essentials from O'Reilly Media. 
Buy a copy at http://rtbook.bestpractical.com

Re: [rt-users] Migrating from Postgres to MySQL

2009-07-29 Thread William Graboyes
Hi Matt,

Raid is not the end-all be-all for disk safety, especially when you step
into terabyte class computing, sorry I am taking this a bit off topic. While
RAID has it's bonuses, there are drawbacks as well, take your standard RAID
5 setup, 4 Disks, 3 active, 1 Hot Spare.  Now lets say that Disk number 2
decided it was going to release it's smoke to the world (never a good
thing), now your array is still alive and it is starting to rebuild onto
disk 4 to make up for the death of disk 2.  During the rebuild process Disk
1 comes across a bad sector, poof, your data is gone.  Just a word of
warning, don't put all your data safety eggs into the RAID basket.

Otherwise I agree that running via NFS from a virtualized server would
probably have perfromance gains over running in the virtual invironment.

Thanks,
Bill

On Wed, Jul 29, 2009 at 10:26 AM, Matt Simerson m...@corp.spry.com wrote:


 On Jul 29, 2009, at 7:10 AM, Robert Nesius wrote:

 On Tue, Jul 28, 2009 at 3:56 PM, Kenneth Marshall k...@rice.edu wrote:

 Kage,

 The main advantage is gained by avoiding I/O through the virtual
 disk. The layout of the virtual disk tends to turn most I/O into
 random I/O, even I/O that starts as sequential. The factor of
 10 performance difference between random/sequential I/O causes
 the majority of the performance problem. I have not had personal
 experience with using an NFS mount point to run a database so I
 cannot really comment on that. Good luck with your evaluation.


 You're trading head-seeking latencies for network latencies,


 No.

 If this were a standard host environment, that would be true. But in a
 virtual environment, there is the overhead of the disk
 create/maintenance/update processes of the virtualization engine which
 multiply the overhead of the disk. Just run a disk benchmarking utility
 inside a VE running under any platform that uses disk images (vmware, xen,
 parallels, etc...) and then run those same tests on the host node. The
 difference in performance is often an order of magnitude slower for the
 virtual disks.

 Contrast that with NFS performance, which has a small fixed overhead
 imposed by the network (even smaller if you use jumbo frames). If you were
 using a platform with a robust NFS implementation (Solaris, FreeBSD), I'd
 put money on the database performing better on NFS than inside most virtual
 machines. If you're using NFS with Linux, you will certainly have
 performance issues that you won't be able to get past.

 If the virtualization environment provides raw disk access to the VE, my
 bet is off. Examples of virtualization platforms that [can] do this are
 FreeBSD jails and Linux OpenVZ. On several occasions, I have built VEs for
 MySQL and mounted a dedicated partition in the VE. Assuming you've given
 adequate resources to the DB VE, that works as well as a dedicated machine.

 When I arrived at my current position, the SA team had put the databases
 into the VEs that needed them, along with the apps that accessed them.
 Despite having 6 servers to spread the load across, they had recurring
 database performance issues (a few times a week), particularly with RT. I
 resolved all the DB issues by building a dedicated machine with 4 disks (two
 battery backed RAID-1 mirrors) all the databases to it. The databases have
 dedicated spindles as does the OS  logging. Despite the resistance to the
 all our DB eggs in one basket approach, the wisdom of that choice is now
 plainly evident. All the performance problems went away and haven't
 returned.

 and those are almost certainly higher.  Hosting your database server
 binaries and such forth in NFS is possible, though again, not optimal both
 from a performance and risk standpoint (NFS server drops, your DB binaries
 vanish, your DB server drops even though the machine hosting it was fine).


 That's not how NFS works. If the NFS server vanishes, the NFS client hangs
 and waits for it to return. That is a design feature of NFS. The consistency
 of the databases is entirely dependency on the disk subsystem of the file
 server.

 I think hosting databases in NFS can cause serious problems - I seem to
 remember older versions of mysql wouldn't support that.  I don't know if
 newer ones do...but I do know in the *very large* IT environment I worked
 in, all database servers hosted the DBs on their local disks or in
 filesystems hosted on disks (SANS?) attached via fibre-channel.


 I would never host a database server on anything but RAID protected disks
 with block level access (ie, local disks, iSCSI, etc). Database engines have
 been explicitly designed and optimized for this type of disk backend.  That
 is starting to change, as a few new DB engines that are designed for network
 storage (like SimpleDB). But none I know of are production-ready.

 Could solid-state drives side-step the random-access issue with
 virtualization, or at least make it suck less?


 Haven't tried it yet, but my guess is no.  However, I have put 

Re: [rt-users] Migrating from Postgres to MySQL

2009-07-29 Thread Matt Simerson

On Jul 29, 2009, at 10:44 AM, William Graboyes wrote:

 Hi Matt,

 Raid is not the end-all be-all for disk safety, especially when you  
 step into terabyte class computing, sorry I am taking this a bit off  
 topic. While RAID has it's bonuses, there are drawbacks as well,  
 take your standard RAID 5 setup, 4 Disks, 3 active, 1 Hot Spare.   
 Now lets say that Disk number 2 decided it was going to release it's  
 smoke to the world (never a good thing), now your array is still  
 alive and it is starting to rebuild onto disk 4 to make up for the  
 death of disk 2.  During the rebuild process Disk 1 comes across a  
 bad sector, poof, your data is gone.  Just a word of warning, don't  
 put all your data safety eggs into the RAID basket.

RAID poorly implemented is a placebo, and is often less reliable than  
a single disk. RAID properly implemented IS the end-all be-all of disk  
safety.

Your chosen argument is only valid against RAID level 5, which would  
be a very poor choice for a database application. RAID-5 is a poor  
choice in any environment where the data set is volatile and valuable.  
Especially when you consider the number of hours (or days) it takes to  
rebuild a hot spare into the RAID-5 set. (HINT: test that before  
deployment!)  During that rebuild window, your system performance is  
heavily degraded and extremely vulnerable. If the performance of your  
RAID system is halved, is that sufficient for your application, or is  
your system effectively down during the rebuild period? (HINT: test  
before deployment!).

But a RAID-1 or RAID 10 can be extremely robust, remaining online and  
performing optimally during multiple catastrophic disk failures. You  
can mirror the data to as many spindles as you need to insure data  
integrity. When disks fail, rebuilding a mirror disk usually takes  
less than an hour.

The systems engineer has to choose between data integrity,  
performance, and storage efficiency.

One of my systems is about 2/3 full with 24.64 TB of data. Does that  
count as terabyte class computing?  :)  I'm using ZFS to manage  
it. :)  :)

Matt
___
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Community help: http://wiki.bestpractical.com
Commercial support: sa...@bestpractical.com


Discover RT's hidden secrets with RT Essentials from O'Reilly Media. 
Buy a copy at http://rtbook.bestpractical.com


Re: [rt-users] Table 'rt3.ObjectCustomFields' doesn't exist

2009-07-29 Thread raymond

HI,

I'll give it another shot with the required options. Thank you!


raymond





On Wed, 29 Jul 2009, Ruslan Zakirov wrote:


On Wed, Jul 29, 2009 at 9:21 PM, raym...@pilotsupplies.com wrote:

Hi,

Thank you for the suggestion.

I'll give that a shot. This is a migration from an old box running 3.2.2 to
a  new server which is rt 3.8.4 fresh install.  Will I need to do make
upgrade as indicated in the 3.8.4 README file?


Nope, you run `make install` instead of `make upgrade` as you have no
RT files on new server.


I am exporting rt 3.2.2 db on old server and importing to the new server
running rt 3.8.4


Don't forget to using --default-charset=binary, both on export and
import. Check exact syntax in mysql's docs. It's important or you can
break every binary attachment.




mysql -u root -p rt3  oldrt3.2.2.db.sql


mysql --default-charset=binary -u root -p rt3  oldrt3.2.2.db.sql




raymond





On Wed, 29 Jul 2009, Ruslan Zakirov wrote:


Then you missed one step. You have to upgrade DB first from 3.2.2 to
3.7.89 first. It's `rt-setup-database --action update ...` command
described in more details in UPGRADING.mysql and README files.

On Tue, Jul 28, 2009 at 11:39 PM, raym...@pilotsupplies.com wrote:


Hi Ruslan,


My apologies.  I was upgrading from 3.2.2


raymond



On Tue, 28 Jul 2009, Ruslan Zakirov wrote:


Why do you even need mysqlupgrade.sql if it's fresh install?

On Tue, Jul 28, 2009 at 10:13 PM, raym...@pilotsupplies.com wrote:


ubuntu vmware esx4i with ubuntu 9.04 4GB of memory dual xeon processor

fresh 3.8.4 install, apache2, perl_Mode 2, mysql 5

go error Table 'rt3.ObjectCustomFields' doesn't exist

so I went and commented out the following, see below and proceed with
the
install with no other issues.

Am wondering if there are any implications, issues or problems with
this
or is there a better way to fix this ?


thanx!



/usr/local/src/rt-3.8.4/etc/upgrade# mysql -u root -p rt3 
mysqlupgrade.sql
Enter password:
ERROR 1146 (42S02) at line 77: Table 'rt3.ObjectCustomFields' doesn't
exist


r...@joeblow:/usr/local/src/rt-3.8.4/etc/upgrade# vi mysqlupgrade.sql

#ALTER TABLE ObjectCustomFields
#   DEFAULT CHARACTER SET utf8;
#ALTER TABLE ObjectCustomFieldValues
#   DEFAULT CHARACTER SET utf8;



--



Regards,

Raymond Wong


Personal motto: P.E.A.C.E
Enjoy the present
Assert your goals
Champion peace
Entrust others
___
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Community help: http://wiki.bestpractical.com
Commercial support: sa...@bestpractical.com


Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
Buy a copy at http://rtbook.bestpractical.com








--



Regards,

Raymond Wong


Personal motto: P.E.A.C.E
Enjoy the present
Assert your goals
Champion peace
Entrust others







--



Regards,

Raymond Wong


Personal motto: P.E.A.C.E
Enjoy the present
Assert your goals
Champion peace
Entrust others







--



Regards,

Raymond Wong


Personal motto: P.E.A.C.E
Enjoy the present
Assert your goals
Champion peace
Entrust others___
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Community help: http://wiki.bestpractical.com
Commercial support: sa...@bestpractical.com


Discover RT's hidden secrets with RT Essentials from O'Reilly Media. 
Buy a copy at http://rtbook.bestpractical.com

[rt-users] Attachment storage

2009-07-29 Thread Michael Ellis
I am considering attaching .wav files of the voicemail left on our helpdesk to 
rt tickets, but I'm worried about performance/stability if I start putting this 
amount of binary data in the system. I ran this thought by our local DB guy and 
he suggested that this might not be a problem if the database just contained 
pointers to files stored elsewhere.

I looked at the rt3.Attachments and it looks like the content is actually 
stored in the DB itself, but I'm a DB newbie.

So I suppose I have three questions: 

1) Do I have it right that the attachments are stored in the DB itself?
2) If they are, could the DB handle, say, a thousand 200KB-2MB attachments per 
year (and if so for how long?)?
3) If they aren't, is there something else that might be a problem?

Thanks for your help,
Mike___
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Community help: http://wiki.bestpractical.com
Commercial support: sa...@bestpractical.com


Discover RT's hidden secrets with RT Essentials from O'Reilly Media. 
Buy a copy at http://rtbook.bestpractical.com

Re: [rt-users] Attachment storage

2009-07-29 Thread Jerrad Pierce
 1) Do I have it right that the attachments are stored in the DB itself?
Alas, they are.

 2) If they are, could the DB handle, say, a thousand 200KB-2MB attachments
 per year (and if so for how long?)?
Depends on your rdbms. Oracle could it, not so sure about MySQL.

Alternatively, you could stash them on a network share or similar,
and give the path in a clickable custom field...
___
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Community help: http://wiki.bestpractical.com
Commercial support: sa...@bestpractical.com


Discover RT's hidden secrets with RT Essentials from O'Reilly Media. 
Buy a copy at http://rtbook.bestpractical.com


Re: [rt-users] Attachment storage

2009-07-29 Thread Jesse Vincent



On Wed 29.Jul'09 at 18:16:51 -0500, Michael Ellis wrote:
 So I suppose I have three questions:
  
 1) Do I have it right that the attachments are stored in the DB itself?

Yes.

 2) If they are, could the DB handle, say, a thousand 200KB-2MB attachments per
 year (and if so for how long?)?

2 gigabytes of storage per year isn't a whole heck of a lot to see a
database grow by in the 21st century. 

All our corporate voicemail goes into a MySQL backed RT and we're very
happy with it.


pgpCxaj0ukCjO.pgp
Description: PGP signature
___
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Community help: http://wiki.bestpractical.com
Commercial support: sa...@bestpractical.com


Discover RT's hidden secrets with RT Essentials from O'Reilly Media. 
Buy a copy at http://rtbook.bestpractical.com