Tardiba - The Tasmanian Devil Database Server
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
 
 

140 lines
3.6 KiB

TarDiBa - Database Server
=========================
Operating System
----------------
Kernel
~~~~~~
Patches
^^^^^^^
- linux-vserver (included in vserver package and applied automatically)
- grsecurity (we have to use stable Linux-VServer + grsecurity patch)
Filesystem
~~~~~~~~~~
Filesystem Layout
^^^^^^^^^^^^^^^^^
mountpoint fstype size
/
/boot
/usr
/home
/data
- filesystem, probably reiserfs (fast)
- tweaked boot for high performance
- tweaked kernel, highmem, disk access and stuff
Database System
---------------
- various maintanace scripts (for now using them for backups
and vacuuming)
- jump to pg8
Autovacuuming
~~~~~~~~~~~~~
- autovacuuming has to be disabled with the postgresql.conf
Logging
~~~~~~~
Abstract
^^^^^^^^
postgresql has a logging facility that drops every statement to log
before it get's executed.
in certain conditions those logs are of very big interest.
legal issues and profiling issues.
Problem
^^^^^^^
problem is that if i enable that systems goes 10 times slower because
of the huge statements that has to be written to disc.
On a bussy server they can easily reach 10th of MB per day.
30-40 but that is quite rare
usualy under 10MB
Solution
^^^^^^^^
- implementing a logging facility to RAM, flushing logs in
background to disk
- usually i am only interested in those statements
we have to consider to flush the logs from the ramdisk if we restart
pg perhaps
Tasks
^^^^^
- we need to test a postgresql.conf option that only logs statements
that take more time than a specified period (i.e. 5min.)
- problem is that that option doesn't work too well like the option
to kill iddle statements
- problem is that pg does not recognize blocked processes like the
ones which are iddle in transaction. an iddle in transaction proces
blocks the whole db (no selects, no updates, no nothing). the only way
out of it is to kill -9 the process
- killing postgresql processes
- postgresql has 2 kinds of processes (the parent postmaster
process which is allways active and child postmaster processes
which are born from the master when it receives a statement
- problem is that childs are forks so whenever i kill a child,
all childs die that sucks somehow
- so instead of killing childs we usualy restart the postmaster but
that has to have another solution too, just that i was unable to
find it
- is there any possib to kill a forked child withoput killing all
childs? (maybe there are some kill statement options for that)
- normally each child should have an own PID
- i use kill -9 $PID
- most probably the parent "thinks" there are problems if one
child dies and kills them all
- next thing is that only the master postmaster is alive. i
couldn't get a concludent answer from #postgresql. all that i
got was 'Don't kill -9 postmaster.
- maybe instead of trying to kill processes we should add pgpool
capabilities to TarDiBa, harvesting in this case other benefits
too like fixed number of connections and the posibility to play
with replpication thingy and loadbalancing
Backup System
-------------
- backup is done by shell scripts and cron (change? not likely)
- backups on other machines (over scp for other linux hosts, samba
for 'secure' Windows2000???, eventually a pro backup app although i
don't think it is necessary, maybe for whole system recovery)
System Monitoring and Notification
----------------------------------
- monitoring disk space, backup files dimensions, excerpts from
certain log files, system status and stats (cpu usage, ram etc), monitoring
pg sessions because the internal pg monitor sucks, we need a good policy on
killing iddle sessions and runaway processes.