Geek Gogie (Paul Namuag's Blog)

I have encountered this when I was upgrading my packages and one of them is Percona Server. Then I encountered this strange error below, (Reading database ... 82838 files and directories currently installed.) Preparing to replace libmysqlclient18-dev 1:5.5.33-rel31.1-566.precise (using .../libmysqlclient18-dev_1%3a5.5.33-rel31.1-568.precise_amd64.deb) ... Unpacking replacement libmysqlclient18-dev ... dpkg: error processing /var/cache/apt/archives/libmysqlclient18-dev_1%3a5.5.33-rel31.1-568.precise_amd64.deb (--unpack):  trying to overwrite '/usr/lib/libmysqlservices.a', which is also in package libmysqlclient-dev 1:5.5.33-rel31.1-566.precise dpkg-deb: error: subprocess paste was killed by signal (Broken pipe) Errors were encountered while processing:  /var/cache/apt/archives/libmysqlclient18-dev_1%3a5.5.33-rel31.1-568.precise_amd64.deb E: Sub-process /usr/bin/dpkg returned an error code (1) So my fix to that is remove  this package "libmysqlclient18*". I'

For some reason, It seems that LC_CTYPE is not declared and can't use fallback to use LC_ALL value. So my very easy fix on this is to declare or define a global shell environment variable in my /etc/default/locale. Here's what my /etc/default/locale contains, toytoy@ubuntu-toytoygogie:~$ cat /etc/default/locale LANG="en_US.UTF-8" LC_ALL=en_US.UTF-8 Hope that helps.

Usually, I got this problem when I start Ubuntu and I cannot connect to the internet. So my fix is just pretty simple, though either might work in your end or not. 1. update your date 2. restart service on /etc/rc.d/networking So in my case, how did I fix it is by $ service ntp stop $ ntpdate 10.0.1.19 $ service networking restart $ service ntp start So where did I have this 10.0.1.19? This is my other VM also, act as a server which interacts through the ntp socket and updates from the 10.0.1.19 server's time. If you don't have other VM, I'm not sure with this, just try to update your date to the recent date you have. Afterwads, just run $ /sbin/dhclient eth0 and hope everything will work into your end.

I just wanted to share these great benchmark results for your guide, http://www.ntlug.org/Articles/DiskBenchmarks http://www.mysqlperformanceblog.com/2009/05/01/raid-vs-ssd-vs-fusionio/

This is wonderful post to learn how to recover your data from Peter Zaitsev, http://www.mysqlperformanceblog.com/2008/07/04/recovering-innodb-table-corruption/ This means that in every BTREE context, there's always a page and by using BTREE data structure, you have records stored in there as part of the page and that means you can recover your data from its tablespace.

In case you're experiencing your ibdata1 is getting bigger, read this wonderful post by my colleague Miguel at Percona. http://www.mysqlperformanceblog.com/2013/08/20/why-is-the-ibdata1-file-continuously-growing-in-mysql/