But we’ve always done it this way – DON’T
Last year I’ve been lucky to attend to USENIX LISA 14 – this was one of the badges that I collected – probably the best I’ve seen there. Always is too many times.
Cheers,
Pedro Oliveira
Last year I’ve been lucky to attend to USENIX LISA 14 – this was one of the badges that I collected – probably the best I’ve seen there. Always is too many times.
Cheers,
Pedro Oliveira
Few days ago I had the need to debug the output of a stream, the problem was that the output is bandwidth is not always constant and that seamed to affect the input application didn’t behave the same with different workloads.
A colleague told me to check pv. As I have never used it before I checked the man page first and it seamed promising. Bellow there are some details about it.
progress show progress bar
timer show elapsed time
eta show estimated time of arrival (completion)
rate show data transfer rate counter
average-rate show data transfer average rate counter
bytes show number of bytes transferred
format FORMAT set output format to FORMAT
numeric output percentages, not visual information
you can also change the standard behaviour of a pipe (and probably this is the most interesting part), you’ll be able to:
rate-limit RATE limit transfer to RATE bytes per second
buffer-size BYTES use a buffer size of BYTES
skip-errors skip read errors in input
stop-at-size stop after –size bytes have been transferred
In this case I’ll limit the write of a file to 1024MB/s, while writing a 10MB file (please note that the limits on both dd and pv are in bytes)
dd count=10 bs=1048576 if=/dev/zero | pv -L 1048576 | dd of=to_delete.file
10+0 records in [1021kiB/s] [ <=> ]
10+0 records out
10485760 bytes (10 MB) copied, 9.84052 s, 1.1 MB/s
10MiB 0:00:09 [1.01MiB/s] [ <=> ]
20400+100 records in
20480+0 records out
10485760 bytes (10 MB) copied, 9.93452 s, 1.1 MB/s
dd count=10 bs=1048576 if=/dev/zero | pv -S -s 5242880 | dd of=to_delete.file
5MiB 0:00:00 [92.4MiB/s] [===========================================>] 100%
10240+0 records in
10240+0 records out
5242880 bytes (5.2 MB) copied, 0.073623 s, 71.2 MB/s
dd count=500 bs=1048576 if=/dev/zero | pv | dd of=/dev/null
500+0 records in
500+0 records out
524288000 bytes (524 MB) copied, 0.684948 s, 765 MB/s
500MiB 0:00:00 [ 731MiB/s] [ <=> ]
1024000+0 records in
1024000+0 records out
524288000 bytes (524 MB) copied, 0.683847 s, 767 MB/s
dd count=500 bs=1048576 if=/dev/zero | pv -B 5242880 | dd of=/dev/null
500+0 records in
500+0 records out
524288000 bytes (524 MB) copied, 0.667252 s, 786 MB/s
500MiB 0:00:00 [ 750MiB/s] [ <=> ]
1024000+0 records in
1024000+0 records out
524288000 bytes (524 MB) copied, 0.667482 s, 785 MB/s
If you want to have more information or check some other use cases you may check this post on cyberciti.
See you next time,
Pedro Oliveira
Backups can be a tricky thing, all of us that did system administration, maintenance, or system engineering or architecture at some point had to choose a backup mechanism, that depending on the requirements can be a simple bash script that uses tar or rsync, or a robust solution like BackupPC or Bacula, backup appliances and so on.
Today while reading the BackuPC mail list someone asked about the best way to use it backup a MySQL DB, as always a multitude of options, one of my favourite ones is using MySQL-ZRM and BackupPC. I’m a fan boy of BackupPC, I’ve used it for years both in personal projects as in different enterprise projects, I’m not going to describe how to install or how to make BackupPC run on your system. There is a lot of online information about this (just check BackupPC home page).
Although BackupPC is a great tool it won’t guarantee the status of your databases on the moment of the copy, for that you need another tool, my favourite one is MySQL-ZRM. MySQL-ZRM will make sure that your new MySQL or mariadb backup is consistent, this backup can be retrieved by BackupPC and stored in the backup server.
As the title of the post says I’ll be using CentOS 7, so the first thing I need is to install the Epel repo on my CentOS 7 server:
rpm -Uvh https://ftp.fau.de/epel/7/x86_64/e/epel-release-7-1.noarch.rpm
Now that we have the repo installed we need to install MySQL-ZRM
yum install -y MySQL-zrm
There are two main differences in the configuration, the mode of the backup that can be:
Raw mode will make sure you that you’ll have the best performance possible during the backup, nevertheless it will need that you use LVM and I would only advice you to use it if you’re familiar with the concept. To start with you should have a logical volume for your mysql data dir (usually /var/lib/mysql/), then you should have available space on your volume group. At least double the space that you would need for MySQL operation during the backup, but please be generous here as if your ran out of space you will truncate your DBs. On the other hand the considerations over the performance may not be true as they will vary with your use case, RAW will make sure you that there were will be not locks on the DB during the time of the backup. If you really need performance to be unaltered during the seconds or minutes of the backup I would recommend a master/slave setup where you would to the backups from the slave host, thus not impacting the master.
The Logical backup mode doesn’t have any special requirements, nevertheless you’ll be “write locking” the tables during the time of the backup, with recent hardware even big backups can be fast, but if you are talking of a 200GB DB miracles won’t happen, in this cases I would recommend the RAW mode.
To make your MySQL server suitable for MySLQ-ZRM you need to create a user with the right set of permission, also if you are not backing up data on the same server that you’re running MySQL-ZRM you need to enable TCP on your mysql.
mysql -h localhost -p # or whatever IP or hostname where your MySQL lives
grant select, insert, update, create, drop, reload, shutdown, alter, super, lock tables, replication client on *.* to ‘backupuser’@’localhost’ identified by ‘very secret password‘;
After installing MySQL-ZRM we need to set it up, to do this we need to edit its configuration:
The config file is located at:
/etc/mysql-zrm/mysql-zrm.conf
In this example we will use the Logical backup mode the main configuration changes are:
backup-mode=logical
destination=/var/lib/mysql-zrm # backups destination folder (can be a NFS share, smb share, usb mount point, etc)
retention-policy=15D # How many days to keep the backup on the destination folder.
compress=1 # compress backups 1 = enabled, 0 = disabled
compress-plugin=/usr/bin/gzip # you’re able
all-databases=1 # do you want to backup all the databases on the mysql server? In this case we do
user=”backupuser” # authorized user to backup your databases
password=”very secret password” # the password
host=”your.server.hostname” # server host name
routines=1 # do we want to backup MySQL routines? In this case yes
verbose=0 # do we want the log to be verbose
mailto=”backup-list@linux-geex.com” # backup admin email, if you have a local MTA correctly configured you’ll receive an email if backups didn’t finish properly, this will depend on the email policy described below
mail-policy=only-on-error
If you are backing up a remote server you’ll also need to enable TCP transfers on my.cnf, this can be achieved by setting on the [mysql] section:
port = 3306
Please keep in mind that you should be very careful when exposing MySQL, so set your iptables firewall to only allow IP connections to the backup server and other desired mysql clients, bellow is an example of how to do it:
iptables -I INPUT -m tcp -p tcp –dport 3306 -i eth0 -s 10.2.3.4/32 -m comment -j ACCEPT –comment “Allow access to web server”
iptables -I INPUT -m tcp -p tcp –dport 3306 -i eth0 -s 10.2.3.5/32 -m comment -j ACCEPT –comment “Allow access to MySQL-ZRM server”
Where –dport is destination port, -i eth0 is the interface where you want the filter to be active (you may skip it and it will be active in all the interfaces), -s IP are the allowed IPs, and -j ACCEPT is the target for the rule, in this case ACCEPT the package.
MySQL-ZRM uses cron to do the backups, so the frequency is the one defined in the cron entry, many just use root crontab to do everything, although this is possible it’s not the most correct way of doing it.
Again there are multiple possibilities of doing this:
For a once a day backup of your database you would need to create the following file:
/etc/cron.d/mysql-zrm
With the following content:
0 1 * * * root /usr/bin/zrm-pre-scheduler –action backup –backup-set `hostname -s` –backup-level 0 –interval daily
0 3 * * * root /usr/bin/mysql-zrm –action purge
This will trigger a backup every night at 1:00 AM, and it will also trigger a purge of the old content at 3:00 AM, please not that if you’re backing up another server than localhost you should replace hostname -s for the FQDN of the desired server.
Integration may be achieve by 2 distinct means:
I’ll focus on the second option as the first one is enabled by default if you include the destination in the folders to be backed up by BackupPC.
Edit your /etc/cron.d/mysql-zrm like this:
0 3 * * * root /usr/bin/mysql-zrm –action purge
As you see the there’s one entry that is missing, the command execution will be triggered by BackupPC.
I’ll assume you already have your BackupPC server configured and that the destination folder is already in the path to be backed up.
mysql-zrm-backup -backup-set `hostname -s` –backup-level 0
Setting up MySQL backups is not a hard task, there are a multitude of options out there this is just one of them. I would recommend you guys to have a deep look at the official BackupPC and MySQL-ZRM documentation. This post touches just the surface of what those two pieces of software can do.
As important as doing backups is a good test on recovering the data to the desired state, it’s not enough to be able to list the backup content, you should be able to restore the full service, then you must check if you are able to do it from a full backup, then do it based on and differential or incremental backup. It’s also important to know what are those and be “fluent” with the backup software. This may be the difference between a headache and getting your head cut.
Keep calm and keep your backups up to date!
Pedro M. S. Oliveira
If you see that your server is running out of swap you should add more RAM, nevertheless this is not always possible or maybe you need that extra amount for a very specific usage.
If this is the case you just need to add some more swap to your system. There are several usage cases I’ll just cover the 2 most common ones, with and without LVM.
If you’re not using LVM and you don’t have any other location to put your new swap partition you can do it in one of the file systems available in the system.
dd if=/dev/zero of=/extra_swap.fs count=16000 bs=1048576
mkswap /extra_swap.fs
chmod 600 /extra_swap.fs; chown root:root /extra_swap.fs
swapon /extra_swap.fs
echo “/extra_swap swap swap defaults 0 0 ” >> /etc/fstab
This method applies if you have LVM and you’re not able to disable swap (for instance production servers that have a high system load and memory usage)
lvcreate -n extra_swap_lv -L16G VolumeGroupName
mkswap /dev/VolumeGroupName/extra_swap_lv
swapon /dev/VolumeGroupName/extra_swap_lv
echo ” /dev/VolumeGroupName/extra_swap_lv swap swap defaults 0 0 ” >> /etc/fstab
If you are able to disable swap for a while (<10minutes) this is the recommended method.
swapoff swap_volume_name
lvextend -L+16G swap_volume_name
mkswap /dev/VolumeGroupName/swap_volume_name
swapon /dev/VolumeGroupName/swap_volume_name
Check the excellent REHL manual about swap.
I hope you don’t have to go through this, as said before the best is to buy some new ram.
Cheers,
Pedro M. S. Oliveira
When you have large deployments with thousands of SSDs and spinning disks megacli utility provides a great help by having all the features and options available in a way that can be easily scripted and therefore automated.
This usage listing just has the most used and therefore limited set of options, but many more exist, please check the bottom for references.
Here are a few of those I find more useful, this will only apply to LSI Raid controllers.
megacli -PDList -a0
megacli -PDList -a0 | grep “Slot\|Error”
megacli -LDInfo -L1 -a0
megacli -LDGetProp Consistency -L1 -a0
megacli -LDRecon ShowProg L2 -a0
megacli -GetPreservedCacheList -a0
megacli -AdpAutoRbld -Dsply -a0
megacli -PdGetMissing -a0
megacli -AdpEventLog -GetSinceReboot -f megacli_events_since_reboot -aALL
megacli -AdpEventLog -GetSinceShutdown -f megacli_events_since_shutdown -aALL
megacli -pdrbld -showprog -physdrv[32:21] -aALL
megacli -AdpSetProp RebuildRate 60 -a0
megacli -DiscardPreservedCache -Lall -a0
megacli -PDOffline -PhysDrv [32:2] -a0
megacli -PDOnline -PhysDrv [32:2] -a0
megacli -PDMakeGood -PhysDrv[32:2] -a0
MegaCli -PDMarkMissing -PhysDrv [32:2] -a0
MegaCli -PdPrpRmv -PhysDrv [32:2] -a0
You may find more information on the missing drive with the option -PdGetMissing (explained above).
megacli -PdReplaceMissing -physdrv [32:2] -Array=2 -row=2 -a0
megacli -PDRbld -Start -PhysDrv[32:2] -a0
megacli -CfgLdAdd -r0[32:5] -a0
megacli -PDHSP -Set -Dedicated -Array1 -PhysDrv[32:18] -a0
megacli -PDHSP -Rmv -PhysDrv[32:6] -a0
megacli -PDOffline -PhysDrv [32:18] -a0
megacli -LDRecon start r6 -Add-PhysDrv[32:14,32:15,32:16,32:17,32:18,32:19,32:20,32:21] L2 -a0
* firmware upgrade can brick your device, first make your drive offline, this is MANDATORY if the drive is online
megacli -PDOffline -PhysDrv [1:18] -a0
megacli -PdFwDownload -PhysDrv[32:18] -f fw.bin -a0
megacli -PDOnline -PhysDrv [32:18] -a0
echo 1 > /sys/block/sdx/device/rescan
http://hwraid.le-vert.net/wiki/LSIMegaRAIDSAS
http://mycusthelp.info/LSI/_cs/AnswerPreview.aspx?sSessionID=&inc=8275
http://artipc10.vub.ac.be/wordpress/2011/09/12/megacli-useful-commands/
Cheers,
Pedro M. S. Oliveira