Booking.com guys thought a sparkling thought: “if the only purpose of master is to serve binlogs… why should it be a full-featured DB instance?”. So they got themselves a different approach: http://blog.booking.com/mysql_slave_scaling_and_more.html
A neat approach with many benefits. Two things to mention:
- this is a concern when the common replication technique starts being a PITA (with GTID, promoting a new master in MySQL shouldn’t be a problem). So this is not what you should rush for for your 2-slave setup
- this approach applies to pretty much any replication task – not necessarily MySQL, not even necessarily DB replication at all
Anyways, nice idea to remember.
This one is another FTR: stress-testing with Siege is a breeze! Here are two cites from http://blog.remarkablelabs.com/2012/11/benchmarking-and-load-testing-with-siege:
You can have this benchmark run forever, or you can specify a specific period of time. To set the duration of the test, use the
-t NUMm option. The NUMm format is a representation of time. Here are some time format examples:
- -t60S (60 seconds)
- -t1H (1 hour)
- -t120M (120 minutes)
To demonstrate running a benchmark, let’s run Siege against this blog:
siege -b -t60S http://blog.remarkablelabs.com
and then also “user emulation”:
When creating a load test, you should set the
-c NUM options. The
-d NUM option sets a random interval between 0 and NUM that each “user” will sleep for between requests. While the
-c NUM option sets the concurrent number of simulated users.
Here is an example of a load test of a Heroku application:
$ siege -c50 -d10 -t3M http://some.application.com
and you could use custom headers (think cookies) with -H.
And what’s even better, it’s widely available – I’ve installed it on Mac through Ports (although it’s on brew as well) and then unpacked it from RPM on my GoDaddy SSH shell account (because I couldn’t just go and install it there). It worked well in both cases.
This was hanging around in my Keep for quite a while – right till I realized that I need it somewhere for a quick reference, although it just messes my Keep flow. Thus posting it here in a “JFTR” fashion.
Data access latencies:
L1 cache reference ……………………. 0.5 ns
Branch mispredict ………………………. 5 ns
L2 cache reference ……………………… 7 ns
Mutex lock/unlock ……………………… 25 ns
Main memory reference …………………. 100 ns
Compress 1K bytes with Zippy …………. 3,000 ns = 3 µs
SSD random read …………………… 150,000 ns = 150 µs
Read 1 MB sequentially from memory ….. 250,000 ns = 250 µs
Round trip within same datacenter …… 500,000 ns = 0.5 ms
Read 1 MB sequentially from SSD ….. 1,000,000 ns = 1 ms
Send 1MB over 1 Gbps network ……. 10,000,000 ns = 10 ms
Disk seek ……………………… 10,000,000 ns = 10 ms
Read 1 MB sequentially from disk …. 20,000,000 ns = 20 ms
Send packet CA->Netherlands->CA …. 150,000,000 ns = 150 ms
MySQL Storage Requirement per Data Type:
TINYINT – 1 byte (BOOL is an alias for this)
SMALLINT – 2 bytes
MEDIUMINT – 3 bytes
INT, INTEGER – 4 bytes
BIGINT – 8 bytes
FLOAT(p) – 4 bytes if 0 <= p <= 24, 8 bytes if 25 <= p <= 53
FLOAT – 4 bytes
DOUBLE [PRECISION], REAL – 8 bytes
DECIMAL(M,D), NUMERIC(M,D) – Varies
BIT(M) – approximately (M+7)/8 bytes
This is an extra brief scrape of a net communication layers – just to keep it around to look at. To understand the difference in Layer 4 / Layer 7 DDOS attacks.
7 – Application Layer. Constructing appropriate data that another application that supports same protocol would understand. Generally by using “Layer 7” term it’s common to combine layers 5-7.
6 – Presentation Layer. A bit less fuzzy – represents compression, encryption, encoding etc.
5 – Session Layer. Generally to establish a bond between sides for further communication. Quite fuzzy.
4 – Transport Layer. TCP, generally. Establishes and manages connection, controls flow, retransmissions. TCP connection: client sends SYN, server responds with that SYN and new ACK, client sends over that ACK and a new ACK.
3 – Network Layer. Logical addressing, routing. ICMP.
2 – Data Link Layer. Ethernex, WiFi (802.11), all that jazz. Responsible for Logical Link Control, data framing (putting into proper frames), addressing
1 – Physical Layer. Establishing hardware specification, encoding/decoding signals, transmitting signals. The only layer that actually transfers data.
This is a “you learn better when you write it down” sort of post. Never actually got into DNS record types – as a lot of things I’ve missed, there was just no need and I wasn’t curious enough. Although curiosity without regular application of that knowledge is rather pointless – “you soon will forget the tune that you play”, if you play it just once or twice.
That said, I’m gonna be needing this knowledge soon (I presume), so I thought I better do me a hint page (a “crib sheet”, as the dictionary suggests).
- A record – “Address”, a connection of a name to an IP address like, for instance, “example.com. IN A 18.104.22.168” – where IN is for the Internet, i.e. “Internet Address…” Wildcards could be used for “all subdomains”
- AAAA – “four times the size”, A-address for IPV6 addresses (see a note on IPV6 below)
- CNAME – Canonical Name, specifies an alias for existing A record, like “subdomain.example.com CNAME example.com“. Useful to make sure you only have one IP address in A record, and others rely on A name – so if IP changes, it’s one place you have to change it at. Note: do not use CNAME aliases in MX records.
- MX – Mail eXchange, specifies which server serves zone’s mail exchange purposes – like, for instance, “mydomain.com IN MX 0 mydomain.com.“; final dot is important, 0 is for priority: ther could be multiple MX records for the zone, and they processed in priority order (the lower the number the higher the priority). Same-priority records are processes in random order. Right-side name should be an A record.
- PTR – specify pointer for a reverse DNS lookup, required to validate hostname identity in some cases – “22.214.171.124.in-addr.arpa. IN PTR name.net” (note that IP of name.net is 126.96.36.199)
- NS – Name Server, specifies a (list of) authoritative DNS server for the domain, for instance: “example.com. IN NS ns1.live.secure.com“. This should be specified at authoritative server as well.
- SOA – State Of Authority, an important record with zone’s name server details – “authoritative information about an Internet domain, the email of the domain administrator, the domain serial number, and several timers relating to refreshing the zone“. Example: mydomain.com. 14400 IN SOA ns.mynameserver.com. root.ns.mynameserver.com. (
2004123001 ; Serial number
86000 ; Refresh rate in seconds
7200 ; Update Retry in seconds
3600000 ; Expiry in seconds
600 ; minimum in seconds )
- SRV – an option to specify a server for a Service, like “_http._tcp.example.com. IN SRV 0 5 80 www.example.com.” – here’s the service name (_http), priority (0), weight (5) for services with the same priority, and port (80) for the service.
- NAPTR – recent and complex regexp-based name resolution I’m not keen to into.
- There’s MUCH MORE of this crap, hope I won’t need to ever dig that deep
- There’s also a number of decentralized DNS initiatives
Oh, and on IPV6:
- it’s 128-bit (IPV4 is 32)
- it’s recorded in hex numbers, 8 quads
- it has following structure:
global prefix subnet Interface ID
- local address is 0000:0000:0000:0000:0000:0000:0000:0001
- and IPV4 record in that case would look like 0000:0000:0000:0000:0000:0000:192.168.1.25
- zeroes could be omitted: ::1 or ::192.168.1.25
- to make sure address is shortened correctly, use ipv6calc util: ipv6calc –in ipv6addr –out ipv6addr –printuncompressed ::1