zealfire

URL: https://www.percona.com/blog/2013/01/09/how-does-mysql-replication-really-work/

How does MySQL Replication really work?
Aurimas Mikalauskas  | January 9, 2013 |  Posted In: Insight for DBAs, MySQL, Replication

While we do have many blog posts on replication on our blog, such as on replication being single-threaded, on semi-synchronous replication or on estimating replication capacity, I don’t think we have one that covers the very basics of how MySQL replication really works on the high level. Or it’s been so long ago I can’t even find it. So, I decided to write one now.

Of course, there are many aspects of MySQL replication, but my main focus will be the logistics – how replication events are written on the master, how they are transferred to the replication slave and then how they are applied there. Note that this is NOT a HOWTO setup replication, but rather a howstuffworks type of thing.

Replication events

zealfire

Logical volume mangaer is widely used technique for deploying logical rather than physical storage. With LVM "logical" partitons can span across physical harddrive and can be resized.

So, in days when techonology was not so advanced, need to store data was less and hence we had physical drives of smaller size but with advance in technology the need to  store data grew and hence the size of the physical  drive so they were stacked one over the other to incress the size of storage. The problem with this was if i had a physical volume 0f 40gb stacked over another 40gb i will be not be able to store continuos data which extend upto 60gb and for that we need a hardrive of 80gb. This was costly job.

So they come up "LVM" which allows mutiple harddrive to combine into one,fooling OS that we are actually using single hard drive instead of mutilple so the OS can span a data across a multiple hard drive thinking as one and this reduce the need of purcahsing new hard drive.

So these physical drive are called "Physica

zealfire

Strace is a debugging tool that will help you troubleshoot issues.

Strace monitors the system calls and signals of a specific program. It is helpful when you do not have the source code and would like to debug the execution of a program. strace provides you the execution sequence of a binary from start to end.

This article explains 7 strace examples to get you started.

1. Trace the Execution of an Executable
You can use strace command to trace the execution of any executable. The following example shows the output of strace for the Linux ls command.

$  strace ls

zealfire

DMG stands for Apple Disk Image. These are treated like a Volume of their own, but one that's contained in that file. Volumes on a Mac are basically any physical or virtual disk that can be mounted permanently or temporarily. The hard drive icon you see on your desktop (probably Macintosh HD unless you renamed it) is a volume. You can clone one volume to another easily, whether it be physical or virtual. This is one of the features that makes a Mac so powerful.

These volumes are "mounted" or "unmounted" on the Mac OS. This is similar to Windows in that when a removable drive is plugged it, it's automatically assigned a drive letter (E:)... in other words, it's mounted. When you "safely remove" it, you're unmounting it. You must always unmount a drive on the Mac OS before removing it, whether it be physical or virtual.

A DMG is similar to any other compressed file, like ZIP in Windows, but more powerful on the Mac OS. The DMG is a self contained volume formated HFS+ that retains file system attributes that a

zealfire

git rev-list --all | xargs git grep expression
find /path/to/ -type f -mtime +7 -name '*.gz' -execdir rm -- '{}' \;

zealfire

/etc/init.d contains scripts used by the System V init tools (SysVinit). This is the traditional service management package for Linux, containing the init program (the first process that is run when the kernel has finished initializing¹) as well as some infrastructure to start and stop services and configure them. Specifically, files in /etc/init.d are shell scripts that respond to start, stop, restart, and (when supported) reload commands to manage a particular service. These scripts can be invoked directly or (most commonly) via some other trigger (typically the presence of a symbolic link in /etc/rc?.d/).

/etc/init contains configuration files used by Upstart. Upstart is a young service management package championed by Ubuntu. Files in /etc/init are configuration files telling Upstart how and when to start, stop, reload the configuration, or query the status of a service. As of lucid, Ubuntu is transitioning from SysVinit to Upstart, which explains why many services come with SysVinit scripts even though 

zealfire

Active Directory (AD) is a Windows OS directory service that facilitates working with interconnected, complex and different network resources in a unified manner.

Active Directory was initially released with Windows 2000 Server and revised with additional features in Windows Server 2008. Active Directory provides a common interface for organizing and maintaining information related to resources connected to a variety of network directories. The directories may be systems-based (like Windows OS), application-specific or network resources, like printers. Active Directory serves as a single data store for quick data access to all users and controls access for users based on the directory's security policy.

zealfire

Sending signals to processes using kill on a Unix system is not a new topic for most systems administrators, but I’ve been asked many times about the difference between kill and kill -9.

Anytime you use kill on a process, you’re actually sending the process a signal (in almost all situations – I’ll get into that soon). Standard C applications have a header file that contains the steps that the process should follow if it receives a particular signal. You can get an entire list of the available signals on your system by checking the man page for kill.

Consider a command like this:


kill 2563
1
kill 2563

zealfire

Uninterruptible sleep
An uninterruptible sleep state is a sleep state that won't handle a signal right away. It will wake only as a result of a waited-upon resource becoming available or after a time-out occurs during that wait (if specified when put to sleep). It is mostly used by device drivers waiting for disk or network IO (input/output). When the process is sleeping uninterruptibly, signals accumulated during the sleep will be noticed when the process returns from the system call or trap.

In Unix-like systems the command 'ps -l' uses code "D" for the uninterruptible sleep state of a process.[7] Such processes cannot be killed even with SIGKILL and the only non-sophisticated way to get rid of them is to reboot the system.[

zealfire

http://patshaughnessy.net/2012/2/15/is-ruby-interpreted-or-compiled
Main  difference between JIT and JVM is that, JIT is part of JVM itself and  used to improve performance of JVM. JIT stands for Just In time  compilation and JVM stands for Java Virtual Machine. JVM is a virtual machine used in  Java programming platform to execute or run Java programs. Main advantage of  JVM is that, it makes Java platform independent by executing byte codes. Java source code is compiled into class files, which contains byte code. These byte codes are then executed by JVM. Now here comes JIT. Since execution of byte code is slower than execution of machine language code, because JVM first needs to translate byte code into machine language code. JIT helps JVM here by compiling currently executing byte code into machine language. JIT also offers caching of compiled code which result in improved performance of JVM. by the way difference between JVM and JIT is also a good Java interview question to ask. Well, this is just a simp