Support for PostgreSQL in OTRS and Bugzilla appliances

[mkarg]

With regards to stability and scalability, PostgreSQL by far outperforms MySQL. As both, OTRS and Bugzilla store information which are vital for a business running these appliances, it would be great if default installation comes with PostgreSQL instead of MySQL, or at least, support for that systems would be set up but a simple configuration switch is to be triggered.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[lirazsiri]

I think this is a great idea, especially now that MySQL is being
developed by Oracle who don't have the best track record with regards to
open source. FWIW, we use PostgreSQL internally for the Hub.

[mkarg]

Being an RDBMS professional for several decades meanwhile, I'd like to mention that one additional thing should be done in the same step: Have a separate virtual disk that holds the write-ahead log (WAL), like it is a best practice told by virtually any RDBMS vendor and professional. Not only this provides much improved prevention against data loss, it also opens the gate for improved performance thanks to parallel drive access. If you like to maximize that, you could even use up to four virtual drives, one holding the database archive, one the database journal (WAL), one a tablespace for indices, and one for temporary storage. Doing so, each single virtual drive can have an optimized physical setup, plus optimized file system (like preventing journalling).

[lirazsiri]

Sounds like a great idea in theory but I wonder how we would implement in a way that works for the builds that don't come pre-configured with virtual hard disks (e.g., the ISOs). In any case we're going to be including all of the ISO conversion scripts in TKLDev so hopefully that will mean we might be able to put more brainpower on this problem.

[mkarg]

I do not see the actual concern. Possibly I miss something, but...

Thanks to TKL's use of LVM we can generally provide two LVs ("fast", "safe") based on two different VGs ("fast", "safe") to allow databases to have their journal (WAL) stored on LV "fast" and their archive (tablespace) stored on LV "safe". Pre-configured packages like OVF/OVA can provide two vHDDs ("fast", "safe") to host two separate PVs ("fast", "safe") storing these VGs, so the administrator can simply put these PVs on separate pHDDs or LUNs implementing the particular "fast" (SSD) or "safe" (RAID6) characteristics.

If I see the non-preconfigured package types correctly, they do not make any assumption on the hardware, hence already have to deal with manual configuration anyways (e. g. how does the ISO know that it might have to use /dev/sdc but not /dev/sda in a multi-pHDD hardware?). So the question simply is, if we provide an ISO packaging for a dual-PV LVM configuration, is there any difference at all? I mean, if the iso currently assumes that there is an /dev/sda and statically installs THERE, then it is simply pretty straightforward to also assume there is a /dev/sdb available for database appliances.

ISO packaging IMHO is for heavy-load production use only in comparison to pre-packaged VMDKs. Running databases in such a scenario without a second physical disk is absolutely irresponsible, so enforcing a second disk for that packaging is absolutely acceptable.

[JedMeister]

IMO if we are going to do this it may be best to rebase both appliances on LAPP rather than LAMP?

I've targetted v14.0 stable release but we'll see...

[JedMeister]

I'm repinning this issue to "on ice". It would be really cool, but it's probably not going to happen anytime soon unless someone in the community takes it on...

[aaronkempf]

I'll try to take a look at it as soon as I can turn off the password
protected BIOS ony Vaio !!

I can't virtualize ANYTHING until I get through that roadblock (not soon)
On Dec 15, 2015 7:50 PM, "Jeremy Davis" notifications@github.com wrote:

I'm repinning this issue to "on ice". It would be really cool, but it's
probably not going to happen anytime soon unless someone in the community
takes it on...

—
Reply to this email directly or view it on GitHub
#237 (comment)
.