{"config":{"lang":["en"],"separator":"[\\s\\-]+","pipeline":["stopWordFilter"]},"docs":[{"location":"","title":"School of SRE","text":"

Site Reliability Engineers (SREs) sits at the intersection of software engineering and systems engineering. While there are potentially infinite permutations and combinations of how infrastructure and software components can be put together to achieve an objective, focusing on foundational skills allows SREs to work with complex systems and software, regardless of whether these systems are proprietary, 3rd party, open systems, run on cloud/on-prem infrastructure, etc. Particularly, it is important to gain a deep understanding of how these areas of systems and infrastructure relate to each other and interact with each other. The combination of software and systems engineering skills is rare and is generally built over time with exposure to a wide variety of infrastructure, systems, and software.

SREs bring in engineering practices to keep the site up. Each distributed system is an agglomeration of many components. SREs validate business requirements, convert them to SLAs for each of the components that constitute the distributed system, monitor and measure adherence to SLAs, re-architect or scale out to mitigate or avoid SLA breaches, add these learnings as feedback to new systems or projects and thereby reduce operational toil. Hence SREs play a vital role right from the day 0 design of the system.

In early 2019, we started visiting campuses across India to recruit the best and brightest minds to make sure LinkedIn and all the services that make up its complex technology stack are always available for everyone. This critical function at LinkedIn falls under the purview of the Site Engineering team and Site Reliability Engineers (SREs) who are Software Engineers, specialized in reliability.

As we continued on this journey, we started getting a lot of questions from these campuses on what exactly the site reliability engineering role entails? And, how could someone learn the skills and the disciplines involved to become a successful site reliability engineer? Fast forward a few months, and a few of these campus students had joined LinkedIn either as interns or as full-time engineers to become a part of the Site Engineering team; we also had a few lateral hires who joined our organization who were not from a traditional SRE background. That's when a few of us got together and started to think about how we can onboard new graduate engineers to the Site Engineering team.

There are very few resources out there guiding someone on the basic skill sets one has to acquire as a beginner SRE. Because of the lack of these resources, we felt that individuals have a tough time getting into open positions in the industry. We created the School Of SRE as a starting point for anyone wanting to build their career as an SRE. In this course, we are focusing on building strong foundational skills. The course is structured in a way to provide more real life examples and how learning each of these topics can play an important role in day-to-day job responsibilities of an SRE. Currently, we are covering the following topics under the School Of SRE:

We believe continuous learning will help in acquiring deeper knowledge and competencies in order to expand your skill sets, every module has added references that could be a guide for further learning. Our hope is that by going through these modules we should be able to build the essential skills required for a Site Reliability Engineer.

At LinkedIn, we are using this curriculum for onboarding our non-traditional hires and new college grads into the SRE role. We had multiple rounds of successful onboarding experiences with new employees and the course helped them be productive in a very short period of time. This motivated us to open source the content for helping other organizations in onboarding new engineers into the role and provide guidance for aspiring individuals to get into the role. We realize that the initial content we created is just a starting point and we hope that the community can help in the journey of refining and expanding the content. Check out the contributing guide to get started.

"},{"location":"CODE_OF_CONDUCT/","title":"Code of Conduct","text":"

This code of conduct outlines expectations for participation in LinkedIn-managed open source communities, as well as steps for reporting unacceptable behavior. We are committed to providing a welcoming and inspiring community for all. People violating this code of conduct may be banned from the community.

Our open source communities strive to:

"},{"location":"CODE_OF_CONDUCT/#scope","title":"Scope","text":"

This code of conduct applies to all repos and communities for LinkedIn-managed open source projects regardless of whether or not the repo explicitly calls out its use of this code. The code also applies in public spaces when an individual is representing a project or its community. Examples include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers.

Note: Some LinkedIn-managed communities have codes of conduct that pre-date this document and issue resolution process. While communities are not required to change their code, they are expected to use the resolution process outlined here. The review team will coordinate with the communities involved to address your concerns.

"},{"location":"CODE_OF_CONDUCT/#reporting-code-of-conduct-issues","title":"Reporting Code of Conduct Issues","text":"

We encourage all communities to resolve issues on their own whenever possible. This builds a broader and deeper understanding and ultimately a healthier interaction. In the event that an issue cannot be resolved locally, please feel free to report your concerns by contacting oss@linkedin.com.

In your report, please include:

All reports will be reviewed by a multi-person team and will result in a response that is deemed necessary and appropriate to the circumstances. Where additional perspectives are needed, the team may seek insight from others with relevant expertise or experience. The confidentiality of the person reporting the incident will be kept at all times. Involved parties are never part of the review team.

Anyone asked to stop unacceptable behavior is expected to comply immediately. If an individual engages in unacceptable behavior, the review team may take any action they deem appropriate, including a permanent ban from the community.

This code of conduct is based on the Microsoft Open Source Code of Conduct which was based on the template established by the TODO Group and used by numerous other large communities (e.g., Facebook, Yahoo, Twitter, GitHub) and the Scope section from the Contributor Covenant version 1.4.

"},{"location":"CONTRIBUTING/","title":"Contribute","text":"

We realise that the initial content we created is just a starting point and our hope is that the community can help in the journey refining and extending the contents.

As a contributor, you represent that the content you submit is not plagiarised. By submitting the content, you (and, if applicable, your employer) are licensing the submitted content to LinkedIn and the open source community subject to the Creative Commons Attribution 4.0 International Public License.

Repository URL: https://github.com/linkedin/school-of-sre

"},{"location":"CONTRIBUTING/#contributing-guidelines","title":"Contributing Guidelines","text":"

Ensure that you adhere to the following guidelines:

"},{"location":"CONTRIBUTING/#building-and-testing-locally","title":"Building and testing locally","text":"

Run the following commands to build and view the site locally before opening a PR.

python3 -m venv .venv\nsource .venv/bin/activate\npip install -r requirements.txt\nmkdocs build\nmkdocs serve\n
"},{"location":"CONTRIBUTING/#opening-a-pr","title":"Opening a PR","text":"

Follow the GitHub PR workflow for your contributions.

Fork this repo, create a feature branch, commit your changes and open a PR to this repo.

"},{"location":"sre_community/","title":"SRE Community","text":"

We are having an active LinkedIn community for School of SRE.

Please join the group via: https://www.linkedin.com/groups/12493545/

The group has members with different levels of experience in site reliability engineering. There are active conversation on different technical topics centered around site reliability engineering. We encourage everyone to join the conversation and learn from each other and build a successful career in the SRE space.

"},{"location":"level101/big_data/evolution/","title":"Evolution of Hadoop","text":""},{"location":"level101/big_data/evolution/#architecture-of-hadoop","title":"Architecture of Hadoop","text":"
  1. HDFS

    1. The Hadoop Distributed File System (HDFS) is a distributed file system designed to run on commodity hardware. It has many similarities with existing distributed file systems. However, the differences from other distributed file systems are significant.
    2. HDFS is highly fault-tolerant and is designed to be deployed on low-cost hardware. HDFS provides high throughput access to application data and is suitable for applications that have large datasets.
    3. HDFS is part of the Apache Hadoop Core project.

    The main components of HDFS include: 1. NameNode: is the arbitrator and central repository of file namespace in the cluster. The NameNode executes the operations such as opening, closing, and renaming files and directories. 2. DataNode: manages the storage attached to the node on which it runs. It is responsible for serving all the read and writes requests. It performs operations on instructions on NameNode such as creation, deletion, and replications of blocks. 3. Client: Responsible for getting the required metadata from the NameNode and then communicating with the DataNodes for reads and writes.

  2. YARN YARN stands for \u201cYet Another Resource Negotiator\u201c. It was introduced in Hadoop 2.0 to remove the bottleneck on Job Tracker which was present in Hadoop 1.0. YARN was described as a \u201cRedesigned Resource Manager\u201d at the time of its launching, but it has now evolved to be known as a large-scale distributed operating system used for Big Data processing.

    The main components of YARN architecture include: 1. Client: It submits map-reduce (MR) jobs to the resource manager. 2. Resource Manager: It is the master daemon of YARN and is responsible for resource assignment and management among all the applications. Whenever it receives a processing request, it forwards it to the corresponding node manager and allocates resources for the completion of the request accordingly. It has two major components: 1. Scheduler: It performs scheduling based on the allocated application and available resources. It is a pure scheduler, which means that it does not perform other tasks such as monitoring or tracking and does not guarantee a restart if a task fails. The YARN scheduler supports plugins such as Capacity Scheduler and Fair Scheduler to partition the cluster resources. 2. Application manager: It is responsible for accepting the application and negotiating the first container from the resource manager. It also restarts the Application Manager container if a task fails. 3. Node Manager: It takes care of individual nodes on the Hadoop cluster and manages application and workflow and that particular node. Its primary job is to keep up with the Node Manager. It monitors resource usage, performs log management, and also kills a container based on directions from the resource manager. It is also responsible for creating the container process and starting it at the request of the Application master. 4. Application Master: An application is a single job submitted to a framework. The application manager is responsible for negotiating resources with the resource manager, tracking the status, and monitoring the progress of a single application. The application master requests the container from the node manager by sending a Container Launch Context (CLC) which includes everything an application needs to run. Once the application is started, it sends the health report to the resource manager from time-to-time. 5. Container: It is a collection of physical resources such as RAM, CPU cores, and disk on a single node. The containers are invoked by Container Launch Context (CLC) which is a record that contains information such as environment variables, security tokens, dependencies, etc.

"},{"location":"level101/big_data/evolution/#mapreduce-framework","title":"MapReduce framework","text":"
  1. The term MapReduce represents two separate and distinct tasks Hadoop programs perform\u2014Map Job and Reduce Job. Map jobs take datasets as input and process them to produce key-value pairs. Reduce job takes the output of the Map job i.e. the key-value pairs and aggregates them to produce desired results.
  2. Hadoop MapReduce (Hadoop Map/Reduce) is a software framework for distributed processing of large datasets on computing clusters. MapReduce helps to split the input dataset into a number of parts and run a program on all data parts parallel at once.
  3. Please find the below Word count example demonstrating the usage of the MapReduce framework:
"},{"location":"level101/big_data/evolution/#other-tooling-around-hadoop","title":"Other tooling around Hadoop","text":"
  1. Hive
    1. Uses a language called HQL which is very SQL like. Gives non-programmers the ability to query and analyze data in Hadoop. Is basically an abstraction layer on top of map-reduce.
    2. Ex. HQL query:
      1. SELECT pet.name, comment FROM pet JOIN event ON (pet.name = event.name);
    3. In mysql:
      1. SELECT pet.name, comment FROM pet, event WHERE pet.name = event.name;
  2. Pig

    1. Uses a scripting language called Pig Latin, which is more workflow driven. Don't need to be an expert Java programmer but need a few coding skills. Is also an abstraction layer on top of map-reduce.
    2. Here is a quick question for you: What is the output of running the Pig queries in the right column against the data present in the left column in the below image?

    Output:

    \n7,Komal,Nayak,24,9848022334,trivendram\n8,Bharathi,Nambiayar,24,9848022333,Chennai\n5,Trupthi,Mohanthy,23,9848022336,Bhuwaneshwar\n6,Archana,Mishra,23,9848022335,Chennai\n

  3. Spark

    1. Spark provides primitives for in-memory cluster computing that allows user programs to load data into a cluster\u2019s memory and query it repeatedly, making it well-suited to machine learning algorithms.
  4. Presto
    1. Presto is a high performance, distributed SQL query engine for Big Data.
    2. Its architecture allows users to query a variety of data sources such as Hadoop, AWS S3, Alluxio, MySQL, Cassandra, Kafka, and MongoDB.
    3. Example Presto query:
      \nUSE studentDB;\nSHOW TABLES;\nSELECT roll_no, name FROM studentDB.studentDetails WHERE section=\u2019A\u2019 LIMIT 5;\n

"},{"location":"level101/big_data/evolution/#data-serialisation-and-storage","title":"Data Serialisation and storage","text":"
  1. In order to transport the data over the network or to store on some persistent storage, we use the process of translating data structures or objects state into binary or textual form. We call this process serialization.
  2. Avro data is stored in a container file (a .avro file) and its schema (the .avsc file) is stored with the data file.
  3. Apache Hive provides support to store a table as Avro and can also query data in this serialisation format.
"},{"location":"level101/big_data/intro/","title":"Big Data","text":""},{"location":"level101/big_data/intro/#prerequisites","title":"Prerequisites","text":""},{"location":"level101/big_data/intro/#what-to-expect-from-this-course","title":"What to expect from this course","text":"

This course covers the basics of Big Data and how it has evolved to become what it is today. We will take a look at a few realistic scenarios where Big Data would be a perfect fit. An interesting assignment on designing a Big Data system is followed by understanding the architecture of Hadoop and the tooling around it.

"},{"location":"level101/big_data/intro/#what-is-not-covered-under-this-course","title":"What is not covered under this course","text":"

Writing programs to draw analytics from data.

"},{"location":"level101/big_data/intro/#course-contents","title":"Course Contents","text":"
  1. Overview of Big Data
  2. Usage of Big Data Techniques
  3. Evolution of Hadoop
  4. Architecture of Hadoop
    1. HDFS
    2. Yarn
  5. MapReduce Framework
  6. Other Tooling Around Hadoop
    1. Hive
    2. Pig
    3. Spark
    4. Presto
  7. Data Serialization and Storage
"},{"location":"level101/big_data/intro/#overview-of-big-data","title":"Overview of Big Data","text":"
  1. Big Data is a collection of large datasets that cannot be processed using traditional computing techniques. It is not a single technique or a tool, rather it has become a complete subject, which involves various tools, techniques, and frameworks.
  2. Big Data could consist of
    1. Structured data
    2. Unstructured data
    3. Semi-structured data
  3. Characteristics of Big Data:
    1. Volume
    2. Variety
    3. Velocity
    4. Variability
  4. Examples of Big Data generation include stock exchanges, social media sites, jet engines, etc.
"},{"location":"level101/big_data/intro/#usage-of-big-data-techniques","title":"Usage of Big Data Techniques","text":"
  1. Take the example of the traffic lights problem.
    1. There are more than 300,000 traffic lights in the US as of 2018.
    2. Let us assume that we placed a device on each of them to collect metrics and send it to a central metrics collection system.
    3. If each of the IoT devices sends 10 events per minute, we have 300000 x 10 x 60 x 24 = 432 x 10 ^ 7 events per day.
    4. How would you go about processing that and telling me how many of the signals were \u201cgreen\u201d at 10:45 am on a particular day?
  2. Consider the next example on Unified Payments Interface (UPI) transactions:
    1. We had about 1.15 billion UPI transactions in the month of October 2019 in India.
    2. If we try to extrapolate this data to about a year and try to find out some common payments that were happening through a particular UPI ID, how do you suggest we go about that?
"},{"location":"level101/big_data/tasks/","title":"Tasks and conclusion","text":""},{"location":"level101/big_data/tasks/#post-training-tasks","title":"Post-training tasks:","text":"
  1. Try setting up your own three-node Hadoop cluster.
    1. A VM-based solution can be found here
  2. Write a simple Spark/MR job of your choice and understand how to generate analytics from data.
    1. Sample dataset can be found here
"},{"location":"level101/big_data/tasks/#references","title":"References:","text":"
  1. Hadoop documentation
  2. HDFS Architecture
  3. YARN Architecture
  4. Google GFS paper
"},{"location":"level101/databases_nosql/further_reading/","title":"Conclusion","text":"

We have covered basic concepts of NoSQL databases. There is much more to learn and do. We hope this course gives you a good start and inspires you to explore further.

"},{"location":"level101/databases_nosql/further_reading/#further-reading","title":"Further reading","text":"

NoSQL:

https://hostingdata.co.uk/nosql-database/

https://www.mongodb.com/nosql-explained

https://www.mongodb.com/nosql-explained/nosql-vs-sql

Cap Theorem

http://www.julianbrowne.com/article/brewers-cap-theorem

Scalability

http://www.slideshare.net/jboner/scalability-availability-stability-patterns

Eventual Consistency

https://www.allthingsdistributed.com/2008/12/eventually_consistent.html

https://www.toptal.com/big-data/consistent-hashing

https://web.stanford.edu/class/cs244/papers/chord_TON_2003.pdf

"},{"location":"level101/databases_nosql/intro/","title":"NoSQL Concepts","text":""},{"location":"level101/databases_nosql/intro/#prerequisites","title":"Prerequisites","text":""},{"location":"level101/databases_nosql/intro/#what-to-expect-from-this-course","title":"What to expect from this course","text":"

At the end of training, you will have an understanding of what a NoSQL database is, what kind of advantages or disadvantages it has over traditional RDBMS, learn about different types of NoSQL databases and understand some of the underlying concepts & trade-offs w.r.t to NoSQL.

"},{"location":"level101/databases_nosql/intro/#what-is-not-covered-under-this-course","title":"What is not covered under this course","text":"

We will not be deep diving into any specific NoSQL database.

"},{"location":"level101/databases_nosql/intro/#course-contents","title":"Course Contents","text":""},{"location":"level101/databases_nosql/intro/#introduction","title":"Introduction","text":"

When people use the term \u201cNoSQL database\u201d, they typically use it to refer to any non-relational database. Some say the term \u201cNoSQL\u201d stands for \u201cnon SQL\u201d while others say it stands for \u201cnot only SQL.\u201d Either way, most agree that NoSQL databases are databases that store data in a format other than relational tables.

A common misconception is that NoSQL databases or non-relational databases don\u2019t store relationship data well. NoSQL databases can store relationship data\u2014they just store it differently than relational databases do. In fact, when compared with SQL databases, many find modeling relationship data in NoSQL databases to be easier, because related data doesn\u2019t have to be split between tables.

Such databases have existed since the late 1960s, but the name \"NoSQL\" was only coined in the early 21st century. NASA used a NoSQL database to track inventory for the Apollo mission. NoSQL databases emerged in the late 2000s as the cost of storage dramatically decreased. Gone were the days of needing to create a complex, difficult-to-manage data model simply for the purposes of reducing data duplication. Developers (rather than storage) were becoming the primary cost of software development, so NoSQL databases optimized for developer productivity. With the rise of Agile development methodology, NoSQL databases were developed with a focus on scaling, fast performance and at the same time allowed for frequent application changes and made programming easier.

"},{"location":"level101/databases_nosql/intro/#types-of-nosql-databases","title":"Types of NoSQL databases:","text":"

Over time due to the way these NoSQL databases were developed to suit requirements at different companies, we ended up with quite a few types of them. However, they can be broadly classified into 4 types. Some of the databases can overlap between different types. They are:

  1. Document databases: They store data in documents similar to JSON (JavaScript Object Notation) objects. Each document contains pairs of fields and values. The values can typically be a variety of types including things like strings, numbers, booleans, arrays, or objects, and their structures typically align with objects developers are working with in code. The advantages include intuitive data model & flexible schemas. Because of their variety of field value types and powerful query languages, document databases are great for a wide variety of use cases and can be used as a general purpose database. They can horizontally scale-out to accomodate large data volumes. Ex: MongoDB, Couchbase

  2. Key-Value databases: These are a simpler type of databases where each item contains keys and values. A value can typically only be retrieved by referencing its key, so learning how to query for a specific key-value pair is typically simple. Key-value databases are great for use cases where you need to store large amounts of data but you don\u2019t need to perform complex queries to retrieve it. Common use cases include storing user preferences or caching. Ex: Redis, DynamoDB, Voldemort/Venice (Linkedin).

  3. Wide-Column stores: They store data in tables, rows, and dynamic columns. Wide-column stores provide a lot of flexibility over relational databases because each row is not required to have the same columns. Many consider wide-column stores to be two-dimensional key-value databases. Wide-column stores are great for when you need to store large amounts of data and you can predict what your query patterns will be. Wide-column stores are commonly used for storing Internet of Things data and user profile data. Cassandra and HBase are two of the most popular wide-column stores.

  4. Graph Databases: These databases store data in nodes and edges. Nodes typically store information about people, places, and things while edges store information about the relationships between the nodes. The underlying storage mechanism of graph databases can vary. Some depend on a relational engine and \u201cstore\u201d the graph data in a table (although a table is a logical element, therefore this approach imposes another level of abstraction between the graph database, the graph database management system and the physical devices where the data is actually stored). Others use a key-value store or document-oriented database for storage, making them inherently NoSQL structures. Graph databases excel in use cases where you need to traverse relationships to look for patterns such as social networks, fraud detection, and recommendation engines. Ex: Neo4j
"},{"location":"level101/databases_nosql/intro/#comparison","title":"Comparison","text":"Performance Scalability Flexibility Complexity Functionality Key Value high high high none Variable Document stores high Variable (high) high low Variable (low) Column DB high high moderate low minimal Graph Variable Variable high high Graph theory"},{"location":"level101/databases_nosql/intro/#differences-between-sql-and-nosql","title":"Differences between SQL and NoSQL","text":"

The table below summarizes the main differences between SQL and NoSQL databases.

SQL Databases NoSQL Databases Data Storage Model Tables with fixed rows and columns Document: JSON documents, Key-value: key-value pairs, Wide-column: tables with rows and dynamic columns, Graph: nodes and edges Primary Purpose General purpose Document: general purpose, Key-value: large amounts of data with simple lookup queries, Wide-column: large amounts of data with predictable query patterns, Graph: analyzing and traversing relationships between connected data Schemas Rigid Flexible Scaling Vertical (scale-up with a larger server) Horizontal (scale-out across commodity servers) Multi-Record ACID Transactions Supported Most do not support multi-record ACID transactions. However, some like MongoDB do. Joins Typically required Typically not required Data to Object Mapping Requires ORM (object-relational mapping) Many do not require ORMs. Document DB documents map directly to data structures in most popular programming languages."},{"location":"level101/databases_nosql/intro/#advantages","title":"Advantages","text":""},{"location":"level101/databases_nosql/key_concepts/","title":"Key Concepts","text":"

Lets looks at some of the key concepts when we talk about NoSQL or distributed systems.

"},{"location":"level101/databases_nosql/key_concepts/#cap-theorem","title":"CAP Theorem","text":"

In a keynote titled \u201cTowards Robust Distributed Systems\u201d at ACM\u2019s PODC symposium in 2000, Eric Brewer came up with the so-called CAP-theorem which is widely adopted today by large web companies as well as in the NoSQL community. The CAP acronym stands for Consistency, Availability & Partition Tolerance.

Brewer alleges that one can at most choose two of these three characteristics in a shared-data system. The CAP-theorem states that a choice can only be made for two options out of consistency, availability and partition tolerance. A growing number of use cases in large scale applications tend to value reliability implying that availability & redundancy are more valuable than consistency. As a result these systems struggle to meet ACID properties. They attain this by loosening on the consistency requirement, i.e Eventual Consistency.

Eventual Consistency means that all readers will see writes, as time goes on: \u201cIn a steady state, the system will eventually return the last written value\u201d. Clients therefore may face an inconsistent state of data as updates are in progress. For instance, in a replicated database updates may go to one node which replicates the latest version to all other nodes that contain a replica of the modified dataset so that the replica nodes eventually will have the latest version.

NoSQL systems support different levels of eventual consistency models. For example:

Eventual consistency is useful if concurrent updates of the same partitions of data are unlikely and if clients do not immediately depend on reading updates issued by themselves or by other clients.

Depending on what consistency model was chosen for the system (or parts of it), determines where the requests are routed, ex: replicas.

CAP alternatives illustration

Choice Traits Examples Consistency + Availability

(Forfeit Partitions) 2-phase commits

Cache invalidation protocols Single-site databases Cluster databases

LDAP

xFS file system Consistency + Partition tolerance

(Forfeit Availability) Pessimistic locking

Make minority partitions unavailable Distributed databases Distributed locking Majority protocols Availability + Partition tolerance (Forfeit Consistency) expirations/leases

conflict resolution optimistic DNS

Web caching"},{"location":"level101/databases_nosql/key_concepts/#versioning-of-data-in-distributed-systems","title":"Versioning of Data in distributed systems","text":"

When data is distributed across nodes, it can be modified on different nodes at the same time (assuming strict consistency is enforced). Questions arise on conflict resolution for concurrent updates. Some of the popular conflict resolution mechanism are

Vector clocks illustration

Vector clocks have the following advantages over other conflict resolution mechanism:

  1. No dependency on synchronized clocks
  2. No total ordering of revision nos required for casual reasoning

No need to store and maintain multiple versions of the data on different nodes.** **

"},{"location":"level101/databases_nosql/key_concepts/#partitioning","title":"Partitioning","text":"

When the amount of data crosses the capacity of a single node, we need to think of splitting data, creating replicas for load balancing & disaster recovery. Depending on how dynamic the infrastructure is, we have a few approaches that we can take.

  1. Memory cached

    These are partitioned in-memory databases that are primarily used for transient data. These databases are generally used as a front for traditional RDBMS. Most frequently used data is replicated from a RDBMS into a memory database to facilitate fast queries and to take the load off from backend DB\u2019s. A very common example is Memcached or Couchbase.

  2. Clustering

    Traditional cluster mechanisms abstract away the cluster topology from clients. A client need not know where the actual data is residing and which node it is talking to. Clustering is very commonly used in traditional RDBMS where it can help scaling the persistent layer to a certain extent.

  3. Separating reads from writes

    In this method, you will have multiple replicas hosting the same data. The incoming writes are typically sent to a single node (Leader) or multiple nodes (multi-Leader), while the rest of the replicas (Follower) handle reads requests. The leader replicates writes asynchronously to all followers. However, the write lag can\u2019t be completely avoided. Sometimes a leader can crash before it replicates all the data to a follower. When this happens, a follower with the most consistent data can be turned into a leader. As you can realize now, it is hard to enforce full consistency in this model. You also need to consider the ratio of read vs write traffic. This model won\u2019t make sense when writes are higher than reads. The replication methods can also vary widely. Some systems do a complete transfer of state periodically, while others use a delta state transfer approach. You could also transfer the state by transferring the operations in order. The followers can then apply the same operations as the leader to catch up.

  4. Sharding

    Sharing refers to dividing data in such a way that data is distributed evenly (both in terms of storage & processing power) across a cluster of nodes. It can also imply data locality, which means similar & related data is stored together to facilitate faster access. A shard in turn can be further replicated to meet load balancing or disaster recovery requirements. A single shard replica might take in all writes (single leader) or multiple replicas can take writes (multi-leader). Reads can be distributed across multiple replicas. Since data is now distributed across multiple nodes, clients should be able to consistently figure out where data is hosted. We will look at some of the common techniques below. The downside of sharding is that joins between shards is not possible. So an upstream/downstream application has to aggregate the results from multiple shards.

Sharding example

"},{"location":"level101/databases_nosql/key_concepts/#hashing","title":"Hashing","text":"

A hash function is a function that maps one piece of data\u2014typically describing some kind of object, often of arbitrary size\u2014to another piece of data, typically an integer, known as hash code, or simply hash. In a partitioned database, it is important to consistently map a key to a server/replica.

For ex: you can use a very simple hash as a modulo function.

_p = k mod n_\n

Where

p -> partition,\n\n\nk -> primary key\n\n\nn -> no of nodes\n

The downside of this simple hash is that, whenever the cluster topology changes, the data distribution also changes. When you are dealing with memory caches, it will be easy to distribute partitions around. Whenever a node joins/leaves a topology, partitions can reorder themselves, a cache miss can be re-populated from backend DB. However, when you look at persistent data, it is not possible as the new node doesn\u2019t have the data needed to serve it. This brings us to consistent hashing.

"},{"location":"level101/databases_nosql/key_concepts/#consistent-hashing","title":"Consistent Hashing","text":"

Consistent hashing is a distributed hashing scheme that operates independently of the number of servers or objects in a distributed hash table by assigning them a position on an abstract circle, or hash ring. This allows servers and objects to scale without affecting the overall system.

Say that our hash function h() generates a 32-bit integer. Then, to determine to which server we will send a key k, we find the server s whose hash h(s) is the smallest integer that is larger than h(k). To make the process simpler, we assume the table is circular, which means that if we cannot find a server with a hash larger than h(k), we wrap around and start looking from the beginning of the array.

Consistent hashing illustration

In consistent hashing, when a server is removed or added, then only the keys from that server are relocated. For example, if server S3 is removed then, all keys from server S3 will be moved to server S4 but keys stored on server S4 and S2 are not relocated. But there is one problem, when server S3 is removed then keys from S3 are not equally distributed among remaining servers S4 and S2. They are only assigned to server S4 which increases the load on server S4.

To evenly distribute the load among servers when a server is added or removed, it creates a fixed number of replicas (known as virtual nodes) of each server and distributes it along the circle. So instead of server labels S1, S2 and S3, we will have S10,S11,\u2026,S19, S20,S21,\u2026,S29 and S30,S31,\u2026,S39. The factor for a number of replicas is also known as weight, depending on the situation.

All keys which are mapped to replicas Sij are stored on server Si. To find a key, we do the same thing, find the position of the key on the circle and then move forward until you find a server replica. If the server replica is Sij, then the key is stored in server Si.

Suppose server S3 is removed, then all S3 replicas with labels S30,S31,\u2026,S39 must be removed. Now, the objects keys adjacent to S3X labels will be automatically re-assigned to S1X, S2X and S4X. All keys originally assigned to S1, S2 & S4 will not be moved.

Similar things happen if we add a server. Suppose we want to add a server S5 as a replacement of S3, then we need to add labels S50,S51,\u2026,S59. In the ideal case, one-fourth of keys from S1, S2 and S4 will be reassigned to S5.

When applied to persistent storages, further issues arise: if a node has left the scene, data stored on this node becomes unavailable, unless it has been replicated to other nodes before; in the opposite case of a new node joining the others, adjacent nodes are no longer responsible for some pieces of data which they still store but not get asked for anymore as the corresponding objects are no longer hashed to them by requesting clients. In order to address this issue, a replication factor (r) can be introduced.

Introducing replicas in a partitioning scheme\u2014besides reliability benefits\u2014also makes it possible to spread workload for read requests that can go to any physical node responsible for a requested piece of data. Scalability doesn\u2019t work if the clients have to decide between multiple versions of the dataset, because they need to read from a quorum of servers which in turn reduces the efficiency of load balancing.

"},{"location":"level101/databases_nosql/key_concepts/#quorum","title":"Quorum","text":"

Quorum is the minimum number of nodes in a cluster that must be online and be able to communicate with each other. If any additional node failure occurs beyond this threshold, the cluster will stop running.

To attain a quorum, you need a majority of the nodes. Commonly, it is (N/2 + 1), where N is the total no of nodes in the system. For example,

Quorum example

Network problems can cause communication failures among cluster nodes. One set of nodes might be able to communicate together across a functioning part of a network but not be able to communicate with a different set of nodes in another part of the network. This is known as split brain in cluster or cluster partitioning.

Now the partition which has quorum is allowed to continue running the application. The other partitions are removed from the cluster.

Eg: In a 5-node cluster, consider what happens if nodes 1, 2, and 3 can communicate with each other but not with nodes 4 and 5. Nodes 1, 2, and 3 constitute a majority, and they continue running as a cluster. Nodes 4 and 5, being a minority, stop running as a cluster. If node 3 loses communication with other nodes, all nodes stop running as a cluster. However, all functioning nodes will continue to listen for communication, so that when the network begins working again, the cluster can form and begin to run.

Below diagram demonstrates Quorum selection on a cluster partitioned into two sets.

Cluster Quorum example

"},{"location":"level101/databases_sql/backup_recovery/","title":"Backup and Recovery","text":""},{"location":"level101/databases_sql/backup_recovery/#backup-and-recovery","title":"Backup and Recovery","text":"

Backups are a very crucial part of any database setup. They are generally a copy of the data that can be used to reconstruct the data in case of any major or minor crisis with the database. In general terms, backups can be of two types:

Both the above kinds of backups are supported by MySQL with different tools. It is the job of the SRE to identify which should be used when.

"},{"location":"level101/databases_sql/backup_recovery/#mysqldump","title":"Mysqldump","text":"

This utility is available with MySQL installation. It helps in getting the logical backup of the database. It outputs a set of SQL statements to reconstruct the data. It is not recommended to use mysqldump for large tables as it might take a lot of time and the file size will be huge. However, for small tables it is the best and the quickest option.

mysqldump [options] > dump_output.sql\n

There are certain options that can be used with mysqldump to get an appropriate dump of the database.

To dump all the databases:

mysqldump -u<user> -p<pwd> --all-databases > all_dbs.sql\n

To dump specific databases:

mysqldump -u<user> -p<pwd> --databases db1 db2 db3 > dbs.sql\n

To dump a single database:

mysqldump -u<user> -p<pwd> --databases db1 > db1.sql\n

OR

mysqldump -u<user> -p<pwd> db1 > db1.sql\n

The difference between the above two commands is that the latter one does not contain the CREATE DATABASE command in the backup output.

To dump specific tables in a database:

mysqldump -u<user> -p<pwd> db1 table1 table2 > db1_tables.sql\n

To dump only table structures and no data:

mysqldump -u<user> -p<pwd> --no-data db1 > db1_structure.sql\n

To dump only table data and no CREATE statements:

mysqldump -u<user> -p<pwd> --no-create-info db1 > db1_data.sql\n

To dump only specific records from a table:

mysqldump -u<user> -p<pwd> --no-create-info db1 table1 --where=\u201dsalary>80000\u201d > db1_table1_80000.sql\n

mysqldump can also provide output in CSV, other delimited text or XML format to support use-cases if any. The backup from mysqldump utility is offline, i.e. when the backup finishes it will not have the changes to the database which were made when the backup was going on. For example, if the backup started at 3:00 pm and finished at 4:00 pm, it will not have the changes made to the database between 3:00 and 4:00 pm.

Restoring from mysqldump can be done in the following two ways:

From shell

mysql -u<user> -p<pwd> < all_dbs.sql\n

OR

From shell, if the database is already created:

mysql -u<user> -p<pwd> db1 < db1.sql\n

From within MySQL shell:

mysql> source all_dbs.sql\n
"},{"location":"level101/databases_sql/backup_recovery/#percona-xtrabackup","title":"Percona XtraBackup","text":"

This utility is installed separately from the MySQL server and is open source, provided by Percona. It helps in getting the full or partial physical backup of the database. It provides online backup of the database, i.e. it will have the changes made to the database when the backup was going on as explained at the end of the previous section.

Percona XtraBackup allows us to get both full and incremental backups as we desire. However, incremental backups take less space than a full backup (if taken per day) but the restore time of incremental backups is more than that of full backups.

Creating a full backup

xtrabackup --defaults-file=<location to my.cnf> --user=<mysql user> --password=<mysql password> --backup --target-dir=<location of target directory>\n

Example:

xtrabackup --defaults-file=/etc/my.cnf --user=some_user --password=XXXX --backup --target-dir=/mnt/data/backup/\n

Some other options

Preparing a backup

Once the backup is done with the --backup option, we need to prepare it in order to restore it. This is done to make the data files consistent with point-in-time. There might have been some transactions going on while the backup was being executed and those have changed the data files. When we prepare a backup, all those transactions are applied to the data files.

xtrabackup --prepare --target-dir=<where backup is taken>\n

Example:

xtrabackup --prepare --target-dir=/mnt/data/backup/\n

It is not recommended to halt a process which is preparing the backup as that might cause data file corruption and backup cannot be used further. The backup will have to be taken again.

Restoring a Full Backup

To restore the backup which is created and prepared from above commands, just copy everything from the backup target-dir to the data-dir of MySQL server, change the ownership of all files to MySQL user (the Linux user used by MySQL server) and start MySQL.

Or the below command can be used as well,

xtrabackup --defaults-file=/etc/my.cnf --copy-back --target-dir=/mnt/data/backups/\n

Note - the backup has to be prepared in order to restore it.

Creating Incremental backups

Percona XtraBackup helps create incremental backups, i.e, only the changes can be backed up since the last backup. Every InnoDB page contains a log sequence number or LSN that is also mentioned as one of the last lines of backup and prepare commands.

xtrabackup: Transaction log of lsn <LSN> to <LSN> was copied.\n

OR

InnoDB: Shutdown completed; log sequence number <LSN>\n<timestamp> completed OK!\n

This indicates that the backup has been taken till the log sequence number mentioned. This is a key information in understanding incremental backups and working towards automating one. Incremental backups do not compare data files for changes, instead, they go through the InnoDB pages and compare their LSN to the last backup\u2019s LSN. So, without one full backup, the incremental backups are useless.

The xtrabackup command creates a xtrabackup_checkpoint file which has the information about the LSN of the backup. Below are the key contents of the file:

backup_type = full-backuped | incremental\nfrom_lsn = 0 (full backup) | to_lsn of last backup <LSN>\nto_lsn = <LSN>\nlast_lsn = <LSN>\n

There is a difference between to_lsn and last_lsn. When the last_lsn is more than to_lsn that means there are transactions that ran while we took the backup and are yet to be applied. That is what --prepare is used for.

To take incremental backups, first, we require one full backup.

xtrabackup --defaults-file=/etc/my.cnf --user=some_user --password=XXXX --backup --target-dir=/mnt/data/backup/full/\n

Let\u2019s assume the contents of the xtrabackup_checkpoint file to be as follows:

backup_type = full-backuped\nfrom_lsn = 0\nto_lsn = 1000\nlast_lsn = 1000\n

Now that we have one full backup, we can have an incremental backup that takes the changes. We will go with differential incremental backups.

xtrabackup --defaults-file=/etc/my.cnf --user=some_user --password=XXXX --backup --target-dir=/mnt/data/backup/incr1/ --incremental-basedir=/mnt/data/backup/full/\n

There are delta files created in the incr1 directory like, ibdata1.delta, db1/tbl1.ibd.delta with the changes from the full directory. The xtrabackup_checkpoint file will thus have the following contents.

backup_type = incremental\nfrom_lsn = 1000\nto_lsn = 1500\nlast_lsn = 1500\n

Hence, the from_lsn here is equal to the to_lsn of the last backup or the basedir provided for the incremental backups. For the next incremental backup, we can use this incremental backup as the basedir.

xtrabackup --defaults-file=/etc/my.cnf --user=some_user --password=XXXX --backup --target-dir=/mnt/data/backup/incr2/ --incremental-basedir=/mnt/data/backup/incr1/\n

The xtrabackup_checkpoint file will thus have the following contents:

backup_type = incremental\nfrom_lsn = 1500\nto_lsn = 2000\nlast_lsn = 2200\n

Preparing Incremental backups

Preparing incremental backups is not the same as preparing a full backup. When prepare runs, two operations are performed - committed transactions are applied on the data files and uncommitted transactions are rolled back. While preparing incremental backups, we have to skip rollback of uncommitted transactions as it is likely that they might get committed in the next incremental backup. If we rollback uncommitted transactions, the further incremental backups cannot be applied.

We use --apply-log-only option along with --prepare to avoid the rollback phase.

From the last section, we had the following directories with complete backup:

/mnt/data/backup/full\n/mnt/data/backup/incr1\n/mnt/data/backup/incr2\n

First, we prepare the full backup, but only with the --apply-log-only option.

xtrabackup --prepare --apply-log-only --target-dir=/mnt/data/backup/full\n

The output of the command will contain the following at the end.

InnoDB: Shutdown complete; log sequence number 1000\n<timestamp> Completed OK!\n

Note the LSN mentioned at the end is the same as the to_lsn from the xtrabackup_checkpoint created for full backup.

Next, we apply the changes from the first incremental backup to the full backup.

xtrabackup --prepare --apply-log-only --target-dir=/mnt/data/backup/full --incremental-dir=/mnt/data/backup/incr1\n

This applies the delta files in the incremental directory to the full backup directory. It rolls the data files in the full backup directory forward to the time of incremental backup and applies the redo logs as usual.

Lastly, we apply the last incremental backup same as the previous one with just a small change.

xtrabackup --prepare --target-dir=/mnt/data/backup/full --incremental-dir=/mnt/data/backup/incr1\n

We do not have to use the --apply-log-only option with it. It applies the incr2 delta files to the full backup data files taking them forward, applies redo logs on them and finally rollbacks the uncommitted transactions to produce the final result. The data now present in the full backup directory can now be used to restore.

Note: To create cumulative incremental backups, the incremental-basedir should always be the full backup directory for every incremental backup. While preparing, we can start with the full backup with the --apply-log-only option and use just the last incremental backup for the final --prepare as that has all the changes since the full backup.

Restoring Incremental backups

Once all the above steps are completed, restoring is the same as done for a full backup.

"},{"location":"level101/databases_sql/backup_recovery/#further-reading","title":"Further Reading","text":""},{"location":"level101/databases_sql/concepts/","title":"Key Concepts","text":""},{"location":"level101/databases_sql/concepts/#popular-databases","title":"Popular databases","text":"

Commercial, closed source: Oracle, Microsoft SQL Server, IBM DB2

Open source with optional paid support: MySQL, MariaDB, PostgreSQL

Individuals and small companies have always preferred open source DBs because of the huge cost associated with commercial software.

In recent times, even large organizations have moved away from commercial software to open source alternatives because of the flexibility and cost savings associated with it.

Lack of support is no longer a concern because of the paid support available from the developer and third parties.

MySQL is the most widely used open source DB, and it is widely supported by hosting providers, making it easy for anyone to use. It is part of the popular Linux-Apache-MySQL-PHP (LAMP) stack that became popular in the 2000s. We have many more choices for a programming language, but the rest of that stack is still widely used.

"},{"location":"level101/databases_sql/conclusion/","title":"Conclusion","text":"

We have covered basic concepts of SQL databases. We have also covered some of the tasks that an SRE may be responsible for\u2014there is so much more to learn and do. We hope this course gives you a good start and inspires you to explore further.

"},{"location":"level101/databases_sql/conclusion/#further-reading","title":"Further reading","text":""},{"location":"level101/databases_sql/innodb/","title":"InnoDB","text":""},{"location":"level101/databases_sql/innodb/#why-should-you-use-this","title":"Why should you use this?","text":"

General purpose, row level locking, ACID support, transactions, crash recovery and multi-version concurrency control, etc.

"},{"location":"level101/databases_sql/innodb/#architecture","title":"Architecture","text":""},{"location":"level101/databases_sql/innodb/#key-components","title":"Key components:","text":""},{"location":"level101/databases_sql/intro/","title":"Relational Databases","text":""},{"location":"level101/databases_sql/intro/#prerequisites","title":"Prerequisites","text":""},{"location":"level101/databases_sql/intro/#what-to-expect-from-this-course","title":"What to expect from this course","text":"

You will have an understanding of what relational databases are, their advantages, and some MySQL specific concepts.

"},{"location":"level101/databases_sql/intro/#what-is-not-covered-under-this-course","title":"What is not covered under this course","text":""},{"location":"level101/databases_sql/intro/#introduction","title":"Introduction","text":"

The main purpose of database systems is to manage data. This includes storage, adding new data, deleting unused data, updating existing data, retrieving data within a reasonable response time, other maintenance tasks to keep the system running, etc.

"},{"location":"level101/databases_sql/intro/#pre-reads","title":"Pre-reads","text":"

RDBMS Concepts

"},{"location":"level101/databases_sql/intro/#course-contents","title":"Course Contents","text":""},{"location":"level101/databases_sql/lab/","title":"Lab","text":"

Prerequisites

Install Docker

Setup

Create a working directory named sos or something similar, and cd into it.

Enter the following into a file named my.cnf under a directory named custom:

sos $ cat custom/my.cnf\n[mysqld]\n\n# These settings apply to MySQL server\n# You can set port, socket path, buffer size etc.\n# Below, we are configuring slow query settings\n\nslow_query_log=1\nslow_query_log_file=/var/log/mysqlslow.log\nlong_query_time=1\n

Start a container and enable slow query log with the following:

sos $ docker run --name db -v custom:/etc/mysql/conf.d -e MYSQL_ROOT_PASSWORD=realsecret -d mysql:8\nsos $ docker cp custom/my.cnf $(docker ps -qf \"name=db\"):/etc/mysql/conf.d/custom.cnf\nsos $ docker restart $(docker ps -qf \"name=db\")\n

Import a sample database:

sos $ git clone git@github.com:datacharmer/test_db.git\nsos $ docker cp test_db $(docker ps -qf \"name=db\"):/home/test_db/\nsos $ docker exec -it $(docker ps -qf \"name=db\") bash\nroot@3ab5b18b0c7d:/# cd /home/test_db/\nroot@3ab5b18b0c7d:/# mysql -uroot -prealsecret mysql < employees.sql\nroot@3ab5b18b0c7d:/etc# touch /var/log/mysqlslow.log\nroot@3ab5b18b0c7d:/etc# chown mysql:mysql /var/log/mysqlslow.log\n

Workshop 1: Run some sample queries

Run the following:

$ mysql -uroot -prealsecret mysql\nmysql>\n\n# inspect DBs and tables\n# the last 4 are MySQL internal DBs\n\nmysql> SHOW DATABASES;\n+--------------------+\n| Database           |\n+--------------------+\n| employees          |\n| information_schema |\n| mysql              |\n| performance_schema |\n| sys                |\n+--------------------+\n\nmysql> USE employees;\nmysql> SHOW TABLES;\n+----------------------+\n| Tables_in_employees  |\n+----------------------+\n| current_dept_emp     |\n| departments          |\n| dept_emp             |\n| dept_emp_latest_date |\n| dept_manager         |\n| employees            |\n| salaries             |\n| titles               |\n+----------------------+\n\n# read a few rows\nmysql> SELECT * FROM employees LIMIT 5;\n\n# filter data by conditions\nmysql> SELECT COUNT(*) FROM employees WHERE gender = 'M' LIMIT 5;\n\n# find count of particular data\nmysql> SELECT COUNT(*) FROM employees WHERE first_name = 'Sachin'; \n

Workshop 2: Use explain and explain analyze to profile a query, identify and add indexes required for improving performance

# View all indexes on table \n# (\\G is to output horizontally, replace it with a ; to get table output)\n\nmysql> SHOW INDEX FROM employees FROM employees\\G\n*************************** 1. row ***************************\n        Table: employees\n   Non_unique: 0\n     Key_name: PRIMARY\n Seq_in_index: 1\n  Column_name: emp_no\n    Collation: A\n  Cardinality: 299113\n     Sub_part: NULL\n       Packed: NULL\n         Null:\n   Index_type: BTREE\n      Comment:\nIndex_comment:\n      Visible: YES\n   Expression: NULL\n\n# This query uses an index, identified by 'key' field\n# By prefixing explain keyword to the command, \n# we get query plan (including key used)\n\nmysql> EXPLAIN SELECT * FROM employees WHERE emp_no < 10005\\G\n*************************** 1. row ***************************\n           id: 1\n  select_type: SIMPLE\n        table: employees\n   partitions: NULL\n         type: range\npossible_keys: PRIMARY\n          key: PRIMARY\n      key_len: 4\n          ref: NULL\n         rows: 4\n     filtered: 100.00\n        Extra: Using where\n\n# Compare that to the next query which does not utilize any index\n\nmysql> EXPLAIN SELECT first_name, last_name FROM employees WHERE first_name = 'Sachin'\\G\n*************************** 1. row ***************************\n           id: 1\n  select_type: SIMPLE\n        table: employees\n   partitions: NULL\n         type: ALL\npossible_keys: NULL\n          key: NULL\n      key_len: NULL\n          ref: NULL\n         rows: 299113\n     filtered: 10.00\n        Extra: Using where\n\n# Let's see how much time this query takes\n\nmysql> EXPLAIN ANALYZE SELECT first_name, last_name FROM employees WHERE first_name = 'Sachin'\\G\n*************************** 1. row ***************************\nEXPLAIN: -> Filter: (employees.first_name = 'Sachin')  (cost=30143.55 rows=29911) (actual time=28.284..3952.428 rows=232 loops=1)\n    -> Table scan on employees  (cost=30143.55 rows=299113) (actual time=0.095..1996.092 rows=300024 loops=1)\n\n\n# Cost (estimated by query planner) is 30143.55\n# actual time=28.284ms for first row, 3952.428 for all rows\n# Now lets try adding an index and running the query again\n\nmysql> CREATE INDEX idx_firstname ON employees(first_name);\nQuery OK, 0 rows affected (1.25 sec)\nRecords: 0  Duplicates: 0  Warnings: 0\n\nmysql> EXPLAIN ANALYZE SELECT first_name, last_name FROM employees WHERE first_name = 'Sachin';\n+--------------------------------------------------------------------------------------------------------------------------------------------+\n| EXPLAIN                                                                                                                                    |\n+--------------------------------------------------------------------------------------------------------------------------------------------+\n| -> Index lookup on employees using idx_firstname (first_name='Sachin')  (cost=81.20 rows=232) (actual time=0.551..2.934 rows=232 loops=1)\n |\n+--------------------------------------------------------------------------------------------------------------------------------------------+\n1 row in set (0.01 sec)\n\n# Actual time=0.551ms for first row\n# 2.934ms for all rows. A huge improvement!\n# Also notice that the query involves only an index lookup,\n# and no table scan (reading all rows of the table),\n# which vastly reduces load on the DB.\n

Workshop 3: Identify slow queries on a MySQL server

# Run the command below in two terminal tabs to open two shells into the container.\n\n$ docker exec -it $(docker ps -qf \"name=db\") bash\n\n# Open a `mysql` prompt in one of them and execute this command\n# We have configured to log queries that take longer than 1s,\n# so this `sleep(3)` will be logged\n\n$ mysql -uroot -prealsecret mysql\nmysql> select sleep(3);\n\n# Now, in the other terminal, tail the slow log to find details about the query\n\nroot@62c92c89234d:/etc# tail -f /var/log/mysqlslow.log\n/usr/sbin/mysqld, Version: 8.0.21 (MySQL Community Server - GPL). started with:\nTcp port: 3306  Unix socket: /var/run/mysqld/mysqld.sock\nTime                 Id Command    Argument\n\n# Time: 2020-11-26T14:53:44.822348Z\n# User@Host: root[root] @ localhost []  Id:     9\n# Query_time: 5.404938  Lock_time: 0.000000 Rows_sent: 1  Rows_examined: 1\nuse employees;\n# Time: 2020-11-26T14:53:58.015736Z\n# User@Host: root[root] @ localhost []  Id:     9\n# Query_time: 10.000225  Lock_time: 0.000000 Rows_sent: 1  Rows_examined: 1\n\nSET timestamp=1606402428;\nselect sleep(3);\n

These were simulated examples with minimal complexity. In real life, the queries would be much more complex and the explain/analyze and slow query logs would have more details.

"},{"location":"level101/databases_sql/mysql/","title":"MySQL","text":""},{"location":"level101/databases_sql/mysql/#mysql-architecture","title":"MySQL architecture","text":"

MySQL architecture enables you to select the right storage engine for your needs, and abstracts away all implementation details from the end users (application engineers and DBA) who only need to know a consistent stable API.

Application layer:

Server layer:

Storage engine options:

It is possible to migrate from one storage engine to another. But this migration locks tables for all operations and is not online, as it changes the physical layout of the data. It takes a long time and is generally not recommended. Hence, choosing the right storage engine at the beginning is important.

General guideline is to use InnoDB unless you have a specific need for one of the other storage engines.

Running mysql> SHOW ENGINES; shows you the supported engines on your MySQL server.

"},{"location":"level101/databases_sql/operations/","title":"Operational Concepts","text":""},{"location":"level101/databases_sql/query_performance/","title":"Query Performance","text":""},{"location":"level101/databases_sql/query_performance/#query-performance-improvement","title":"Query Performance Improvement","text":"

Query Performance is a very crucial aspect of relational databases. If not tuned correctly, the select queries can become slow and painful for the application, and for the MySQL server as well. The important task is to identify the slow queries and try to improve their performance by either rewriting them or creating proper indexes on the tables involved in it.

"},{"location":"level101/databases_sql/query_performance/#the-slow-query-log","title":"The Slow Query Log","text":"

The slow query log contains SQL statements that take a longer time to execute than set in the config parameter long_query_time. These queries are the candidates for optimization. There are some good utilities to summarize the slow query logs like, mysqldumpslow (provided by MySQL itself), pt-query-digest (provided by Percona), etc. Following are the config parameters that are used to enable and effectively catch slow queries

Variable Explanation Example value slow_query_log Enables or disables slow query logs ON slow_query_log_file The location of the slow query log /var/lib/mysql/mysql-slow.log long_query_time Threshold time. The query that takes longer than this time is logged in slow query log 5 log_queries_not_using_indexes When enabled with the slow query log, the queries which do not make use of any index are also logged in the slow query log even though they take less time than long_query_time. ON

So, for this section, we will be enabling slow_query_log, long_query_time will be kept to 0.3 (300 ms), and log_queries_not_using index will be enabled as well.

Below are the queries that we will execute on the employees database.

  1. SELECT * FROM employees WHERE last_name = 'Koblick'

  2. SELECT * FROM salaries WHERE salary >= 100000

  3. SELECT * FROM titles WHERE title = 'Manager'

  4. SELECT * FROM employees WHERE year(hire_date) = 1995

  5. SELECT year(e.hire_date), max(s.salary) FROM employees e JOIN salaries s ON e.emp_no=s.emp_no GROUP BY year(e.hire_date)

Now, queries 1, 3 and 4 executed under 300ms but if we check the slow query logs, we will find these queries logged as they are not using any of the index. Queries 2 and 5 are taking longer than 300ms and also not using any index.

Use the following command to get the summary of the slow query log:

mysqldumpslow /var/lib/mysql/mysql-slow.log\n

There are some more queries in the snapshot that were along with the queries mentioned. mysqldumpslow replaces actual values that were used by N (in case of numbers) and S (in case of strings). That can be overridden by -a option, however, that will increase the output lines if different values are used in similar queries.

"},{"location":"level101/databases_sql/query_performance/#the-explain-plan","title":"The EXPLAIN Plan","text":"

The EXPLAIN command is used with any query that we want to analyze. It describes the query execution plan, how MySQL sees and executes the query. EXPLAIN works with SELECT, INSERT, UPDATE and DELETE statements. It tells about different aspects of the query like, how tables are joined, indexes used or not, etc. The important thing here is to understand the basic EXPLAIN plan output of a query to determine its performance.

Let's take the following query as an example,

mysql> EXPLAIN SELECT * FROM salaries WHERE salary = 100000;\n+----+-------------+----------+------------+------+---------------+------+---------+------+---------+----------+-------------+\n| id | select_type | table    | partitions | type | possible_keys | key  | key_len | ref  | rows    | filtered | Extra       |\n+----+-------------+----------+------------+------+---------------+------+---------+------+---------+----------+-------------+\n|  1 | SIMPLE      | salaries | NULL       | ALL  | NULL          | NULL | NULL    | NULL | 2838426 |    10.00 | Using where |\n+----+-------------+----------+------------+------+---------------+------+---------+------+---------+----------+-------------+\n1 row in set, 1 warning (0.00 sec)\n

The key aspects to understand in the above output are:

So, for the above query, we can determine that there are no partitions, there are no candidate indexes to be used and so no index is used at all, over 2M rows are examined and only 10% of them are included in the result, and lastly, only a WHERE clause is used to match the target rows.

"},{"location":"level101/databases_sql/query_performance/#creating-an-index","title":"Creating an Index","text":"

Indexes are used to speed up selecting relevant rows for a given column value. Without an index, MySQL starts with the first row and goes through the entire table to find matching rows. If the table has too many rows, the operation becomes costly. With indexes, MySQL determines the position to start looking for the data without reading the full table.

A primary key is also an index which is also the fastest and is stored along with the table data. Secondary indexes are stored outside of the table data and are used to further enhance the performance of SQL statements. Indexes are mostly stored as B-Trees, with some exceptions like spatial indexes use R-Trees and memory tables use hash indexes.

There are 2 ways to create indexes:

Let\u2019s look at the query that we discussed in the previous section. It\u2019s clear that scanning over 2M records is not a good idea when only 10% of those records are actually in the resultset.

Hence, we create an index on the salary column of the salaries table.

CREATE INDEX idx_salary ON salaries(salary)\n

OR

ALTER TABLE salaries ADD INDEX idx_salary(salary)\n

And the same explain plan now looks like this:

mysql> EXPLAIN SELECT * FROM salaries WHERE salary = 100000;\n+----+-------------+----------+------------+------+---------------+------------+---------+-------+------+----------+-------+\n| id | select_type | table    | partitions | type | possible_keys | key        | key_len | ref   | rows | filtered | Extra |\n+----+-------------+----------+------------+------+---------------+------------+---------+-------+------+----------+-------+\n|  1 | SIMPLE      | salaries | NULL       | ref  | idx_salary    | idx_salary | 4       | const |   13 |   100.00 | NULL  |\n+----+-------------+----------+------------+------+---------------+------------+---------+-------+------+----------+-------+\n1 row in set, 1 warning (0.00 sec)\n

Now the index used is idx_salary, the one we recently created. The index actually helped examine only 13 records and all of them are in the resultset. Also, the query execution time is also reduced from over 700ms to almost negligible.

Let\u2019s look at another example. Here, we are searching for a specific combination of first_name and last_name. But, we might also search based on last_name only.

mysql> EXPLAIN SELECT * FROM employees WHERE last_name = 'Dredge' AND first_name = 'Yinghua';\n+----+-------------+-----------+------------+------+---------------+------+---------+------+--------+----------+-------------+\n| id | select_type | table     | partitions | type | possible_keys | key  | key_len | ref  | rows   | filtered | Extra       |\n+----+-------------+-----------+------------+------+---------------+------+---------+------+--------+----------+-------------+\n|  1 | SIMPLE      | employees | NULL       | ALL  | NULL          | NULL | NULL    | NULL | 299468 |     1.00 | Using where |\n+----+-------------+-----------+------------+------+---------------+------+---------+------+--------+----------+-------------+\n1 row in set, 1 warning (0.00 sec)\n

Now only 1% record out of almost 300K is the resultset. Although the query time is particularly quick as we have only 300K records, this will be a pain if the number of records are over millions. In this case, we create an index on last_name and first_name, not separately, but a composite index including both the columns.

CREATE INDEX idx_last_first ON employees(last_name, first_name)\n
mysql> EXPLAIN SELECT * FROM employees WHERE last_name = 'Dredge' AND first_name = 'Yinghua';\n+----+-------------+-----------+------------+------+----------------+----------------+---------+-------------+------+----------+-------+\n| id | select_type | table     | partitions | type | possible_keys  | key            | key_len | ref         | rows | filtered | Extra |\n+----+-------------+-----------+------------+------+----------------+----------------+---------+-------------+------+----------+-------+\n|  1 | SIMPLE      | employees | NULL       | ref  | idx_last_first | idx_last_first | 124     | const,const |    1 |   100.00 | NULL  |\n+----+-------------+-----------+------------+------+----------------+----------------+---------+-------------+------+----------+-------+\n1 row in set, 1 warning (0.00 sec)\n

We chose to put last_name before first_name while creating the index as the optimizer starts from the leftmost prefix of the index while evaluating the query. For example, if we have a 3-column index like idx(c1, c2, c3), then the search capability of the index follows - (c1), (c1, c2) or (c1, c2, c3) i.e. if your WHERE clause has only first_name, this index won\u2019t work.

mysql> EXPLAIN SELECT * FROM employees WHERE first_name = 'Yinghua';\n+----+-------------+-----------+------------+------+---------------+------+---------+------+--------+----------+-------------+\n| id | select_type | table     | partitions | type | possible_keys | key  | key_len | ref  | rows   | filtered | Extra       |\n+----+-------------+-----------+------------+------+---------------+------+---------+------+--------+----------+-------------+\n|  1 | SIMPLE      | employees | NULL       | ALL  | NULL          | NULL | NULL    | NULL | 299468 |    10.00 | Using where |\n+----+-------------+-----------+------------+------+---------------+------+---------+------+--------+----------+-------------+\n1 row in set, 1 warning (0.00 sec)\n

But, if you have only the last_name in the WHERE clause, it will work as expected.

mysql> EXPLAIN SELECT * FROM employees WHERE last_name = 'Dredge';\n+----+-------------+-----------+------------+------+----------------+----------------+---------+-------+------+----------+-------+\n| id | select_type | table     | partitions | type | possible_keys  | key            | key_len | ref   | rows | filtered | Extra |\n+----+-------------+-----------+------------+------+----------------+----------------+---------+-------+------+----------+-------+\n|  1 | SIMPLE      | employees | NULL       | ref  | idx_last_first | idx_last_first | 66      | const |  200 |   100.00 | NULL  |\n+----+-------------+-----------+------------+------+----------------+----------------+---------+-------+------+----------+-------+\n1 row in set, 1 warning (0.00 sec)\n

For another example, use the following queries:

CREATE TABLE employees_2 LIKE employees;\nCREATE TABLE salaries_2 LIKE salaries;\nALTER TABLE salaries_2 DROP PRIMARY KEY;\n

We made copies of employees and salaries tables without the Primary Key of salaries table to understand an example of SELECT with JOIN.

When you have queries like the below, it becomes tricky to identify the pain point of the query.

mysql> SELECT e.first_name, e.last_name, s.salary, e.hire_date FROM employees_2 e JOIN salaries_2 s ON e.emp_no=s.emp_no WHERE e.last_name='Dredge';\n1860 rows in set (4.44 sec)\n

This query is taking about 4.5 seconds to complete with 1860 rows in the resultset. Let\u2019s look at the Explain plan. There will be 2 records in the Explain plan as 2 tables are used in the query.

mysql> EXPLAIN SELECT e.first_name, e.last_name, s.salary, e.hire_date FROM employees_2 e JOIN salaries_2 s ON e.emp_no=s.emp_no WHERE e.last_name='Dredge';\n+----+-------------+-------+------------+--------+------------------------+---------+---------+--------------------+---------+----------+-------------+\n| id | select_type | table | partitions | type   | possible_keys          | key     | key_len | ref                | rows    | filtered | Extra       |\n+----+-------------+-------+------------+--------+------------------------+---------+---------+--------------------+---------+----------+-------------+\n|  1 | SIMPLE      | s     | NULL       | ALL    | NULL                   | NULL    | NULL    | NULL               | 2837194 |   100.00 | NULL        |\n|  1 | SIMPLE      | e     | NULL       | eq_ref | PRIMARY,idx_last_first | PRIMARY | 4       | employees.s.emp_no |       1 |     5.00 | Using where |\n+----+-------------+-------+------------+--------+------------------------+---------+---------+--------------------+---------+----------+-------------+\n2 rows in set, 1 warning (0.00 sec)\n

These are in order of evaluation, i.e. salaries_2 will be evaluated first and then employees_2 will be joined to it. As it looks like, it scans almost all the rows of salaries_2 table and tries to match the employees_2 rows as per the JOIN condition. Though WHERE clause is used in fetching the final resultset, but the index corresponding to the WHERE clause is not used for the employees_2 table.

If the join is done on two indexes which have the same data-types, it will always be faster. So, let\u2019s create an index on the emp_no column of salaries_2 table and analyze the query again.

CREATE INDEX idx_empno ON salaries_2(emp_no)\n
mysql> EXPLAIN SELECT e.first_name, e.last_name, s.salary, e.hire_date FROM employees_2 e JOIN salaries_2 s ON e.emp_no=s.emp_no WHERE e.last_name='Dredge';\n+----+-------------+-------+------------+------+------------------------+----------------+---------+--------------------+------+----------+-------+\n| id | select_type | table | partitions | type | possible_keys          | key            | key_len | ref                | rows | filtered | Extra |\n+----+-------------+-------+------------+------+------------------------+----------------+---------+--------------------+------+----------+-------+\n|  1 | SIMPLE      | e     | NULL       | ref  | PRIMARY,idx_last_first | idx_last_first | 66      | const              |  200 |   100.00 | NULL  |\n|  1 | SIMPLE      | s     | NULL       | ref  | idx_empno              | idx_empno      | 4       | employees.e.emp_no |    9 |   100.00 | NULL  |\n+----+-------------+-------+------------+------+------------------------+----------------+---------+--------------------+------+----------+-------+\n2 rows in set, 1 warning (0.00 sec)\n

Now, not only did the index help the optimizer to examine only a few rows in both tables, it reversed the order of the tables in evaluation. The employees_2 table is evaluated first and rows are selected as per the index respective to the WHERE clause. Then, the records are joined to salaries_2 table as per the index used due to the JOIN condition. The execution time of the query came down from 4.5s to 0.02s.

mysql> SELECT e.first_name, e.last_name, s.salary, e.hire_date FROM employees_2 e JOIN salaries_2 s ON e.emp_no=s.emp_no WHERE e.last_name='Dredge'\\G\n1860 rows in set (0.02 sec)\n
"},{"location":"level101/databases_sql/replication/","title":"MySQL Replication","text":""},{"location":"level101/databases_sql/replication/#mysql-replication","title":"MySQL Replication","text":"

Replication enables data from one MySQL host (termed as Primary) to be copied to another MySQL host (termed as Replica). MySQL Replication is asynchronous in nature by default, but it can be changed to semi-synchronous with some configurations.

Some common applications of MySQL replication are:

MySQL supports different types of synchronizations as well:

Pre-Requisites

Before we dive into setting up replication, we should know about the binary logs. Binary logs play a very important role in MySQL replication. Binary logs, or commonly known as binlogs contain events about the changes done to the database, like table structure changes, data changes via DML operations, etc. They are not used to log SELECT statements. For replication, the primary sends the information to the replicas using its binlogs about the changes done to the database, and the replicas make the same data changes.

With respect to MySQL replication, the binary log format can be of two types that decides the main type of replication:

Statement-Based Binlog Format

Originally, the replication in MySQL was based on SQL statements getting replicated and executed on the replica from the primary. This is called statement-based logging. The binlog contains the exact SQL statement run by the session.

So, if we run the above statements to insert 3 records and the update 3 in a single update statement, they will be logged exactly the same as when we executed them.

Row-Based Binlog Format

The row-based is the default one in the latest MySQL releases. This is a lot different from the Statement format as here, row events are logged instead of statements. By that we mean, in the above example one update statement affected 3 records, but binlog had only one UPDATE statement; if it is a row-based format, binlog will have an event for each record updated.

Statement-Based v/s Row-Based binlogs

Let\u2019s have a look at the operational differences between statement-based and row-based binlogs.

Statement-Based Row-Based Logs SQL statements as executed Logs row events based on SQL statements executed Takes lesser disk space Takes more disk space Restoring using binlogs is faster Restoring using binlogs is slower When used for replication, if any statement has a predefined function that has its own value, like sysdate(), uuid() etc, the output could be different on the replica which makes it inconsistent. Whatever is executed becomes a row event with values, so there will be no problem if such functions are used in SQL statements. Only statements are logged so no other row events are generated. A lot of events are generated when a table is copied into another using INSERT INTO SELECT.

Note: There is another type of binlog format called Mixed. With mixed logging, statement-based is used by default but it switches to row-based in certain cases. If MySQL cannot guarantee that statement-based logging is safe for the statements executed, it issues a warning and switches to row-based for those statements.

We will be using binary log format as Row for the entire replication topic.

Replication in Motion

The above figure indicates how a typical MySQL replication works.

  1. Replica_IO_Thread is responsible to fetch the binlog events from the primary binary logs to the replica.
  2. On the Replica host, relay logs are created which are exact copies of the binary logs. If the binary logs on primary are in row format, the relay logs will be the same.
  3. Replica_SQL_Thread applies the relay logs on the replica MySQL server.
  4. If log-bin is enabled on the replica, then the replica will have its own binary logs as well. If log-slave-updates is enabled, then it will have the updates from the primary logged in the binlogs as well.
"},{"location":"level101/databases_sql/replication/#setting-up-replication","title":"Setting up Replication","text":"

In this section, we will set up a simple asynchronous replication. The binlogs will be in row-based format. The replication will be set up on two fresh hosts with no prior data present. There are two different ways in which we can set up replication.

We will set up a GTID-based replication in the following section but will also discuss binlog-based replication setup as well.

Primary Host Configurations

The following config parameters should be present in the primary my.cnf file for setting up GTID-based replication.

server-id - a unique ID for the mysql server\nlog-bin - the binlog location\nbinlog-format - ROW | STATEMENT (we will use ROW)\ngtid-mode - ON\nenforce-gtid-consistency - ON (allows execution of only those statements which can be logged using GTIDs)\n

Replica Host Configurations

The following config parameters should be present in the replica my.cnf file for setting up replication.

server-id - different than the primary host\nlog-bin - (optional, if you want replica to log its own changes as well)\nbinlog-format - depends on the above\ngtid-mode - ON\nenforce-gtid-consistency - ON\nlog-slave-updates - ON (if binlog is enabled, then we can enable this. This enables the replica to log the changes coming from the primary along with its own changes. Helps in setting up chain replication)\n

Replication User

Every replica connects to the primary using a mysql user for replicating. So there must be a mysql user account for the same on the primary host. Any user can be used for this purpose provided it has REPLICATION SLAVE privilege. If the sole purpose is replication, then we can have a user with only the required privilege.

On the primary host:

mysql> CREATE USER repl_user@<replica_IP> IDENTIFIED BY 'xxxxx';\n\nmysql> GRANT REPLICATION SLAVE ON *.* TO repl_user@'<replica_IP>';\n

Obtaining Starting position from Primary

Run the following command on the primary host:

mysql> SHOW MASTER STATUS\\G\n*************************** 1. row ***************************\n             File: mysql-bin.000001\n         Position: 73\n     Binlog_Do_DB:\n Binlog_Ignore_DB:\nExecuted_Gtid_Set: e17d0920-d00e-11eb-a3e6-000d3aa00f87:1-3\n1 row in set (0.00 sec)\n

If we are working with binary log-based replication, the top two output lines are the most important ones. That tells the current binlog on the primary host and till what position it has written. For fresh hosts we know that no data is written, so we can directly set up replication using the very first binlog file and position 4. If we are setting up a replication from a backup, then that changes the way we obtain the starting position. For GTIDs, the executed_gtid_set is the value where primary is right now. Again, for a fresh setup, we don\u2019t have to specify anything about the starting point and it will start from the transaction id 1, but when we set up from a backup, the backup will contain the GTID positions till where backup has been taken.

Setting up Replica

The replication setup must know about the primary host, the user and password to connect, the binlog coordinates (for binlog-based replication) or the GTID auto-position parameter. The following command is used for setting up:

CHANGE MASTER TO\nmaster_host = '<primary host IP>',\nmaster_port = <primary host port - default=3306>,\nmaster_user = 'repl_user',\nmaster_password = 'xxxxx',\nmaster_auto_position = 1;\n

Note: The CHANGE MASTER TO command has been replaced with CHANGE REPLICATION SOURCE TO from Mysql 8.0.23 onwards, also all the master and slave keywords are replaced with source and replica.

If it is binlog-based replication, then instead of master_auto_position, we need to specify the binlog coordinates.

master_log_file = 'mysql-bin.000001',\nmaster_log_pos = 4\n

Starting Replication and Check Status

Now that everything is configured, we just need to start the replication on the replica via the following command

START SLAVE;\n

OR from MySQL 8.0.23 onwards,

START REPLICA;\n

Whether or not the replication is running successfully, we can determine by running the following command:

SHOW SLAVE STATUS\\G\n

OR from MySQL 8.0.23 onwards,

SHOW REPLICA STATUS\\G\n
mysql> SHOW REPLICA STATUS\\G\n*************************** 1. row ***************************\n             Replica_IO_State: Waiting for master to send event\n                  Source_Host: <primary IP>\n                  Source_User: repl_user\n                  Source_Port: <primary port>\n                Connect_Retry: 60\n              Source_Log_File: mysql-bin.000001\n          Read_Source_Log_Pos: 852\n               Relay_Log_File: mysql-relay-bin.000002\n                Relay_Log_Pos: 1067\n        Relay_Source_Log_File: mysql-bin.000001\n           Replica_IO_Running: Yes\n          Replica_SQL_Running: Yes\n              Replicate_Do_DB:\n          Replicate_Ignore_DB:\n           Replicate_Do_Table:\n       Replicate_Ignore_Table:\n      Replicate_Wild_Do_Table:\n  Replicate_Wild_Ignore_Table:\n                   Last_Errno: 0\n                   Last_Error:\n                 Skip_Counter: 0\n          Exec_Source_Log_Pos: 852\n              Relay_Log_Space: 1283\n              Until_Condition: None\n               Until_Log_File:\n                Until_Log_Pos: 0\n           Source_SSL_Allowed: No\n           Source_SSL_CA_File:\n           Source_SSL_CA_Path:\n              Source_SSL_Cert:\n            Source_SSL_Cipher:\n               Source_SSL_Key:\n        Seconds_Behind_Source: 0\nSource_SSL_Verify_Server_Cert: No\n                Last_IO_Errno: 0\n                Last_IO_Error:\n               Last_SQL_Errno: 0\n               Last_SQL_Error:\n  Replicate_Ignore_Server_Ids:\n             Source_Server_Id: 1\n                  Source_UUID: e17d0920-d00e-11eb-a3e6-000d3aa00f87\n             Source_Info_File: mysql.slave_master_info\n                    SQL_Delay: 0\n          SQL_Remaining_Delay: NULL\n    Replica_SQL_Running_State: Slave has read all relay log; waiting for more updates\n           Source_Retry_Count: 86400\n                  Source_Bind:\n      Last_IO_Error_Timestamp:\n     Last_SQL_Error_Timestamp:\n               Source_SSL_Crl:\n           Source_SSL_Crlpath:\n           Retrieved_Gtid_Set: e17d0920-d00e-11eb-a3e6-000d3aa00f87:1-3\n            Executed_Gtid_Set: e17d0920-d00e-11eb-a3e6-000d3aa00f87:1-3\n                Auto_Position: 1\n         Replicate_Rewrite_DB:\n                 Channel_Name:\n           Source_TLS_Version:\n       Source_public_key_path:\n        Get_Source_public_key: 0\n            Network_Namespace:\n1 row in set (0.00 sec)\n

Some of the parameters are explained below:

Parameters Description Relay_Source_Log_File the primary\u2019s file where replica is currently reading from Execute_Source_Log_Pos for the above file on which position is the replica reading currently from. These two parameters are of utmost importance when binlog based replication is used Replica_IO_Running IO thread of replica is running or not Replica_SQL_Running SQL thread of replica is running or not Seconds_Behind_Source the difference of seconds when a statement was executed on Primary and then on Replica. This indicates how much replication lag is there Source_UUID the uuid of the primary host Retrieved_Gtid_Set the GTIDs fetched from the primary host by the replica to be executed Executed_Gtid_Set the GTIDs executed on the replica. This set remains the same for the entire cluster if the replicas are in sync Auto_Position it directs the replica to fetch the next GTID automatically

Create a Replica for the already setup cluster

The steps discussed in the previous section talks about the setting up replication on two fresh hosts. When we have to set up a replica for a host which is already serving applications, then the backup of the primary is used, either fresh backup taken for the replica (should only be done if the traffic it is serving is less) or use a recently taken backup.

If the size of the databases on the MySQL primary server is small, less than 100G recommended, then mysqldump can be used to take backup along with the following options.

mysqldump -uroot -p -hhost_ip -P3306 --all-databases --single-transaction --master-data=1 > primary_host.bkp\n

When GTID mode is enabled and mysqldump is executed, it includes the GTID executed to be used to start the replica after the backup position. The contents of the mysqldump output file will have the following

It is recommended to comment these before restoring otherwise they could throw errors. Also, using master-data=2 will automatically comment the master_log_file line.

Similarly, when taking backup of the host using xtrabackup, the file xtrabckup_info file contains the information about binlog file and file position, as well as the GTID executed set.

server_version = 8.0.25\nstart_time = 2021-06-22 03:45:17\nend_time = 2021-06-22 03:45:20\nlock_time = 0\nbinlog_pos = filename 'mysql-bin.000007', position '196', GTID of the last change 'e17d0920-d00e-11eb-a3e6-000d3aa00f87:1-5'\ninnodb_from_lsn = 0\ninnodb_to_lsn = 18153149\npartial = N\nincremental = N\nformat = file\ncompressed = N\nencrypted = N\n

Now, after setting MySQL server on the desired host, restore the backup taken from any one of the above methods. If the intended way is binlog-based replication, then use the binlog file and position info in the following command:

CHANGE REPLICATION SOURCE TO \nsource_host = \u2018primary_ip\u2019,\nsource_port = 3306,\nsource_user = \u2018repl_user\u2019,\nsource_password = \u2018xxxxx\u2019,\nsource_log_file = \u2018mysql-bin.000007\u2019,\nsource_log_pos = \u2018196\u2019;\n

If the replication needs to be set via GITDs, then run the below command to tell the replica about the GTIDs already executed. On the Replica host, run the following commands:

RESET MASTER;\n\nset global gtid_purged = \u2018e17d0920-d00e-11eb-a3e6-000d3aa00f87:1-5\u2019\n\nCHANGE REPLICATION SOURCE TO\nsource_host = \u2018primary_ip\u2019,\nsource_port = 3306,\nsource_user = \u2018repl_user\u2019,\nsource_password = \u2018xxxxx\u2019,\nsource_auto_position = 1\n

The reset master command resets the position of the binary log to initial. It can be skipped if the host is a freshly installed MySQL, but we restored a backup so it is necessary. The gtid_purged global variable lets the replica know the GTIDs that have already been executed, so that the replication can start after that. Then in the change source command, we set the auto-position to 1 which automatically gets the next GTID to proceed.

"},{"location":"level101/databases_sql/replication/#further-reading","title":"Further Reading","text":""},{"location":"level101/databases_sql/select_query/","title":"Select Query","text":""},{"location":"level101/databases_sql/select_query/#select-query","title":"SELECT Query","text":"

The most commonly used command while working with MySQL is SELECT. It is used to fetch the resultset from one or more tables. The general form of a typical select query looks like:

SELECT expr\nFROM table1\n[WHERE condition]\n[GROUP BY column_list HAVING condition]\n[ORDER BY column_list ASC|DESC]\n[LIMIT #]\n

The above general form contains some commonly used clauses of a SELECT query:

Let\u2019s have a look at some examples for a better understanding of the above. The dataset used for the examples below is available here and is free to use.

Select all records

mysql> SELECT * FROM employees LIMIT 5;\n+--------+------------+------------+-----------+--------+------------+\n| emp_no | birth_date | first_name | last_name | gender | hire_date  |\n+--------+------------+------------+-----------+--------+------------+\n|  10001 | 1953-09-02 | Georgi     | Facello   | M      | 1986-06-26 |\n|  10002 | 1964-06-02 | Bezalel    | Simmel    | F      | 1985-11-21 |\n|  10003 | 1959-12-03 | Parto      | Bamford   | M      | 1986-08-28 |\n|  10004 | 1954-05-01 | Chirstian  | Koblick   | M      | 1986-12-01 |\n|  10005 | 1955-01-21 | Kyoichi    | Maliniak  | M      | 1989-09-12 |\n+--------+------------+------------+-----------+--------+------------+\n5 rows in set (0.00 sec)\n

Select specific fields for all records

mysql> SELECT first_name, last_name, gender FROM employees LIMIT 5;\n+------------+-----------+--------+\n| first_name | last_name | gender |\n+------------+-----------+--------+\n| Georgi     | Facello   | M      |\n| Bezalel    | Simmel    | F      |\n| Parto      | Bamford   | M      |\n| Chirstian  | Koblick   | M      |\n| Kyoichi    | Maliniak  | M      |\n+------------+-----------+--------+\n5 rows in set (0.00 sec)\n

Select all records Where hire_date >= January 1, 1990

mysql> SELECT * FROM employees WHERE hire_date >= '1990-01-01' LIMIT 5;\n+--------+------------+------------+-------------+--------+------------+\n| emp_no | birth_date | first_name | last_name   | gender | hire_date  |\n+--------+------------+------------+-------------+--------+------------+\n|  10008 | 1958-02-19 | Saniya     | Kalloufi    | M      | 1994-09-15 |\n|  10011 | 1953-11-07 | Mary       | Sluis       | F      | 1990-01-22 |\n|  10012 | 1960-10-04 | Patricio   | Bridgland   | M      | 1992-12-18 |\n|  10016 | 1961-05-02 | Kazuhito   | Cappelletti | M      | 1995-01-27 |\n|  10017 | 1958-07-06 | Cristinel  | Bouloucos   | F      | 1993-08-03 |\n+--------+------------+------------+-------------+--------+------------+\n5 rows in set (0.01 sec)\n

Select first_name and last_name from all records Where birth_date >= 1960 AND gender = \u2018F\u2019

mysql> SELECT first_name, last_name FROM employees WHERE year(birth_date) >= 1960 AND gender='F' LIMIT 5;\n+------------+-----------+\n| first_name | last_name |\n+------------+-----------+\n| Bezalel    | Simmel    |\n| Duangkaew  | Piveteau  |\n| Divier     | Reistad   |\n| Jeong      | Reistad   |\n| Mingsen    | Casley    |\n+------------+-----------+\n5 rows in set (0.00 sec)\n

Display the total number of records

mysql> SELECT COUNT(*) FROM employees;\n+----------+\n| COUNT(*) |\n+----------+\n|   300024 |\n+----------+\n1 row in set (0.05 sec)\n

Display gender-wise count of all records

mysql> SELECT gender, COUNT(*) FROM employees GROUP BY gender;\n+--------+----------+\n| gender | COUNT(*) |\n+--------+----------+\n| M      |   179973 |\n| F      |   120051 |\n+--------+----------+\n2 rows in set (0.14 sec)\n

Display the year of hire_date and number of employees hired that year, also only those years where more than 20k employees were hired

mysql> SELECT year(hire_date), COUNT(*) FROM employees GROUP BY year(hire_date) HAVING COUNT(*) > 20000;\n+-----------------+----------+\n| year(hire_date) | COUNT(*) |\n+-----------------+----------+\n|            1985 |    35316 |\n|            1986 |    36150 |\n|            1987 |    33501 |\n|            1988 |    31436 |\n|            1989 |    28394 |\n|            1990 |    25610 |\n|            1991 |    22568 |\n|            1992 |    20402 |\n+-----------------+----------+\n8 rows in set (0.14 sec)\n

Display all records ordered by their hire_date in descending order. If hire_date is the same, then in order of their birth_date ascending order

mysql> SELECT * FROM employees ORDER BY hire_date DESC, birth_date ASC LIMIT 5;\n+--------+------------+------------+-----------+--------+------------+\n| emp_no | birth_date | first_name | last_name | gender | hire_date  |\n+--------+------------+------------+-----------+--------+------------+\n| 463807 | 1964-06-12 | Bikash     | Covnot    | M      | 2000-01-28 |\n| 428377 | 1957-05-09 | Yucai      | Gerlach   | M      | 2000-01-23 |\n| 499553 | 1954-05-06 | Hideyuki   | Delgrande | F      | 2000-01-22 |\n| 222965 | 1959-08-07 | Volkmar    | Perko     | F      | 2000-01-13 |\n|  47291 | 1960-09-09 | Ulf        | Flexer    | M      | 2000-01-12 |\n+--------+------------+------------+-----------+--------+------------+\n5 rows in set (0.12 sec)\n
"},{"location":"level101/databases_sql/select_query/#select-joins","title":"SELECT - JOINS","text":"

JOIN statement is used to produce a combined resultset from two or more tables based on certain conditions. It can be also used with UPDATE and DELETE statements, but we will be focussing on the select query.

Following is a basic general form for joins:

SELECT table1.col1, table2.col1, ... (any combination)\nFROM\ntable1 <join_type> table2\nON (or USING depends on join_type) table1.column_for_joining = table2.column_for_joining\nWHERE \u2026\n

Any number of columns can be selected, but it is recommended to select only those which are relevant to increase the readability of the resultset. All other clauses like WHERE, GROUP BY are not mandatory. Let\u2019s discuss the types of JOINs supported by MySQL Syntax.

Inner Join

This joins table A with table B on a condition. Only the records where the condition is True are selected in the resultset.

Display some details of employees along with their salary:

mysql> SELECT e.emp_no,e.first_name,e.last_name,s.salary FROM employees e JOIN salaries s ON e.emp_no=s.emp_no LIMIT 5;\n+--------+------------+-----------+--------+\n| emp_no | first_name | last_name | salary |\n+--------+------------+-----------+--------+\n|  10001 | Georgi     | Facello   |  60117 |\n|  10001 | Georgi     | Facello   |  62102 |\n|  10001 | Georgi     | Facello   |  66074 |\n|  10001 | Georgi     | Facello   |  66596 |\n|  10001 | Georgi     | Facello   |  66961 |\n+--------+------------+-----------+--------+\n5 rows in set (0.00 sec)\n

Similar result can be achieved by:

mysql> SELECT e.emp_no,e.first_name,e.last_name,s.salary FROM employees e JOIN salaries s USING (emp_no) LIMIT 5;\n+--------+------------+-----------+--------+\n| emp_no | first_name | last_name | salary |\n+--------+------------+-----------+--------+\n|  10001 | Georgi     | Facello   |  60117 |\n|  10001 | Georgi     | Facello   |  62102 |\n|  10001 | Georgi     | Facello   |  66074 |\n|  10001 | Georgi     | Facello   |  66596 |\n|  10001 | Georgi     | Facello   |  66961 |\n+--------+------------+-----------+--------+\n5 rows in set (0.00 sec)\n

And also by:

mysql> SELECT e.emp_no,e.first_name,e.last_name,s.salary FROM employees e NATURAL JOIN salaries s LIMIT 5;\n+--------+------------+-----------+--------+\n| emp_no | first_name | last_name | salary |\n+--------+------------+-----------+--------+\n|  10001 | Georgi     | Facello   |  60117 |\n|  10001 | Georgi     | Facello   |  62102 |\n|  10001 | Georgi     | Facello   |  66074 |\n|  10001 | Georgi     | Facello   |  66596 |\n|  10001 | Georgi     | Facello   |  66961 |\n+--------+------------+-----------+--------+\n5 rows in set (0.00 sec)\n

Outer Join

Majorly of two types:

Let us assume the below tables for understanding LEFT JOIN better.

mysql> SELECT * FROM dummy1;\n+----------+------------+\n| same_col | diff_col_1 |\n+----------+------------+\n|        1 | A          |\n|        2 | B          |\n|        3 | C          |\n+----------+------------+\n\nmysql> SELECT * FROM dummy2;\n+----------+------------+\n| same_col | diff_col_2 |\n+----------+------------+\n|        1 | X          |\n|        3 | Y          |\n+----------+------------+\n

A simple SELECT JOIN will look like the one below:

mysql> SELECT * FROM dummy1 d1 LEFT JOIN dummy2 d2 ON d1.same_col=d2.same_col;\n+----------+------------+----------+------------+\n| same_col | diff_col_1 | same_col | diff_col_2 |\n+----------+------------+----------+------------+\n|        1 | A          |        1 | X          |\n|        3 | C          |        3 | Y          |\n|        2 | B          |     NULL | NULL       |\n+----------+------------+----------+------------+\n3 rows in set (0.00 sec)\n

Which can also be written as:

mysql> SELECT * FROM dummy1 d1 LEFT JOIN dummy2 d2 USING(same_col);\n+----------+------------+------------+\n| same_col | diff_col_1 | diff_col_2 |\n+----------+------------+------------+\n|        1 | A          | X          |\n|        3 | C          | Y          |\n|        2 | B          | NULL       |\n+----------+------------+------------+\n3 rows in set (0.00 sec)\n

And also as:

mysql> SELECT * FROM dummy1 d1 NATURAL LEFT JOIN dummy2 d2;\n+----------+------------+------------+\n| same_col | diff_col_1 | diff_col_2 |\n+----------+------------+------------+\n|        1 | A          | X          |\n|        3 | C          | Y          |\n|        2 | B          | NULL       |\n+----------+------------+------------+\n3 rows in set (0.00 sec)\n

Cross Join

This does a cross product of table A and table B without any condition. It doesn\u2019t have a lot of applications in the real world.

A Simple CROSS JOIN looks like this:

mysql> SELECT * FROM dummy1 CROSS JOIN dummy2;\n+----------+------------+----------+------------+\n| same_col | diff_col_1 | same_col | diff_col_2 |\n+----------+------------+----------+------------+\n|        1 | A          |        3 | Y          |\n|        1 | A          |        1 | X          |\n|        2 | B          |        3 | Y          |\n|        2 | B          |        1 | X          |\n|        3 | C          |        3 | Y          |\n|        3 | C          |        1 | X          |\n+----------+------------+----------+------------+\n6 rows in set (0.01 sec)\n

One use case that can come in handy is when you have to fill in some missing entries. For example, all the entries from dummy1 must be inserted into a similar table dummy3, with each record must have 3 entries with statuses 1, 5 and 7.

mysql> DESC dummy3;\n+----------+----------+------+-----+---------+-------+\n| Field    | Type     | Null | Key | Default | Extra |\n+----------+----------+------+-----+---------+-------+\n| same_col | int      | YES  |     | NULL    |       |\n| value    | char(15) | YES  |     | NULL    |       |\n| status   | smallint | YES  |     | NULL    |       |\n+----------+----------+------+-----+---------+-------+\n3 rows in set (0.02 sec)\n

Either you create an INSERT query script with as many entries as in dummy1 or use CROSS JOIN to produce the required resultset.

mysql> SELECT * FROM dummy1 \nCROSS JOIN \n(SELECT 1 UNION SELECT 5 UNION SELECT 7) T2 \nORDER BY same_col;\n+----------+------------+---+\n| same_col | diff_col_1 | 1 |\n+----------+------------+---+\n|        1 | A          | 1 |\n|        1 | A          | 5 |\n|        1 | A          | 7 |\n|        2 | B          | 1 |\n|        2 | B          | 5 |\n|        2 | B          | 7 |\n|        3 | C          | 1 |\n|        3 | C          | 5 |\n|        3 | C          | 7 |\n+----------+------------+---+\n9 rows in set (0.00 sec)\n

The T2 section in the above query is called a sub-query. We will discuss the same in the next section.

Natural Join

This implicitly selects the common column from table A and table B and performs an inner join.

mysql> SELECT e.emp_no,e.first_name,e.last_name,s.salary FROM employees e NATURAL JOIN salaries s LIMIT 5;\n+--------+------------+-----------+--------+\n| emp_no | first_name | last_name | salary |\n+--------+------------+-----------+--------+\n|  10001 | Georgi     | Facello   |  60117 |\n|  10001 | Georgi     | Facello   |  62102 |\n|  10001 | Georgi     | Facello   |  66074 |\n|  10001 | Georgi     | Facello   |  66596 |\n|  10001 | Georgi     | Facello   |  66961 |\n+--------+------------+-----------+--------+\n5 rows in set (0.00 sec)\n

Notice how NATURAL JOIN and using takes care that the common column is displayed only once if you are not explicitly selecting columns for the query.

Some More Examples

Display emp_no, salary, title and dept of the employees where salary > 80000.

mysql> SELECT e.emp_no, s.salary, t.title, d.dept_no \nFROM  \nemployees e \nJOIN salaries s USING (emp_no) \nJOIN titles t USING (emp_no) \nJOIN dept_emp d USING (emp_no) \nWHERE s.salary > 80000 \nLIMIT 5;\n+--------+--------+--------------+---------+\n| emp_no | salary | title        | dept_no |\n+--------+--------+--------------+---------+\n|  10017 |  82163 | Senior Staff | d001    |\n|  10017 |  86157 | Senior Staff | d001    |\n|  10017 |  89619 | Senior Staff | d001    |\n|  10017 |  91985 | Senior Staff | d001    |\n|  10017 |  96122 | Senior Staff | d001    |\n+--------+--------+--------------+---------+\n5 rows in set (0.00 sec)\n

Display title-wise count of employees in each department ordered by dept_no:

mysql> SELECT d.dept_no, t.title, COUNT(*) \nFROM titles t \nLEFT JOIN dept_emp d USING (emp_no) \nGROUP BY d.dept_no, t.title \nORDER BY d.dept_no \nLIMIT 10;\n+---------+--------------------+----------+\n| dept_no | title              | COUNT(*) |\n+---------+--------------------+----------+\n| d001    | Manager            |        2 |\n| d001    | Senior Staff       |    13940 |\n| d001    | Staff              |    16196 |\n| d002    | Manager            |        2 |\n| d002    | Senior Staff       |    12139 |\n| d002    | Staff              |    13929 |\n| d003    | Manager            |        2 |\n| d003    | Senior Staff       |    12274 |\n| d003    | Staff              |    14342 |\n| d004    | Assistant Engineer |     6445 |\n+---------+--------------------+----------+\n10 rows in set (1.32 sec)\n
"},{"location":"level101/databases_sql/select_query/#select-subquery","title":"SELECT - Subquery","text":"

A subquery is generally a smaller resultset that can be used to power a SELECT query in many ways. It can be used in a WHERE condition, can be used in place of JOIN mostly where a JOIN could be an overkill. These subqueries are also termed as derived tables. They must have a table alias in the SELECT query.

Let\u2019s look at some examples of subqueries.

Here, we got the department name from the departments table by a subquery which used dept_no from dept_emp table.

mysql> SELECT e.emp_no, \n(SELECT dept_name FROM departments WHERE dept_no=d.dept_no) dept_name FROM employees e \nJOIN dept_emp d USING (emp_no) \nLIMIT 5;\n+--------+-----------------+\n| emp_no | dept_name       |\n+--------+-----------------+\n|  10001 | Development     |\n|  10002 | Sales           |\n|  10003 | Production      |\n|  10004 | Production      |\n|  10005 | Human Resources |\n+--------+-----------------+\n5 rows in set (0.01 sec)\n

Here, we used the AVG query above (which got the avg salary) as a subquery to list the employees whose latest salary is more than the average.

mysql> SELECT AVG(salary) FROM salaries;\n+-------------+\n| AVG(salary) |\n+-------------+\n|  63810.7448 |\n+-------------+\n1 row in set (0.80 sec)\n\nmysql> SELECT e.emp_no, MAX(s.salary) \nFROM employees e \nNATURAL JOIN salaries s \nGROUP BY e.emp_no \nHAVING MAX(s.salary) > (SELECT AVG(salary) FROM salaries) \nLIMIT 10;\n+--------+---------------+\n| emp_no | MAX(s.salary) |\n+--------+---------------+\n|  10001 |         88958 |\n|  10002 |         72527 |\n|  10004 |         74057 |\n|  10005 |         94692 |\n|  10007 |         88070 |\n|  10009 |         94443 |\n|  10010 |         80324 |\n|  10013 |         68901 |\n|  10016 |         77935 |\n|  10017 |         99651 |\n+--------+---------------+\n10 rows in set (0.56 sec)\n
"},{"location":"level101/git/branches/","title":"Working With Branches","text":"

Coming back to our local repo which has two commits. So far, what we have is a single line of history. Commits are chained in a single line. But sometimes you may have a need to work on two different features in parallel in the same repo. Now one option here could be making a new folder/repo with the same code and use that for another feature development. But there's a better way. Use branches. Since git follows tree-like structure for commits, we can use branches to work on different sets of features. From a commit, two or more branches can be created and branches can also be merged.

Using branches, there can exist multiple lines of histories and we can checkout to any of them and work on it. Checking out, as we discussed earlier, would simply mean replacing contents of the directory (repo) with the snapshot at the checked out version.

Let's create a branch and see how it looks like:

$ git branch b1\n$ git log --oneline --graph\n* 7f3b00e (HEAD -> master, b1) adding file 2\n* df2fb7a adding file 1\n

We create a branch called b1. Git log tells us that b1 also points to the last commit (7f3b00e) but the HEAD is still pointing to master. If you remember, HEAD points to the commit/reference wherever you are checkout to. So if we checkout to b1, HEAD should point to that. Let's confirm:

$ git checkout b1\nSwitched to branch 'b1'\n$ git log --oneline --graph\n* 7f3b00e (HEAD -> b1, master) adding file 2\n* df2fb7a adding file 1\n

b1 still points to the same commit but HEAD now points to b1. Since we create a branch at commit 7f3b00e, there will be two lines of histories starting this commit. Depending on which branch you are checked out on, the line of history will progress.

At this moment, we are checked out on branch b1, so making a new commit will advance branch reference b1 to that commit and current b1 commit will become its parent. Let's do that.

# Creating a file and making a commit\n$ echo \"I am a file in b1 branch\" > b1.txt\n$ git add b1.txt\n$ git commit -m \"adding b1 file\"\n[b1 872a38f] adding b1 file\n1 file changed, 1 insertion(+)\ncreate mode 100644 b1.txt\n\n# The new line of history\n$ git log --oneline --graph\n* 872a38f (HEAD -> b1) adding b1 file\n* 7f3b00e (master) adding file 2\n* df2fb7a adding file 1\n$\n

Do note that master is still pointing to the old commit it was pointing to. We can now checkout to master branch and make commits there. This will result in another line of history starting from commit 7f3b00e.

# checkout to master branch\n$ git checkout master\nSwitched to branch 'master'\n\n# Creating a new commit on master branch\n$ echo \"new file in master branch\" > master.txt\n$ git add master.txt\n$ git commit -m \"adding master.txt file\"\n[master 60dc441] adding master.txt file\n1 file changed, 1 insertion(+)\ncreate mode 100644 master.txt\n\n# The history line\n$ git log --oneline --graph\n* 60dc441 (HEAD -> master) adding master.txt file\n* 7f3b00e adding file 2\n* df2fb7a adding file 1\n

Notice how branch b1 is not visible here since we are on the master. Let's try to visualize both to get the whole picture:

$ git log --oneline --graph --all\n* 60dc441 (HEAD -> master) adding master.txt file\n| * 872a38f (b1) adding b1 file\n|/\n* 7f3b00e adding file 2\n* df2fb7a adding file 1\n

Above tree structure should make things clear. Notice a clear branch/fork on commit 7f3b00e. This is how we create branches. Now they both are two separate lines of history on which feature development can be done independently.

To reiterate, internally, git is just a tree of commits. Branch names (human readable) are pointers to those commits in the tree. We use various git commands to work with the tree structure and references. Git accordingly modifies contents of our repo.

"},{"location":"level101/git/branches/#merges","title":"Merges","text":"

Now say the feature you were working on branch b1 is complete and you need to merge it on master branch, where all the final version of code goes. So first, you will checkout to branch master and then you pull the latest code from upstream (eg: GitHub). Then you need to merge your code from b1 into master. There could be two ways this can be done.

Here is the current history:

$ git log --oneline --graph --all\n* 60dc441 (HEAD -> master) adding master.txt file\n| * 872a38f (b1) adding b1 file\n|/\n* 7f3b00e adding file 2\n* df2fb7a adding file 1\n

Option 1: Directly merge the branch. Merging the branch b1 into master will result in a new merge commit. This will merge changes from two different lines of history and create a new commit of the result.

$ git merge b1\nMerge made by the 'recursive' strategy.\nb1.txt | 1 +\n1 file changed, 1 insertion(+)\ncreate mode 100644 b1.txt\n$ git log --oneline --graph --all\n*   8fc28f9 (HEAD -> master) Merge branch 'b1'\n|\\\n| * 872a38f (b1) adding b1 file\n* | 60dc441 adding master.txt file\n|/\n* 7f3b00e adding file 2\n* df2fb7a adding file 1\n

You can see a new merge commit created (8fc28f9). You will be prompted for the commit message. If there are a lot of branches in the repo, this result will end-up with a lot of merge commits. Which looks ugly compared to a single line of history of development. So let's look at an alternative approach.

First, let's reset our last merge and go to the previous state.

$ git reset --hard 60dc441\nHEAD is now at 60dc441 adding master.txt file\n$ git log --oneline --graph --all\n* 60dc441 (HEAD -> master) adding master.txt file\n| * 872a38f (b1) adding b1 file\n|/\n* 7f3b00e adding file 2\n* df2fb7a adding file 1\n

Option 2: Rebase. Now, instead of merging two branches which has a similar base (commit: 7f3b00e), let us rebase branch b1 on to current master. What this means is take branch b1 (from commit 7f3b00e to commit 872a38f) and rebase (put them on top of) master (60dc441).

# Switch to b1\n$ git checkout b1\nSwitched to branch 'b1'\n\n# Rebase (b1 which is current branch) on master\n$ git rebase master\nFirst, rewinding head to replay your work on top of it...\nApplying: adding b1 file\n\n# The result\n$ git log --oneline --graph --all\n* 5372c8f (HEAD -> b1) adding b1 file\n* 60dc441 (master) adding master.txt file\n* 7f3b00e adding file 2\n* df2fb7a adding file 1\n

You can see b1 which had 1 commit. That commit's parent was 7f3b00e. But since we rebase it on master (60dc441). That becomes the parent now. As a side effect, you also see it has become a single line of history. Now if we were to merge b1 into master, it would simply mean change master to point to 5372c8f which is b1. Let's try it:

# checkout to master since we want to merge code into master\n$ git checkout master\nSwitched to branch 'master'\n\n# the current history, where b1 is based on master\n$ git log --oneline --graph --all\n* 5372c8f (b1) adding b1 file\n* 60dc441 (HEAD -> master) adding master.txt file\n* 7f3b00e adding file 2\n* df2fb7a adding file 1\n\n\n# Performing the merge, notice the \"fast-forward\" message\n$ git merge b1\nUpdating 60dc441..5372c8f\nFast-forward\nb1.txt | 1 +\n1 file changed, 1 insertion(+)\ncreate mode 100644 b1.txt\n\n# The Result\n$ git log --oneline --graph --all\n* 5372c8f (HEAD -> master, b1) adding b1 file\n* 60dc441 adding master.txt file\n* 7f3b00e adding file 2\n* df2fb7a adding file 1\n

Now you see both b1 and master are pointing to the same commit. Your code has been merged to the master branch and it can be pushed. Also we have clean line of history! :D

"},{"location":"level101/git/conclusion/","title":"Conclusion","text":""},{"location":"level101/git/conclusion/#what-next-from-here","title":"What next from here?","text":"

There are a lot of git commands and features which we have not explored here. But with the base built-up, be sure to explore concepts like

"},{"location":"level101/git/git-basics/","title":"Git","text":""},{"location":"level101/git/git-basics/#prerequisites","title":"Prerequisites","text":"
  1. Have Git installed https://git-scm.com/downloads
  2. Have taken any git high-level tutorial or following LinkedIn learning courses
"},{"location":"level101/git/git-basics/#what-to-expect-from-this-course","title":"What to expect from this course","text":"

As an engineer in the field of computer science, having knowledge of version control tools becomes almost a requirement. While there are a lot of version control tools that exist today like SVN, Mercurial, etc, Git perhaps is the most used one and this course we will be working with Git. While this course does not start with Git 101 and expects basic knowledge of git as a prerequisite, it will reintroduce the git concepts known by you with details covering what is happening under the hood as you execute various git commands. So that next time you run a git command, you will be able to press enter more confidently!

"},{"location":"level101/git/git-basics/#what-is-not-covered-under-this-course","title":"What is not covered under this course","text":"

Advanced usage and specifics of internal implementation details of Git.

"},{"location":"level101/git/git-basics/#course-contents","title":"Course Contents","text":"
  1. Git Basics
  2. Working with Branches
  3. Git with Github
  4. Hooks
"},{"location":"level101/git/git-basics/#git-basics","title":"Git Basics","text":"

Though you might be aware already, let's revisit why we need a version control system. As the project grows and multiple developers start working on it, an efficient method for collaboration is warranted. Git helps the team collaborate easily and also maintains the history of the changes happening with the codebase.

"},{"location":"level101/git/git-basics/#creating-a-git-repo","title":"Creating a Git Repo","text":"

Any folder can be converted into a git repository. After executing the following command, we will see a .git folder within the folder, which makes our folder a git repository. All the magic that git does, .git folder is the enabler for the same.

# creating an empty folder and changing current dir to it\n$ cd /tmp\n$ mkdir school-of-sre\n$ cd school-of-sre/\n\n# initialize a git repo\n$ git init\nInitialized empty Git repository in /private/tmp/school-of-sre/.git/\n

As the output says, an empty git repo has been initialized in our folder. Let's take a look at what is there.

$ ls .git/\nHEAD        config      description hooks       info        objects     refs\n

There are a bunch of folders and files in the .git folder. As I said, all these enable git to do its magic. We will look into some of these folders and files. But for now, what we have is an empty git repository.

"},{"location":"level101/git/git-basics/#tracking-a-file","title":"Tracking a File","text":"

Now as you might already know, let us create a new file in our repo (we will refer to the folder as repo now.) And see git status:

$ echo \"I am file 1\" > file1.txt\n$ git status\nOn branch master\n\nNo commits yet\n\nUntracked files:\n (use \"git add <file>...\" to include in what will be committed)\n\n       file1.txt\n\nnothing added to commit but untracked files present (use \"git add\" to track)\n

The current git status says No commits yet and there is one untracked file. Since we just created the file, git is not tracking that file. We explicitly need to ask git to track files and folders. (Also checkout gitignore) And how we do that is via git add command as suggested in the above output. Then, we go ahead and create a commit.

$ git add file1.txt\n$ git status\nOn branch master\n\nNo commits yet\n\nChanges to be committed:\n (use \"git rm --cached <file>...\" to unstage)\n\n       new file:   file1.txt\n\n$ git commit -m \"adding file 1\"\n[master (root-commit) df2fb7a] adding file 1\n1 file changed, 1 insertion(+)\ncreate mode 100644 file1.txt\n

Notice how after adding the file, git status says Changes to be committed:. What it means is whatever is listed there, will be included in the next commit. Then, we go ahead and create a commit, with an attached message via -m.

"},{"location":"level101/git/git-basics/#more-about-a-commit","title":"More About a Commit","text":"

Commit is a snapshot of the repo. Whenever a commit is made, a snapshot of the current state of repo (the folder) is taken and saved. Each commit has a unique ID. (df2fb7a for the commit we made in the previous step). As we keep adding/changing more and more contents and keep making commits, all those snapshots are stored by git. Again, all this magic happens inside the .git folder. This is where all this snapshot or versions are stored in an efficient manner.

"},{"location":"level101/git/git-basics/#adding-more-changes","title":"Adding More Changes","text":"

Let us create one more file and commit the change. It would look the same as the previous commit we made.

$ echo \"I am file 2\" > file2.txt\n$ git add file2.txt\n$ git commit -m \"adding file 2\"\n[master 7f3b00e] adding file 2\n1 file changed, 1 insertion(+)\ncreate mode 100644 file2.txt\n

A new commit with ID 7f3b00e has been created. You can issue git status at any time to see the state of the repository.

   **IMPORTANT: Note that commit IDs are long string (SHA) but we can refer to a commit by its initial few (8 or more) characters too. We will interchangeably using shorter and longer commit IDs.**\n

Now that we have two commits, let's visualize them:

$ git log --oneline --graph\n* 7f3b00e (HEAD -> master) adding file 2\n* df2fb7a adding file 1\n

git log, as the name suggests, prints the log of all the git commits. Here you see two additional arguments, --oneline prints the shorter version of the log, ie: the commit message only and not the person who made the commit and when. --graph prints it in graph format.

Now at this moment, the commits might look like just one in each line but all commits are stored as a tree like data structure internally by git. That means there can be two or more children commits of a given commit. And not just a single line of commits. We will look more into this part when we get to the Branches section. For now, this is our commit history:

   df2fb7a ===> 7f3b00e\n
"},{"location":"level101/git/git-basics/#are-commits-really-linked","title":"Are commits really linked?","text":"

As I just said, the two commits we just made are linked via tree like data structure and we saw how they are linked. But let's actually verify it. Everything in git is an object. Newly created files are stored as an object. Changes to file are stored as an objects and even commits are objects. To view contents of an object, we can use the following command with the object's ID. We will take a look at the contents of the second commit:

$ git cat-file -p 7f3b00e\ntree ebf3af44d253e5328340026e45a9fa9ae3ea1982\nparent df2fb7a61f5d40c1191e0fdeb0fc5d6e7969685a\nauthor Sanket Patel <spatel1@linkedin.com> 1603273316 -0700\ncommitter Sanket Patel <spatel1@linkedin.com> 1603273316 -0700\n\nadding file 2\n

Take a note of parent attribute in the above output. It points to the commit id of the first commit we made. So this proves that they are linked! Additionally, you can see the second commit's message in this object. As I said all this magic is enabled by .git folder and the object to which we are looking at also is in that folder.

$ ls .git/objects/7f/3b00eaa957815884198e2fdfec29361108d6a9\n.git/objects/7f/3b00eaa957815884198e2fdfec29361108d6a9\n

It is stored in .git/objects/ folder. All the files and changes to them as well are stored in this folder.

"},{"location":"level101/git/git-basics/#the-version-control-part-of-git","title":"The Version Control part of Git","text":"

We already can see two commits (versions) in our git log. One thing a version control tool gives you is ability to browse back and forth in history. For example: some of your users are running an old version of code and they are reporting an issue. In order to debug the issue, you need access to the old code. The one in your current repo is the latest code. In this example, you are working on the second commit (7f3b00e) and someone reported an issue with the code snapshot at commit (df2fb7a). This is how you would get access to the code at any older commit.

# Current contents, two files present\n$ ls\nfile1.txt file2.txt\n\n# checking out to (an older) commit\n$ git checkout df2fb7a\nNote: checking out 'df2fb7a'.\n\nYou are in 'detached HEAD' state. You can look around, make experimental\nchanges and commit them, and you can discard any commits you make in this\nstate without impacting any branches by performing another checkout.\n\nIf you want to create a new branch to retain commits you create, you may\ndo so (now or later) by using -b with the checkout command again. Example:\n\n git checkout -b <new-branch-name>\n\nHEAD is now at df2fb7a adding file 1\n\n# checking contents, can verify it has old contents\n$ ls\nfile1.txt\n

So this is how we would get access to old versions/snapshots. All we need is a reference to that snapshot. Upon executing git checkout ..., what git does for you is use the .git folder, see what was the state of things (files and folders) at that version/reference and replace the contents of current directory with those contents. The then-existing content will no longer be present in the local dir (repo) but we can and will still get access to them because they are tracked via git commit and .git folder has them stored/tracked.

"},{"location":"level101/git/git-basics/#reference","title":"Reference","text":"

I mention in the previous section that we need a reference to the version. By default, git repo is made of tree of commits. And each commit has a unique IDs. But the unique ID is not the only thing we can reference commits via. There are multiple ways to reference commits. For example: HEAD is a reference to current commit. Whatever commit your repo is checked out at, HEAD will point to that. HEAD~1 is reference to previous commit. So while checking out previous version in section above, we could have done git checkout HEAD~1.

Similarly, master is also a reference (to a branch). Since git uses tree like structure to store commits, there of course will be branches. And the default branch is called master. Master (or any branch reference) will point to the latest commit in the branch. Even though we have checked out to the previous commit in out repo, master still points to the latest commit. And we can get back to the latest version by checkout at master reference

$ git checkout master\nPrevious HEAD position was df2fb7a adding file 1\nSwitched to branch 'master'\n\n# now we will see latest code, with two files\n$ ls\nfile1.txt file2.txt\n

Note, instead of master in above command, we could have used commit's ID as well.

"},{"location":"level101/git/git-basics/#references-and-the-magic","title":"References and The Magic","text":"

Let's look at the state of things. Two commits, master and HEAD references are pointing to the latest commit

$ git log --oneline --graph\n* 7f3b00e (HEAD -> master) adding file 2\n* df2fb7a adding file 1\n

The magic? Let's examine these files:

$ cat .git/refs/heads/master\n7f3b00eaa957815884198e2fdfec29361108d6a9\n

Viola! Where master is pointing to is stored in a file. Whenever git needs to know where master reference is pointing to, or if git needs to update where master points, it just needs to update the file above. So when you create a new commit, a new commit is created on top of the current commit and the master file is updated with the new commit's ID.

Similary, for HEAD reference:

$ cat .git/HEAD\nref: refs/heads/master\n

We can see HEAD is pointing to a reference called refs/heads/master. So HEAD will point where ever the master points.

"},{"location":"level101/git/git-basics/#little-adventure","title":"Little Adventure","text":"

We discussed how git will update the files as we execute commands. But let's try to do it ourselves, by hand, and see what happens.

$ git log --oneline --graph\n* 7f3b00e (HEAD -> master) adding file 2\n* df2fb7a adding file 1\n

Now, let's change master to point to the previous/first commit.

$ echo df2fb7a61f5d40c1191e0fdeb0fc5d6e7969685a > .git/refs/heads/master\n$ git log --oneline --graph\n* df2fb7a (HEAD -> master) adding file 1\n\n# RESETTING TO ORIGINAL\n$ echo 7f3b00eaa957815884198e2fdfec29361108d6a9 > .git/refs/heads/master\n$ git log --oneline --graph\n* 7f3b00e (HEAD -> master) adding file 2\n* df2fb7a adding file 1\n

We just edited the master reference file and now we can see only the first commit in git log. Undoing the change to the file brings the state back to original. Not so much of magic, is it?

"},{"location":"level101/git/github-hooks/","title":"Git with GitHub","text":"

Till now all the operations we did were in our local repo while git also helps us in a collaborative environment. GitHub is one place on the Internet where you can centrally host your git repos and collaborate with other developers.

Most of the workflow will remain the same as we discussed, with addition of couple of things:

  1. Pull: to pull latest changes from GitHub (the central) repo
  2. Push: to push your changes to GitHub repo so that it's available to all people

GitHub has written nice guides and tutorials about this and you can refer to them here:

"},{"location":"level101/git/github-hooks/#hooks","title":"Hooks","text":"

Git has another nice feature called hooks. Hooks are basically scripts which will be called when a certain event happens. Here is where hooks are located:

$ ls .git/hooks/\napplypatch-msg.sample     fsmonitor-watchman.sample pre-applypatch.sample     pre-push.sample           pre-receive.sample        update.sample\ncommit-msg.sample         post-update.sample        pre-commit.sample         pre-rebase.sample         prepare-commit-msg.sample\n

Names are self-explanatory. These hooks are useful when you want to do certain things when a certain event happens. If you want to run tests before pushing code, you would want to setup pre-push hooks. Let's try to create a pre commit hook.

$ echo \"echo this is from pre commit hook\" > .git/hooks/pre-commit\n$ chmod +x .git/hooks/pre-commit\n

We basically create a file called pre-commit in hooks folder and make it executable. Now if we make a commit, we should see the message getting printed.

$ echo \"sample file\" > sample.txt\n$ git add sample.txt\n$ git commit -m \"adding sample file\"\nthis is from pre commit hook     # <===== THE MESSAGE FROM HOOK EXECUTION\n[master 9894e05] adding sample file\n1 file changed, 1 insertion(+)\ncreate mode 100644 sample.txt\n
"},{"location":"level101/linux_basics/command_line_basics/","title":"Command Line Basics","text":""},{"location":"level101/linux_basics/command_line_basics/#lab-environment-setup","title":"Lab Environment Setup","text":"

One can use an online Bash interpreter to run all the commands that are provided as examples in this course. This will also help you in getting a hands-on experience of various Linux commands.

REPL is one of the popular online Bash interpreters for running Linux commands. We will be using it for running all the commands mentioned in this course.

"},{"location":"level101/linux_basics/command_line_basics/#what-is-a-command","title":"What is a Command","text":"

A command is a program that tells the operating system to perform specific work. Programs are stored as files in Linux. Therefore, a command is also a file which is stored somewhere on the disk.

Commands may also take additional arguments as input from the user. These arguments are called command line arguments. Knowing how to use the commands is important and there are many ways to get help in Linux, especially for commands. Almost every command will have some form of documentation, most commands will have a command-line argument -h or --help that will display a reasonable amount of documentation. But the most popular documentation system in Linux is called man pages\u2014short for manual pages.

Using --help to show the documentation for ls command.

"},{"location":"level101/linux_basics/command_line_basics/#file-system-organization","title":"File System Organization","text":"

The Linux file system has a hierarchical (or tree-like) structure with its highest-level directory called root (denoted by /). Directories present inside the root directory stores files related to the system. These directories in turn can either store system files or application files or user-related files.

Directory Description bin The executable program of most commonly used commands reside in bin directory dev This directory contains files related to devices on the system etc This directory contains all the system configuration files home This directory contains user-related files and directories lib This directory contains all the library files mnt This directory contains files related to mounted devices on the system proc This directory contains files related to the running processes on the system root This directory contains root user-related files and directories sbin This directory contains programs used for system administration tmp This directory is used to store temporary files on the system usr This directory is used to store application programs on the system"},{"location":"level101/linux_basics/command_line_basics/#commands-for-navigating-the-file-system","title":"Commands for Navigating the File System","text":"

There are three basic commands which are used frequently to navigate the file system:

We will now try to understand what each command does and how to use these commands. You should also practice the given examples on the online Bash shell.

"},{"location":"level101/linux_basics/command_line_basics/#pwd-print-working-directory","title":"pwd (print working directory)","text":"

At any given moment of time, we will be standing in a certain directory. To get the name of the directory in which we are standing, we can use the pwd command in Linux.

We will now use the cd command to move to a different directory and then print the working directory.

"},{"location":"level101/linux_basics/command_line_basics/#cd-change-directory","title":"cd (change directory)","text":"

The cd command can be used to change the working directory. Using the command, you can move from one directory to another.

In the below example, we are initially in the root directory. We have then used the cd command to change the directory.

"},{"location":"level101/linux_basics/command_line_basics/#ls-list-files-and-directories","title":"ls (list files and directories)**","text":"

The ls command is used to list the contents of a directory. It will list down all the files and folders present in the given directory.

If we just type ls in the shell, it will list all the files and directories present in the current directory.

We can also provide the directory name as argument to ls command. It will then list all the files and directories inside the given directory.

"},{"location":"level101/linux_basics/command_line_basics/#commands-for-manipulating-files","title":"Commands for Manipulating Files","text":"

There are five basic commands which are used frequently to manipulate files:

We will now try to understand what each command does and how to use these commands. You should also practice the given examples on the online Bash shell.

"},{"location":"level101/linux_basics/command_line_basics/#touch-create-new-file","title":"touch (create new file)","text":"

The touch command can be used to create an empty new file. This command is very useful for many other purposes, but we will discuss the simplest use case of creating a new file.

General syntax of using touch command:

touch <file_name>\n

"},{"location":"level101/linux_basics/command_line_basics/#mkdir-create-new-directories","title":"mkdir (create new directories)","text":"

The mkdir command is used to create directories. You can use ls command to verify that the new directory is created.

General syntax of using mkdir command:

mkdir <directory_name>\n

"},{"location":"level101/linux_basics/command_line_basics/#rm-delete-files-and-directories","title":"rm (delete files and directories)","text":"

The rm command can be used to delete files and directories. It is very important to note that this command permanently deletes the files and directories. It's almost impossible to recover these files and directories once you have executed rm command on them successfully. Do run this command with care.

General syntax of using rm command:

rm <file_name>\n

Let's try to understand the rm command with an example. We will try to delete the file and directory we created using touch and mkdir command respectively.

"},{"location":"level101/linux_basics/command_line_basics/#cp-copy-files-and-directories","title":"cp (copy files and directories)","text":"

The cp command is used to copy files and directories from one location to another. Do note that the cp command doesn't do any change to the original files or directories. The original files or directories and their copy both co-exist after running cp command successfully.

General syntax of using cp command:

cp <source_path> <destination_path>\n

We are currently in the /home/runner directory. We will use the mkdir command to create a new directory named test_directory. We will now try to copy the _test_runner.py file to the directory we created just now.

Do note that nothing happened to the original _test_runner.py file. It's still there in the current directory. A new copy of it got created inside the test_directory.

We can also use the cp command to copy the whole directory from one location to another. Let's try to understand this with an example.

We again used the mkdir command to create a new directory called another_directory. We then used the cp command along with an additional argument -r to copy the test_directory.

mv (move files and directories)

The mv command can either be used to move files or directories from one location to another or it can be used to rename files or directories. Do note that moving files and copying them are very different. When you move the files or directories, the original copy is lost.

General syntax of using mv command:

mv <source_path> <destination_path>\n

In this example, we will use the mv command to move the _test_runner.py file to test_directory. In this case, this file already exists in test_directory. The mv command will just replace it. Do note that the original file doesn't exist in the current directory after mv command ran successfully.

We can also use the mv command to move a directory from one location to another. In this case, we do not need to use the -r flag that we did while using the cp command. Do note that the original directory will not exist if we use mv command.

One of the important uses of the mv command is to rename files and directories. Let's see how we can use this command for renaming.

We have first changed our location to test_directory. We then use the mv command to rename the _test_runner.py file to test.py.

"},{"location":"level101/linux_basics/command_line_basics/#commands-for-viewing-files","title":"Commands for Viewing Files","text":"

There are five basic commands which are used frequently to view the files:

We will now try to understand what each command does and how to use these commands. You should also practice the given examples on the online Bash shell.

We will create a new file called numbers.txt and insert numbers from 1 to 100 in this file. Each number will be in a separate line.

Do not worry about the above command now. It's an advanced command which is used to generate numbers. We have then used a redirection operator to push these numbers to the file. We will be discussing I/O redirection in the later sections.

"},{"location":"level101/linux_basics/command_line_basics/#cat","title":"cat","text":"

The most simplest use of cat command is to print the contents of the file on your output screen. This command is very useful and can be used for many other purposes. We will study about other use cases later.

You can try to run the above command and you will see numbers being printed from 1 to 100 on your screen. You will need to scroll up to view all the numbers.

"},{"location":"level101/linux_basics/command_line_basics/#head","title":"head","text":"

The head command displays the first 10 lines of the file by default. We can include additional arguments to display as many lines as we want from the top.

In this example, we are only able to see the first 10 lines from the file when we use the head command.

By default, head command will only display the first 10 lines. If we want to specify the number of lines we want to see from start, use the -n argument to provide the input.

"},{"location":"level101/linux_basics/command_line_basics/#tail","title":"tail","text":"

The tail command displays the last 10 lines of the file by default. We can include additional arguments to display as many lines as we want from the end of the file.

By default, the tail command will only display the last 10 lines. If we want to specify the number of lines we want to see from the end, use -n argument to provide the input.

In this example, we are only able to see the last 5 lines from the file when we use the tail command with explicit -n option.

"},{"location":"level101/linux_basics/command_line_basics/#more","title":"more","text":"

The more command displays the contents of a file or a command output, displaying one screen at a time in case the file is large (Eg: log files). It also allows forward navigation and limited backward navigation in the file.

The more command displays as much as can fit on the current screen and waits for user input to advance. Forward navigation can be done by pressing Enter, which advances the output by one line and Space, which advances the output by one screen.

"},{"location":"level101/linux_basics/command_line_basics/#less","title":"less","text":"

The less command is an improved version of more. It displays the contents of a file or a command output, one page at a time. It allows backward navigation as well as forward navigation in the file and also has search options. We can use arrow keys for advancing backward or forward by one line. For moving forward by one page, press Space and for moving backward by one page, press b on your keyboard. You can go to the beginning and the end of a file instantly.

"},{"location":"level101/linux_basics/command_line_basics/#echo-command-in-linux","title":"Echo Command in Linux","text":"

The echo command is one of the simplest commands that is used in the shell. This command is equivalent to print in other programming languages.

The echo command prints the given input string on the screen.

"},{"location":"level101/linux_basics/command_line_basics/#text-processing-commands","title":"Text Processing Commands","text":"

In the previous section, we learned how to view the content of a file. In many cases, we will be interested in performing the below operations:

There are three basic commands which are used frequently to process texts:

We will now try to understand what each command does and how to use these commands. You should also practice the given examples on the online Bash shell.

We will create a new file called numbers.txt and insert numbers from 1 to 10 in this file. Each number will be in a separate line.

"},{"location":"level101/linux_basics/command_line_basics/#grep","title":"grep","text":"

The grep command in its simplest form can be used to search particular words in a text file. It will display all the lines in a file that contains a particular input. The word we want to search is provided as an input to the grep command.

General syntax of using grep command:

grep <word_to_search> <file_name>\n

In this example, we are trying to search for a string \"1\" in this file. The grep command outputs the lines where it found this string.

"},{"location":"level101/linux_basics/command_line_basics/#sed","title":"sed","text":"

The sed command in its simplest form can be used to replace a text in a file.

General syntax of using the sed command for replacement:

sed 's/<text_to_replace>/<replacement_text>/' <file_name>\n

Let's try to replace each occurrence of \"1\" in the file with \"3\" using sed command.

The content of the file will not change in the above example. To do so, we have to use an extra argument -i so that the changes are reflected back in the file.

"},{"location":"level101/linux_basics/command_line_basics/#sort","title":"sort","text":"

The sort command can be used to sort the input provided to it as an argument. By default, it will sort in increasing order.

Let's first see the content of the file before trying to sort it.

Now, we will try to sort the file using the sort command. The sort command sorts the content in lexicographical order.

The content of the file will not change in the above example.

"},{"location":"level101/linux_basics/command_line_basics/#io-redirection","title":"I/O Redirection","text":"

Each open file gets assigned a file descriptor. A file descriptor is an unique identifier for open files in the system. There are always three default files open, stdin (the keyboard), stdout (the screen), and stderr (error messages output to the screen). These files can be redirected.

Everything is a file in Linux - https://unix.stackexchange.com/questions/225537/everything-is-a-file

Till now, we have displayed all the output on the screen which is the standard output. We can use some special operators to redirect the output of the command to files or even to the input of other commands. I/O redirection is a very powerful feature.

In the below example, we have used the > operator to redirect the output of ls command to output.txt file.

In the below example, we have redirected the output from echo command to a file.

We can also redirect the output of a command as an input to another command. This is possible with the help of pipes.

In the below example, we have passed the output of cat command as an input to grep command using pipe (|) operator.

In the below example, we have passed the output of sort command as an input to uniq command using pipe (|) operator. The uniq command only prints the unique numbers from the input.

I/O redirection - https://tldp.org/LDP/abs/html/io-redirection.html

"},{"location":"level101/linux_basics/conclusion/","title":"Conclusion","text":"

We have covered the basics of Linux operating systems and basic commands used in Linux. We have also covered the Linux server administration commands.

We hope that this course will make it easier for you to operate on the command line.

"},{"location":"level101/linux_basics/conclusion/#applications-in-sre-role","title":"Applications in SRE Role","text":"
  1. As a SRE, you will be required to perform some general tasks on these Linux servers. You will also be using the command line when you are troubleshooting issues.
  2. Moving from one location to another in the filesystem will require the help of ls, pwd and cd commands.
  3. You may need to search some specific information in the log files. grep command would be very useful here. I/O redirection will become handy if you want to store the output in a file or pass it as an input to another command.
  4. tail command is very useful to view the latest data in the log file.
  5. Different users will have different permissions depending on their roles. We will also not want everyone in the company to access our servers for security reasons. Users permissions can be restricted with chown, chmod and chgrp commands.
  6. ssh is one of the most frequently used commands for a SRE. Logging into servers and troubleshooting along with performing basic administration tasks will only be possible if we are able to login into the server.
  7. What if we want to run an Apache server or NGINX on a server? We will first install it using the package manager. Package management commands become important here.
  8. Managing services on servers is another critical responsibility of a SRE. systemd-related commands can help in troubleshooting issues. If a service goes down, we can start it using systemctl start command. We can also stop a service in case it is not needed.
  9. Monitoring is another core responsibility of a SRE. Memory and CPU are two important system-level metrics which should be monitored. Commands like top and free are quite helpful here.
  10. If a service throws an error, how do we find out the root cause of the error? We will certainly need to check logs to find out the whole stack trace of the error. The log file will also tell us the number of times the error has occurred along with time when it started.
"},{"location":"level101/linux_basics/conclusion/#useful-courses-and-tutorials","title":"Useful Courses and Tutorials","text":""},{"location":"level101/linux_basics/intro/","title":"Linux Basics","text":""},{"location":"level101/linux_basics/intro/#introduction","title":"Introduction","text":""},{"location":"level101/linux_basics/intro/#prerequisites","title":"Prerequisites","text":""},{"location":"level101/linux_basics/intro/#what-to-expect-from-this-course","title":"What to expect from this course","text":"

This course is divided into three parts. In the first part, we cover the fundamentals of Linux operating systems. We will talk about Linux architecture, Linux distributions and uses of Linux operating systems. We will also talk about the difference between GUI and CLI.

In the second part, we cover some basic commands used in Linux. We will focus on commands used for navigating the file system, viewing and manipulating files, I/O redirection, etc.

In the third part, we cover Linux system administration. This includes day-to-day tasks performed by Linux admins, like managing users/groups, managing file permissions, monitoring system performance, log files etc.

In the second and third part, we will be showing examples to understand the concepts.

"},{"location":"level101/linux_basics/intro/#what-is-not-covered-under-this-course","title":"What is not covered under this course","text":"

We are not covering advanced Linux commands and Bash scripting in this course. We will also not be covering Linux internals.

"},{"location":"level101/linux_basics/intro/#course-contents","title":"Course Contents","text":"

The following topics has been covered in this course:

"},{"location":"level101/linux_basics/intro/#what-are-linux-operating-systems","title":"What are Linux operating systems","text":"

Most of us are familiar with the Windows operating system used in more than 75% of the personal computers. The Windows operating systems are based on Windows NT kernel.

A kernel is the most important part of an operating system\u2014it performs important functions like process management, memory management, filesystem management, etc.

Linux operating systems are based on the Linux kernel. A Linux-based operating system will consist of Linux kernel, GUI/CLI, system libraries and system utilities. The Linux kernel was independently developed and released by Linus Torvalds. The Linux kernel is free and open-source (See https://github.com/torvalds/linux).

Linux is a kernel and not a complete operating system. Linux kernel is combined with GNU system to make a complete operating system. Therefore, Linux-based operating systems are also called as GNU/Linux systems. GNU is an extensive collection of free softwares like compiler, debugger, C library etc. (See Linux and the GNU System)

History of Linux - https://en.wikipedia.org/wiki/History_of_Linux

"},{"location":"level101/linux_basics/intro/#what-are-popular-linux-distributions","title":"What are popular Linux distributions","text":"

A Linux distribution (distro) is an operating system based on the Linux kernel and a package management system. A package management system consists of tools that help in installing, upgrading, configuring and removing softwares on the operating system.

Software are usually adopted to a distribution and are packaged in a distro-specific format. These packages are available through a distro-specific repository. Packages are installed and managed in the operating system by a package manager.

List of popular Linux distributions:

Packaging systems Distributions Package manager Debian style (.deb) Debian, Ubuntu APT Red Hat style (.rpm) Fedora, CentOS, Red Hat Enterprise Linux YUM"},{"location":"level101/linux_basics/intro/#linux-architecture","title":"Linux Architecture","text":""},{"location":"level101/linux_basics/intro/#uses-of-linux-operating-systems","title":"Uses of Linux Operating Systems","text":"

Operating system based on Linux kernel are widely used in:

"},{"location":"level101/linux_basics/intro/#graphical-user-interface-gui-vs-command-line-interface-cli","title":"Graphical user interface (GUI) vs Command line interface (CLI)","text":"

A user interacts with a computer with the help of user interfaces. The user interface can be either GUI or CLI.

Graphical user interface allows a user to interact with the computer using graphics such as icons and images. When a user clicks on an icon to open an application on a computer, he or she is actually using the GUI. It's easy to perform tasks using GUI.

Command line interface allows a user to interact with the computer using commands. A user types the command in a terminal and the system helps in executing these commands. A new user with experience on GUI may find it difficult to interact with CLI as he/she needs to be aware of the commands to perform a particular operation.

"},{"location":"level101/linux_basics/intro/#shell-vs-terminal","title":"Shell vs Terminal","text":"

Shell is a program that takes commands from the users and gives them to the operating system for processing. Shell is an example of a CLI (command line interface). Bash is one of the most popular shell programs available on Linux servers. Other popular shell programs are zsh, ksh and tcsh.

Terminal is a program that opens a window and lets you interact with the shell. Some popular examples of terminals are GNOME-terminal, xterm, Konsole, etc.

Linux users do use the terms shell, terminal, prompt, console, etc. interchangeably. In simple terms, these all refer to a way of taking commands from the user.

"},{"location":"level101/linux_basics/linux_server_administration/","title":"Linux Server Administration","text":"

In this course, will try to cover some of the common tasks that a Linux server administrator performs. We will first try to understand what a particular command does and then try to understand the commands using examples. Do keep in mind that it's very important to practice the Linux commands on your own.

"},{"location":"level101/linux_basics/linux_server_administration/#lab-environment-setup","title":"Lab Environment Setup","text":"

"},{"location":"level101/linux_basics/linux_server_administration/#multi-user-operating-systems","title":"Multi-User Operating Systems","text":"

An operating system is considered as multi-user if it allows multiple people/users to use a computer and not affect each other's files and preferences. Linux-based operating systems are multi-user in nature as it allows multiple users to access the system at the same time. A typical computer will only have one keyboard and monitor but multiple users can log in via SSH if the computer is connected to the network. We will cover more about SSH later.

As a server administrator, we are mostly concerned with the Linux servers which are physically present at a very large distance from us. We can connect to these servers with the help of remote login methods like SSH.

Since Linux supports multiple users, we need to have a method which can protect the users from each other. One user should not be able to access and modify files of other users

"},{"location":"level101/linux_basics/linux_server_administration/#usergroup-management","title":"User/Group Management","text":""},{"location":"level101/linux_basics/linux_server_administration/#id-command","title":"id command","text":"

id command can be used to find the uid and gid associated with an user. It also lists down the groups to which the user belongs to.

The uid and gid associated with the root user is 0.

A good way to find out the current user in Linux is to use the whoami command.

root user or superuser is the most privileged user with unrestricted access to all the resources on the system. It has UID 0

"},{"location":"level101/linux_basics/linux_server_administration/#important-files-associated-with-usersgroups","title":"Important files associated with users/groups","text":"Files Description /etc/passwd Stores the user name, the uid, the gid, the home directory, the login shell etc /etc/shadow Stores the password associated with the users /etc/group Stores information about different groups on the system

If you want to understand each field discussed in the above outputs, you can go through below links:

"},{"location":"level101/linux_basics/linux_server_administration/#important-commands-for-managing-users","title":"Important commands for managing users","text":"

Some of the commands which are used frequently to manage users/groups on Linux are following:

"},{"location":"level101/linux_basics/linux_server_administration/#useradd","title":"useradd","text":"

The useradd command adds a new user in Linux.

We will create a new user shivam. We will also verify that the user has been created by tailing the /etc/passwd file. The uid and gid are 1000 for the newly created user. The home directory assigned to the user is /home/shivam and the login shell assigned is /bin/bash. Do note that the user home directory and login shell can be modified later on.

If we do not specify any value for attributes like home directory or login shell, default values will be assigned to the user. We can also override these default values when creating a new user.

"},{"location":"level101/linux_basics/linux_server_administration/#passwd","title":"passwd","text":"

The passwd command is used to create or modify passwords for a user.

In the above examples, we have not assigned any password for users shivam or amit while creating them.

!! in an account entry in shadow means the account of an user has been created, but not yet given a password.

Let's now try to create a password for user shivam.

Do remember the password as we will be later using examples where it will be useful.

Also, let's change the password for the root user now. When we switch from a normal user to root user, it will request you for a password. Also, when you login using root user, the password will be asked.

"},{"location":"level101/linux_basics/linux_server_administration/#usermod","title":"usermod","text":"

The usermod command is used to modify the attributes of an user like the home directory or the shell.

Let's try to modify the login shell of user amit to /bin/bash.

In a similar way, you can also modify many other attributes for a user. Try usermod -h for a list of attributes you can modify.

"},{"location":"level101/linux_basics/linux_server_administration/#userdel","title":"userdel","text":"

The userdel command is used to remove a user on Linux. Once we remove a user, all the information related to that user will be removed.

Let's try to delete the user amit. After deleting the user, you will not find the entry for that user in /etc/passwd or /etc/shadow file.

"},{"location":"level101/linux_basics/linux_server_administration/#important-commands-for-managing-groups","title":"Important commands for managing groups","text":"

Commands for managing groups are quite similar to the commands used for managing users. Each command is not explained in detail here as they are quite similar. You can try running these commands on your system.

Command Description groupadd <group_name> Creates a new group groupmod <group_name> Modifies attributes of a group groupdel <group_name> Deletes a group gpasswd <group_name> Modifies password for group

We will now try to add user shivam to the group we have created above.

"},{"location":"level101/linux_basics/linux_server_administration/#becoming-a-superuser","title":"Becoming a Superuser","text":"

Before running the below commands, do make sure that you have set up a password for user shivam and user root using the passwd command described in the above section.

The su command can be used to switch users in Linux. Let's now try to switch to user shivam.

Let's now try to open the /etc/shadow file.

The operating system didn't allow the user shivam to read the content of the /etc/shadow file. This is an important file in Linux which stores the passwords of users. This file can only be accessed by root or users who have the superuser privileges.

The sudo command allows a user to run commands with the security privileges of the root user. Do remember that the root user has all the privileges on a system. We can also use su command to switch to the root user and open the above file but doing that will require the password of the root user. An alternative way which is preferred on most modern operating systems is to use sudo command for becoming a superuser. Using this way, a user has to enter his/her password and they need to be a part of the sudo group.

How to provide superpriveleges to other users ?

Let's first switch to the root user using su command. Do note that using the below command will need you to enter the password for the root user.

In case, you forgot to set a password for the root user, type exit and you will be back as the root user. Now, set up a password using the passwd command.

The file /etc/sudoers holds the names of users permitted to invoke sudo. In Red Hat operating systems, this file is not present by default. We will need to install sudo.

We will discuss the yum command in detail in later sections.

Try to open the /etc/sudoers file on the system. The file has a lot of information. This file stores the rules that users must follow when running the sudo command. For example, root is allowed to run any commands from anywhere.

One easy way of providing root access to users is to add them to a group which has permissions to run all the commands. wheel is a group in Red Hat Linux with such privileges.

Let's add the user shivam to this group so that it also has sudo privileges.

Let's now switch back to user shivam and try to access the /etc/shadow file.

We need to use sudo before running the command since it can only be accessed with the sudo privileges. We have already given sudo privileges to user shivam by adding him to the group wheel.

"},{"location":"level101/linux_basics/linux_server_administration/#file-permissions","title":"File Permissions","text":"

On a Linux operating system, each file and directory is assigned access permissions for the owner of the file, the members of a group of related users and everybody else. This is to make sure that one user is not allowed to access the files and resources of another user.

To see the permissions of a file, we can use the ls command. Let's look at the permissions of /etc/passwd file.

Let's go over some of the important fields in the output that are related to file permissions.

"},{"location":"level101/linux_basics/linux_server_administration/#chmod-command","title":"Chmod command","text":"

The chmod command is used to modify files and directories permissions in Linux.

The chmod command accepts permissions in as a numerical argument. We can think of permission as a series of bits with 1 representing True or allowed and 0 representing False or not allowed.

Permission rwx Binary Decimal Read, write and execute rwx 111 7 Read and write rw- 110 6 Read and execute r-x 101 5 Read only r-- 100 4 Write and execute -wx 011 3 Write only -w- 010 2 Execute only --x 001 1 None --- 000 0

We will now create a new file and check the permission of the file.

The group owner doesn't have the permission to write to this file. Let's give the group owner or root the permission to write to it using chmod command.

chmod command can be also used to change the permissions of a directory in the similar way.

"},{"location":"level101/linux_basics/linux_server_administration/#chown-command","title":"Chown command","text":"

The chown command is used to change the owner of files or directories in Linux.

Command syntax: chown \\<new_owner\\> \\<file_name\\>

In case, we do not have sudo privileges, we need to use sudo command. Let's switch to user shivam and try changing the owner. We have also changed the owner of the file to root before running the below command.

Chown command can also be used to change the owner of a directory in the similar way.

"},{"location":"level101/linux_basics/linux_server_administration/#chgrp-command","title":"Chgrp command","text":"

The chgrp command can be used to change the group ownership of files or directories in Linux. The syntax is very similar to that of chown command.

chgrp command can also be used to change the owner of a directory in the similar way.

"},{"location":"level101/linux_basics/linux_server_administration/#ssh-command","title":"SSH Command","text":"

The ssh command is used for logging into the remote systems, transfer files between systems and for executing commands on a remote machine. SSH stands for secure shell and is used to provide an encrypted secured connection between two hosts over an insecure network like the internet.

Reference: https://www.ssh.com/ssh/command/

We will now discuss passwordless authentication which is secure and most commonly used for ssh authentication.

"},{"location":"level101/linux_basics/linux_server_administration/#passwordless-authentication-using-ssh","title":"Passwordless Authentication Using SSH","text":"

Using this method, we can ssh into hosts without entering the password. This method is also useful when we want some scripts to perform ssh-related tasks.

Passwordless authentication requires the use of a public and private key pair. As the name implies, the public key can be shared with anyone but the private key should be kept private. Let's not get into the details of how this authentication works. You can read more about it here

Steps for setting up a passwordless authentication with a remote host:

  1. Generating public-private key pair

    If we already have a key pair stored in ~/.ssh directory, we will not need to generate keys again.

    Install openssh package which contains all the commands related to ssh.

    Generate a key pair using the ssh-keygen command. One can choose the default values for all prompts.

    After running the ssh-keygen command successfully, we should see two keys present in the ~/.ssh directory. id_rsa is the private key and id_rsa.pub is the public key. Do note that the private key can only be read and modified by you.

  2. Transferring the public key to the remote host

    There are multiple ways to transfer the public key to the remote server. We will look at one of the most common ways of doing it using the ssh-copy-id command.

    Install the openssh-clients package to use ssh-copy-id command.

    Use the ssh-copy-id command to copy your public key to the remote host.

    Now, ssh into the remote host using the password authentication.

    Our public key should be there in ~/.ssh/authorized_keys now.

    ~/.ssh/authorized_key contains a list of public keys. The users associated with these public keys have the ssh access into the remote host.

"},{"location":"level101/linux_basics/linux_server_administration/#how-to-run-commands-on-a-remote-host","title":"How to run commands on a remote host ?","text":"

General syntax:

ssh \\<user\\>@\\<hostname/hostip\\> \\<command\\>\n

"},{"location":"level101/linux_basics/linux_server_administration/#how-to-transfer-files-from-one-host-to-another-host","title":"How to transfer files from one host to another host ?","text":"

General syntax:

scp \\<source\\> \\<destination\\>\n

"},{"location":"level101/linux_basics/linux_server_administration/#package-management","title":"Package Management","text":"

Package management is the process of installing and managing software on the system. We can install the packages which we require from the Linux package distributor. Different distributors use different packaging systems.

Packaging systems Distributions Debian style (.deb) Debian, Ubuntu Red Hat style (.rpm) Fedora, CentOS, Red Hat Enterprise Linux

Popular Packaging Systems in Linux

Command Description yum install <package_name> Installs a package on your system yum update <package_name> Updates a package to its latest available version yum remove <package_name> Removes a package from your system yum search <keyword> Searches for a particular keyword

DNF is the successor to YUM which is now used in Fedora for installing and managing packages. DNF may replace YUM in the future on all RPM-based Linux distributions.

We did find an exact match for the keyword httpd when we searched using yum search command. Let's now install the httpd package.

After httpd is installed, we will use the yum remove command to remove httpd package.

"},{"location":"level101/linux_basics/linux_server_administration/#process-management","title":"Process Management","text":"

In this section, we will study about some useful commands that can be used to monitor the processes on Linux systems.

"},{"location":"level101/linux_basics/linux_server_administration/#ps-process-status","title":"ps (process status)","text":"

The ps command is used to know the information of a process or list of processes.

If you get an error \"ps command not found\" while running ps command, do install procps package.

ps without any arguments is not very useful. Let's try to list all the processes on the system by using the below command.

Reference: https://unix.stackexchange.com/questions/106847/what-does-aux-mean-in-ps-aux

We can use an additional argument with ps command to list the information about the process with a specific process ID (PID).

We can use grep in combination with ps command to list only specific processes.

"},{"location":"level101/linux_basics/linux_server_administration/#top","title":"top","text":"

The top command is used to show information about Linux processes running on the system in real time. It also shows a summary of the system information.

For each process, top lists down the process ID, owner, priority, state, CPU utilization, memory utilization and much more information. It also lists down the memory utilization and CPU utilization of the system as a whole along with system uptime and CPU load average.

"},{"location":"level101/linux_basics/linux_server_administration/#memory-management","title":"Memory Management","text":"

In this section, we will study about some useful commands that can be used to view information about the system memory.

"},{"location":"level101/linux_basics/linux_server_administration/#free","title":"free","text":"

The free command is used to display the memory usage of the system. The command displays the total free and used space available in the RAM along with space occupied by the caches/buffers.

free command by default shows the memory usage in kilobytes. We can use an additional argument to get the data in human-readable format.

"},{"location":"level101/linux_basics/linux_server_administration/#vmstat","title":"vmstat","text":"

The vmstat command can be used to display the memory usage along with additional information about IO and CPU usage.

"},{"location":"level101/linux_basics/linux_server_administration/#checking-disk-space","title":"Checking Disk Space","text":"

In this section, we will study about some useful commands that can be used to view disk space on Linux.

"},{"location":"level101/linux_basics/linux_server_administration/#df-disk-free","title":"df (disk free)","text":"

The df command is used to display the free and available space for each mounted file system.

"},{"location":"level101/linux_basics/linux_server_administration/#du-disk-usage","title":"du (disk usage)","text":"

The du command is used to display disk usage of files and directories on the system.

The below command can be used to display the top 5 largest directories in the root directory.

"},{"location":"level101/linux_basics/linux_server_administration/#daemons","title":"Daemons","text":"

A computer program that runs as a background process is called a daemon. Traditionally, the name of daemon processes ends with d - sshd, httpd, etc. We cannot interact with a daemon process as they run in the background.

Services and daemons are used interchangeably most of the time.

"},{"location":"level101/linux_basics/linux_server_administration/#systemd","title":"Systemd","text":"

systemd is a system and service manager for Linux operating systems. systemd units are the building blocks of systemd. These units are represented by unit configuration files.

The below examples shows the unit configuration files available at /usr/lib/systemd/system which are distributed by installed RPM packages. We are more interested in the configuration file that ends with service as these are service units.

"},{"location":"level101/linux_basics/linux_server_administration/#managing-system-services","title":"Managing System Services","text":"

Service units end with .service file extension. systemctl command can be used to start/stop/restart the services managed by systemd.

Command Description systemctl start name.service Starts a service systemctl stop name.service Stops a service systemctl restart name.service Restarts a service systemctl status name.service Check the status of a service systemctl reload name.service Reload the configuration of a service"},{"location":"level101/linux_basics/linux_server_administration/#logs","title":"Logs","text":"

In this section, we will talk about some important files and directories which can be very useful for viewing system logs and applications logs in Linux. These logs can be very useful when you are troubleshooting on the system.

"},{"location":"level101/linux_networking/conclusion/","title":"Conclusion","text":"

With this, we have traversed through the TCP/IP stack completely. We hope there will be a different perspective when one opens any website in the browser post the course.

During the course we have also dissected what are common tasks in this pipeline which falls under the ambit of SRE.

"},{"location":"level101/linux_networking/conclusion/#post-training-exercises","title":"Post Training Exercises","text":"
  1. Set up your own DNS resolver in the dev environment which acts as an authoritative DNS server for example.com and forwarder for other domains. Update resolv.conf to use the new DNS resolver running in localhost.
  2. Set up a site dummy.example.com in localhost and run a webserver with a self-signed certificate. Update the trusted CAs or pass self-signed CA\u2019s public key as a parameter so that curl https://dummy.example.com -v works properly without self-signed cert warning.
  3. Update the routing table to use another host (container/VM) in the same network as a gateway for 8.8.8.8/32 and run ping 8.8.8.8. Do the packet capture on the new gateway to see L3 hop is working as expected (might need to disable icmp_redirect).
"},{"location":"level101/linux_networking/dns/","title":"DNS","text":"

Domain Names are the simple human-readable names for websites. The Internet understands only IP addresses, but since memorizing incoherent numbers is not practical, domain names are used instead. These domain names are translated into IP addresses by the DNS infrastructure. When somebody tries to open www.linkedin.com in the browser, the browser tries to convert www.linkedin.com to an IP Address. This process is called DNS resolution. A simple pseudocode depicting this process looks this:

ip, err = getIPAddress(domainName)\nif err:\n  print(\"unknown Host Exception while trying to resolve:%s\".format(domainName))\n

Now, let\u2019s try to understand what happens inside the getIPAddress function. The browser would have a DNS cache of its own where it checks if there is a mapping for the domainName to an IP Address already available, in which case the browser uses that IP address. If no such mapping exists, the browser calls gethostbyname syscall to ask the operating system to find the IP address for the given domainName.

def getIPAddress(domainName):\n    resp, fail = lookupCache(domainName)\n    If not fail:\n       return resp\n    else:\n       resp, err = gethostbyname(domainName)\n       if err:\n         return null, err\n       else:\n          return resp\n

Now, let's understand what operating system kernel does when the gethostbyname function is called. The Linux operating system looks at the file /etc/nsswitch.conf file which usually has a line.

hosts:      files dns\n

This line means the OS has to look up first in file (/etc/hosts) and then use DNS protocol to do the resolution if there is no match in /etc/hosts.

The file /etc/hosts is of format:

IPAddress FQDN [FQDN].*

127.0.0.1 localhost.localdomain localhost\n::1 localhost.localdomain localhost\n

If a match exists for a domain in this file, then that IP address is returned by the OS. Let's add a line to this file:

127.0.0.1 test.linkedin.com\n

And then do ping test.linkedin.com.

ping test.linkedin.com -n\n
PING test.linkedin.com (127.0.0.1) 56(84) bytes of data.\n64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.047 ms\n64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.036 ms\n64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.037 ms\n\n

As mentioned earlier, if no match exists in /etc/hosts, the OS tries to do a DNS resolution using the DNS protocol. The Linux system makes a DNS request to the first IP in /etc/resolv.conf. If there is no response, requests are sent to subsequent servers in resolv.conf. These servers in resolv.conf are called DNS resolvers. The DNS resolvers are populated by DHCP or statically configured by an administrator. Dig is a userspace DNS system which creates and sends request to DNS resolvers and prints the response it receives to the console.

# run this command in one shell to capture all DNS requests\nsudo tcpdump -s 0 -A -i any port 53\n# make a dig request from another shell\ndig linkedin.com\n
13:19:54.432507 IP 172.19.209.122.56497 > 172.23.195.101.53: 527+ [1au] A? linkedin.com. (41)\n....E..E....@.n....z...e...5.1.:... .........linkedin.com.......)........\n13:19:54.485131 IP 172.23.195.101.53 > 172.19.209.122.56497: 527 1/0/1 A 108.174.10.10 (57)\n....E..U..@.|.  ....e...z.5...A...............linkedin.com..............3..l.\n\n..)........\n

The packet capture shows a request is made to 172.23.195.101:53 (this is the resolver in /etc/resolv.conf) for linkedin.com and a response is received from 172.23.195.101 with the IP address of linkedin.com 108.174.10.10.

Now, let's try to understand how DNS resolver tries to find the IP address of linkedin.com. DNS resolver first looks at its cache. Since many devices in the network can query for the domain name linkedin.com, the name resolution result may already exist in the cache. If there is a cache miss, it starts the DNS resolution process. The DNS server breaks \u201clinkedin.com\u201d to \u201c.\u201d, \u201ccom.\u201d and \u201clinkedin.com.\u201d and starts DNS resolution from \u201c.\u201d. The \u201c.\u201d is called root domain and those IPs are known to the DNS resolver software. DNS resolver queries the root domain nameservers to find the right top-level domain (TLD) nameservers which could respond regarding details for \"com.\". The address of the TLD nameserver of \u201ccom.\u201d is returned. Now the DNS resolution service contacts the TLD nameserver for \u201ccom.\u201d to fetch the authoritative nameserver for \u201clinkedin.com\u201d. Once an authoritative nameserver of \u201clinkedin.com\u201d is known, the resolver contacts LinkedIn\u2019s nameserver to provide the IP address of \u201clinkedin.com\u201d. This whole process can be visualized by running the following:

dig +trace linkedin.com\n
linkedin.com.       3600    IN  A   108.174.10.10\n

This DNS response has 5 fields where the first field is the request and the last field is the response. The second field is the Time-to-Live (TTL) which says how long the DNS response is valid in seconds. In this case, this mapping of linkedin.com is valid for 1 hour. This is how the resolvers and application (browser) maintain their cache. Any request for linkedin.com beyond 1 hour will be treated as a cache miss as the mapping has expired its TTL and the whole process has to be redone. The 4th field says the type of DNS response/request. Some of the various DNS query types are A, AAAA, NS, TXT, PTR, MX and CNAME.

dig A linkedin.com +short\n108.174.10.10\n\n\ndig AAAA linkedin.com +short\n2620:109:c002::6cae:a0a\n\n\ndig NS linkedin.com +short\ndns3.p09.nsone.net.\ndns4.p09.nsone.net.\ndns2.p09.nsone.net.\nns4.p43.dynect.net.\nns1.p43.dynect.net.\nns2.p43.dynect.net.\nns3.p43.dynect.net.\ndns1.p09.nsone.net.\n\ndig www.linkedin.com CNAME +short\n2-01-2c3e-005a.cdx.cedexis.net.\n

Armed with these fundamentals of DNS lets see use cases where DNS is used by SREs.

"},{"location":"level101/linux_networking/dns/#applications-in-sre-role","title":"Applications in SRE role","text":"

This section covers some of the common solutions SRE can derive from DNS.

  1. Every company has to have its internal DNS infrastructure for intranet sites and internal services like databases and other internal applications like Wiki. So there has to be a DNS infrastructure maintained for those domain names by the infrastructure team. This DNS infrastructure has to be optimized and scaled so that it doesn\u2019t become a single point of failure. Failure of the internal DNS infrastructure can cause API calls of microservices to fail and other cascading effects.
  2. DNS can also be used for discovering services. For example the hostname serviceb.internal.example.com could list instances which run service b internally in example.com company. Cloud providers provide options to enable DNS discovery (example).
  3. DNS is used by cloud providers and CDN providers to scale their services. In Azure/AWS, Load Balancers are given a CNAME instead of IPAddress. They update the IPAddress of the Loadbalancers as they scale by changing the IP Address of alias domain names. This is one of the reasons why A records of such alias domains are short-lived like 1 minute.
  4. DNS can also be used to make clients get IP addresses closer to their location so that their HTTP calls can be responded faster if the company has a presence geographically distributed.
  5. SRE also has to understand since there is no verification in DNS infrastructure, these responses can be spoofed. This is safeguarded by other protocols like HTTPS (dealt later). DNSSEC protects from forged or manipulated DNS responses.
  6. Stale DNS cache can be a problem. Some apps might still be using expired DNS records for their API calls. This is something SRE has to be wary of when doing maintenance.
  7. DNS Loadbalancing and service discovery also has to understand TTL and the servers can be removed from the pool only after waiting till TTL post the changes are made to DNS records. If this is not done, a certain portion of the traffic will fail as the server is removed before the TTL.
"},{"location":"level101/linux_networking/http/","title":"HTTP","text":"

Till this point we have only got the IP address of linkedin.com. The HTML page of linkedin.com is served by HTTP protocol which the browser renders. Browser sends a HTTP request to the IP of the server determined above. Request has a verb GET, PUT, POST followed by a path and query parameters and lines of key-value pair which gives information about the client and capabilities of the client like contents it can accept and a body (usually in POST or PUT).

# Eg. run the following in your container and have a look at the headers \ncurl linkedin.com -v\n
* Connected to linkedin.com (108.174.10.10) port 80 (#0)\n> GET / HTTP/1.1\n> Host: linkedin.com\n> User-Agent: curl/7.64.1\n> Accept: */*\n> \n< HTTP/1.1 301 Moved Permanently\n< Date: Mon, 09 Nov 2020 10:39:43 GMT\n< X-Li-Pop: prod-esv5\n< X-LI-Proto: http/1.1\n< Location: https://www.linkedin.com/\n< Content-Length: 0\n< \n* Connection #0 to host linkedin.com left intact\n* Closing connection 0\n

Here, in the first line GET is the verb, / is the path and 1.1 is the HTTP protocol version. Then there are key-value pairs which give client capabilities and some details to the server. The server responds back with HTTP version, Status Code and Status message. Status codes 2xx means success, 3xx denotes redirection, 4xx denotes client-side errors and 5xx server-side errors.

We will now jump in to see the difference between HTTP/1.0 and HTTP/1.1.

#On the terminal type\ntelnet  www.linkedin.com 80\n#Copy and paste the following with an empty new line at last in the telnet STDIN\nGET / HTTP/1.1\nHOST:linkedin.com\nUSER-AGENT: curl\n\n

This would get server response and waits for next input as the underlying connection to www.linkedin.com can be reused for further queries. While going through TCP, we can understand the benefits of this. But in HTTP/1.0, this connection will be immediately closed after the response meaning new connection has to be opened for each query. HTTP/1.1 can have only one inflight request in an open connection but connection can be reused for multiple requests one after another. One of the benefits of HTTP/2.0 over HTTP/1.1 is we can have multiple inflight requests on the same connection. We are restricting our scope to generic HTTP and not jumping to the intricacies of each protocol version but they should be straight forward to understand post the course.

HTTP is called stateless protocol. This section we will try to understand what stateless means. Say we logged in to linkedin.com, each request to linkedin.com from the client will have no context of the user and it makes no sense to prompt user to login for each page/resource. This problem of HTTP is solved by COOKIE. A user is created a session when a user logs in. This session identifier is sent to the browser via SET-COOKIE header. The browser stores the COOKIE till the expiry set by the server and sends the cookie for each request from hereon for linkedin.com. More details on cookies are available here. Cookies are a critical piece of information like password and since HTTP is a plain text protocol, any man-in-the-middle can capture either password or cookies and can breach the privacy of the user. Similarly as discussed during DNS, a spoofed IP of linkedin.com can cause a phishing attack on users where an user can give LinkedIn\u2019s password to login on the malicious site. To solve both problems, HTTPS came in place and HTTPS has to be mandated.

HTTPS has to provide server identification and encryption of data between client and server. The server administrator has to generate a private-public key pair and certificate request. This certificate request has to be signed by a certificate authority which converts the certificate request to a certificate. The server administrator has to update the certificate and private key to the webserver. The certificate has details about the server (like domain name for which it serves, expiry date), public key of the server. The private key is a secret to the server and losing the private key loses the trust the server provides. When clients connect, the client sends a HELLO. The server sends its certificate to the client. The client checks the validity of the cert by seeing if it is within its expiry time, if it is signed by a trusted authority and the hostname in the cert is the same as the server. This validation makes sure the server is the right server and there is no phishing. Once that is validated, the client negotiates a symmetrical key and cipher with the server by encrypting the negotiation with the public key of the server. Nobody else other than the server who has the private key can understand this data. Once negotiation is complete, that symmetric key and algorithm is used for further encryption which can be decrypted only by client and server from thereon as they only know the symmetric key and algorithm. The switch to symmetric algorithm from asymmetric encryption algorithm is to not strain the resources of client devices as symmetric encryption is generally less resource intensive than asymmetric.

# Try the following on your terminal to see the cert details like Subject Name (domain name), Issuer details, Expiry date\ncurl https://www.linkedin.com -v \n
* Connected to www.linkedin.com (13.107.42.14) port 443 (#0)\n* ALPN, offering h2\n* ALPN, offering http/1.1\n* successfully set certificate verify locations:\n*   CAfile: /etc/ssl/cert.pem\n  CApath: none\n* TLSv1.2 (OUT), TLS handshake, Client hello (1):\n} [230 bytes data]\n* TLSv1.2 (IN), TLS handshake, Server hello (2):\n{ [90 bytes data]\n* TLSv1.2 (IN), TLS handshake, Certificate (11):\n{ [3171 bytes data]\n* TLSv1.2 (IN), TLS handshake, Server key exchange (12):\n{ [365 bytes data]\n* TLSv1.2 (IN), TLS handshake, Server finished (14):\n{ [4 bytes data]\n* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):\n} [102 bytes data]\n* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):\n} [1 bytes data]\n* TLSv1.2 (OUT), TLS handshake, Finished (20):\n} [16 bytes data]\n* TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):\n{ [1 bytes data]\n* TLSv1.2 (IN), TLS handshake, Finished (20):\n{ [16 bytes data]\n* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384\n* ALPN, server accepted to use h2\n* Server certificate:\n*  subject: C=US; ST=California; L=Sunnyvale; O=LinkedIn Corporation; CN=www.linkedin.com\n*  start date: Oct  2 00:00:00 2020 GMT\n*  expire date: Apr  2 12:00:00 2021 GMT\n*  subjectAltName: host \"www.linkedin.com\" matched cert's \"www.linkedin.com\"\n*  issuer: C=US; O=DigiCert Inc; CN=DigiCert SHA2 Secure Server CA\n*  SSL certificate verify ok.\n* Using HTTP2, server supports multi-use\n* Connection state changed (HTTP/2 confirmed)\n* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0\n* Using Stream ID: 1 (easy handle 0x7fb055808200)\n* Connection state changed (MAX_CONCURRENT_STREAMS == 100)!\n  0 82117    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0\n* Connection #0 to host www.linkedin.com left intact\nHTTP/2 200 \ncache-control: no-cache, no-store\npragma: no-cache\ncontent-length: 82117\ncontent-type: text/html; charset=utf-8\nexpires: Thu, 01 Jan 1970 00:00:00 GMT\nset-cookie: JSESSIONID=ajax:2747059799136291014; SameSite=None; Path=/; Domain=.www.linkedin.com; Secure\nset-cookie: lang=v=2&lang=en-us; SameSite=None; Path=/; Domain=linkedin.com; Secure\nset-cookie: bcookie=\"v=2&70bd59e3-5a51-406c-8e0d-dd70befa8890\"; domain=.linkedin.com; Path=/; Secure; Expires=Wed, 09-Nov-2022 22:27:42 GMT; SameSite=None\nset-cookie: bscookie=\"v=1&202011091050107ae9b7ac-fe97-40fc-830d-d7a9ccf80659AQGib5iXwarbY8CCBP94Q39THkgUlx6J\"; domain=.www.linkedin.com; Path=/; Secure; Expires=Wed, 09-Nov-2022 22:27:42 GMT; HttpOnly; SameSite=None\nset-cookie: lissc=1; domain=.linkedin.com; Path=/; Secure; Expires=Tue, 09-Nov-2021 10:50:10 GMT; SameSite=None\nset-cookie: lidc=\"b=VGST04:s=V:r=V:g=2201:u=1:i=1604919010:t=1605005410:v=1:sig=AQHe-KzU8i_5Iy6MwnFEsgRct3c9Lh5R\"; Expires=Tue, 10 Nov 2020 10:50:10 GMT; domain=.linkedin.com; Path=/; SameSite=None; Secure\nx-fs-txn-id: 2b8d5409ba70\nx-fs-uuid: 61bbf94956d14516302567fc882b0000\nexpect-ct: max-age=86400, report-uri=\"https://www.linkedin.com/platform-telemetry/ct\"\nx-xss-protection: 1; mode=block\ncontent-security-policy-report-only: default-src 'none'; connect-src 'self' www.linkedin.com www.google-analytics.com https://dpm.demdex.net/id lnkd.demdex.net blob: https://linkedin.sc.omtrdc.net/b/ss/ static.licdn.com static-exp1.licdn.com static-exp2.licdn.com static-exp3.licdn.com; script-src 'sha256-THuVhwbXPeTR0HszASqMOnIyxqEgvGyBwSPBKBF/iMc=' 'sha256-PyCXNcEkzRWqbiNr087fizmiBBrq9O6GGD8eV3P09Ik=' 'sha256-2SQ55Erm3CPCb+k03EpNxU9bdV3XL9TnVTriDs7INZ4=' 'sha256-S/KSPe186K/1B0JEjbIXcCdpB97krdzX05S+dHnQjUs=' platform.linkedin.com platform-akam.linkedin.com platform-ecst.linkedin.com platform-azur.linkedin.com static.licdn.com static-exp1.licdn.com static-exp2.licdn.com static-exp3.licdn.com; img-src data: blob: *; font-src data: *; style-src 'self' 'unsafe-inline' static.licdn.com static-exp1.licdn.com static-exp2.licdn.com static-exp3.licdn.com; media-src dms.licdn.com; child-src blob: *; frame-src 'self' lnkd.demdex.net linkedin.cdn.qualaroo.com; manifest-src 'self'; report-uri https://www.linkedin.com/platform-telemetry/csp?f=g\ncontent-security-policy: default-src *; connect-src 'self' https://media-src.linkedin.com/media/ www.linkedin.com s.c.lnkd.licdn.com m.c.lnkd.licdn.com s.c.exp1.licdn.com s.c.exp2.licdn.com m.c.exp1.licdn.com m.c.exp2.licdn.com wss://*.linkedin.com dms.licdn.com https://dpm.demdex.net/id lnkd.demdex.net blob: https://accounts.google.com/gsi/status https://linkedin.sc.omtrdc.net/b/ss/ www.google-analytics.com static.licdn.com static-exp1.licdn.com static-exp2.licdn.com static-exp3.licdn.com media.licdn.com media-exp1.licdn.com media-exp2.licdn.com media-exp3.licdn.com; img-src data: blob: *; font-src data: *; style-src 'unsafe-inline' 'self' static-src.linkedin.com *.licdn.com; script-src 'report-sample' 'unsafe-inline' 'unsafe-eval' 'self' spdy.linkedin.com static-src.linkedin.com *.ads.linkedin.com *.licdn.com static.chartbeat.com www.google-analytics.com ssl.google-analytics.com bcvipva02.rightnowtech.com www.bizographics.com sjs.bizographics.com js.bizographics.com d.la4-c1-was.salesforceliveagent.com slideshare.www.linkedin.com https://snap.licdn.com/li.lms-analytics/ platform.linkedin.com platform-akam.linkedin.com platform-ecst.linkedin.com platform-azur.linkedin.com; object-src 'none'; media-src blob: *; child-src blob: lnkd-communities: voyager: *; frame-ancestors 'self'; report-uri https://www.linkedin.com/platform-telemetry/csp?f=l\nx-frame-options: sameorigin\nx-content-type-options: nosniff\nstrict-transport-security: max-age=2592000\nx-li-fabric: prod-lva1\nx-li-pop: afd-prod-lva1\nx-li-proto: http/2\nx-li-uuid: Ybv5SVbRRRYwJWf8iCsAAA==\nx-msedge-ref: Ref A: CFB9AC1D2B0645DDB161CEE4A4909AEF Ref B: BOM02EDGE0712 Ref C: 2020-11-09T10:50:10Z\ndate: Mon, 09 Nov 2020 10:50:10 GMT\n\n* Closing connection 0\n

Here, my system has a list of certificate authorities it trusts in this file /etc/ssl/cert.pem. cURL validates the certificate is for www.linkedin.com by seeing the CN section of the subject part of the certificate. It also makes sure the certificate is not expired by seeing the expire date. It also validates the signature on the certificate by using the public key of issuer Digicert in /etc/ssl/cert.pem. Once this is done, using the public key of www.linkedin.com it negotiates cipher TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 with a symmetric key. Subsequent data transfer including first HTTP request uses the same cipher and symmetric key.

"},{"location":"level101/linux_networking/intro/","title":"Linux Networking Fundamentals","text":""},{"location":"level101/linux_networking/intro/#prerequisites","title":"Prerequisites","text":""},{"location":"level101/linux_networking/intro/#what-to-expect-from-this-course","title":"What to expect from this course","text":"

Throughout the course, we cover how an SRE can optimize the system to improve their web stack performance and troubleshoot if there is an issue in any of the layers of the networking stack. This course tries to dig through each layer of traditional TCP/IP stack and expects an SRE to have a picture beyond the bird\u2019s eye view of the functioning of the Internet.

"},{"location":"level101/linux_networking/intro/#what-is-not-covered-under-this-course","title":"What is not covered under this course","text":"

This course spends time on the fundamentals. We are not covering concepts like HTTP/2.0, QUIC, TCP congestion control protocols, Anycast, BGP, CDN, Tunnels and Multicast. We expect that this course will provide the relevant basics to understand such concepts.

"},{"location":"level101/linux_networking/intro/#birds-eye-view-of-the-course","title":"Birds eye view of the course","text":"

The course covers the question \u201cWhat happens when you open linkedin.com in your browser?\u201d The course follows the flow of TCP/IP stack. More specifically, the course covers topics of Application layer protocols (DNS and HTTP), transport layer protocols (UDP and TCP), networking layer protocol (IP) and data link layer protocol.

"},{"location":"level101/linux_networking/intro/#course-contents","title":"Course Contents","text":"
  1. DNS
  2. UDP
  3. HTTP
  4. TCP
  5. IP Routing
"},{"location":"level101/linux_networking/ipr/","title":"IP Routing and Data Link Layer","text":"

We will dig how packets that leave the client reach the server and vice versa. When the packet reaches the IP layer, the transport layer populates source port, destination port. IP/Network layer populates destination IP (discovered from DNS) and then looks up the route to the destination IP on the routing table.

# Linux `route -n` command gives the default routing table\nroute -n\n
Kernel IP routing table\nDestination     Gateway         Genmask         Flags Metric Ref    Use Iface\n0.0.0.0         172.17.0.1      0.0.0.0         UG    0      0        0 eth0\n172.17.0.0      0.0.0.0         255.255.0.0     U     0      0        0 eth0\n

Here, the destination IP is bitwise AND\u2019d with the Genmask and if the answer is the destination part of the table, then that gateway and interface is picked for routing. Here, linkedin.com\u2019s IP 108.174.10.10 is AND\u2019d with 255.255.255.0 and the answer we get is 108.174.10.0 which doesn\u2019t match with any destination in the routing table. Then, Linux does an AND of destination IP with 0.0.0.0 and we get 0.0.0.0. This answer matches the default row.

Routing table is processed in the order of more octets of 1 set in Genmask and Genmask 0.0.0.0 is the default route if nothing matches. At the end of this operation, Linux figured out that the packet has to be sent to next hop 172.17.0.1 via eth0. The source IP of the packet will be set as the IP of interface eth0. Now, to send the packet to 172.17.0.1, Linux has to figure out the MAC address of 172.17.0.1. MAC address is figured by looking at the internal ARP cache which stores translation between IP address and MAC address. If there is a cache miss, Linux broadcasts ARP request within the internal network asking who has 172.17.0.1. The owner of the IP sends an ARP response which is cached by the kernel and the kernel sends the packet to the gateway by setting Source MAC address as MAC address of eth0 and destination MAC address of 172.17.0.1 which we got just now. Similar routing lookup process is followed in each hop till the packet reaches the actual server. Transport layer and layers above it come to play only at end servers. During intermediate hops, only till the IP/Network layer is involved.

One weird gateway we saw in the routing table is 0.0.0.0. This gateway means no Layer3 (Network layer) hop is needed to send the packet. Both source and destination are in the same network. Kernel has to figure out the MAC of the destination and populate source and destination MAC appropriately and send the packet out so that it reaches the destination without any Layer3 hop in the middle.

As we followed in other modules, let's complete this session with SRE use cases.

"},{"location":"level101/linux_networking/ipr/#applications-in-sre-role","title":"Applications in SRE role","text":"
  1. Generally the routing table is populated by DHCP and playing around is not a good practice. There can be reasons where one has to play around the routing table but take that path only when it's absolutely necessary.
  2. Understanding error messages better like, \u201cNo route to host\u201d error can mean MAC address of the destination host is not found and it can mean the destination host is down.
  3. On rare cases, looking at the ARP table can help us understand if there is a IP conflict where same IP is assigned to two hosts by mistake and this is causing unexpected behavior.
"},{"location":"level101/linux_networking/tcp/","title":"TCP","text":"

TCP is a transport layer protocol like UDP but it guarantees reliability, flow control and congestion control. TCP guarantees reliable delivery by using sequence numbers. A TCP connection is established by a three-way handshake. In our case, the client sends a SYN packet along with the starting sequence number it plans to use, the server acknowledges the SYN packet and sends a SYN with its sequence number. Once the client acknowledges the SYN packet, the connection is established. Each data transferred from here on is considered delivered reliably once acknowledgement for that sequence is received by the concerned party.

# To understand handshake run packet capture on one bash session\ntcpdump -S -i any port 80\n# Run curl on one bash session\ncurl www.linkedin.com\n

Here, client sends a SYN flag shown by [S] flag with a sequence number 1522264672. The server acknowledges receipt of SYN with an ACK [.] flag and a SYN flag for its sequence number [S]. The server uses the sequence number 1063230400 and acknowledges the client it's expecting sequence number 1522264673 (client sequence + 1). Client sends a zero length acknowledgement packet to the server (server sequence + 1) and connection stands established. This is called three way handshake. The client sends a 76 bytes length packet after this and increments its sequence number by 76. Server sends a 170 byte response and closes the connection. This was the difference we were talking about between HTTP/1.1 and HTTP/1.0. In HTTP/1.1, this same connection can be reused which reduces overhead of three-way handshake for each HTTP request. If a packet is missed between client and server, server won\u2019t send an ACK to the client and client would retry sending the packet till the ACK is received. This guarantees reliability. The flow control is established by the WIN size field in each segment. The WIN size says available TCP buffer length in the kernel which can be used to buffer received segments. A size 0 means the receiver has a lot of lag to catch from its socket buffer and the sender has to pause sending packets so that receiver can cope up. This flow control protects from slow receiver and fast sender problem.

TCP also does congestion control which determines how many segments can be in transit without an ACK. Linux provides us the ability to configure algorithms for congestion control which we are not covering here.

While closing a connection, client/server calls a close syscall. Let's assume client do that. Client\u2019s kernel will send a FIN packet to the server. Server\u2019s kernel can\u2019t close the connection till the close syscall is called by the server application. Once server app calls close, server also sends a FIN packet and client enters into TIME_WAIT state for 2*MSS (120s) so that this socket can\u2019t be reused for that time period to prevent any TCP state corruptions due to stray stale packets.

Armed with our TCP and HTTP knowledge, let's see how this is used by SREs in their role.

"},{"location":"level101/linux_networking/tcp/#applications-in-sre-role","title":"Applications in SRE role","text":"
  1. Scaling HTTP performance using load balancers need consistent knowledge about both TCP and HTTP. There are different kinds of load balancing like L4, L7 load balancing, Direct Server Return etc. HTTPs offloading can be done on Load balancer or directly on servers based on the performance and compliance needs.
  2. Tweaking sysctl variables for rmem and wmem like we did for UDP can improve throughput of sender and receiver.
  3. sysctl variable tcp_max_syn_backlog and socket variable somax_conn determines how many connections for which the kernel can complete 3-way handshake before app calling accept syscall. This is much useful in single-threaded applications. Once the backlog is full, new connections stay in SYN_RCVD state (when you run netstat) till the application calls accept syscall.
  4. Apps can run out of file descriptors if there are too many short-lived connections. Digging through tcp_reuse and tcp_recycle can help reduce time spent in the TIME_WAIT state (it has its own risk). Making apps reuse a pool of connections instead of creating ad hoc connection can also help.
  5. Understanding performance bottlenecks by seeing metrics and classifying whether it's a problem in App or network side. Example too many sockets in CLOSE_WAIT state is a problem on application whereas retransmissions can be a problem more on network or on OS stack than the application itself. Understanding the fundamentals can help us narrow down where the bottleneck is.
"},{"location":"level101/linux_networking/udp/","title":"UDP","text":"

UDP is a transport layer protocol. DNS is an application layer protocol that runs on top of UDP (most of the times). Before jumping into UDP, let's try to understand what an application and transport layer is. DNS protocol is used by a DNS client (eg dig) and DNS server (eg named). The transport layer makes sure the DNS request reaches the DNS server process and similarly the response reaches the DNS client process. Multiple processes can run on a system and they can listen on any ports. DNS servers usually listen on port number 53. When a client makes a DNS request, after filling the necessary application payload, it passes the payload to the kernel via sendto system call. The kernel picks a random port number (>1024) as source port number and puts 53 as destination port number and sends the packet to lower layers. When the kernel on server-side receives the packet, it checks the port number and queues the packet to the application buffer of the DNS server process which makes a recvfrom system call and reads the packet. This process by the kernel is called multiplexing (combining packets from multiple applications to same lower layers) and demultiplexing (segregating packets from single lower layer to multiple applications). Multiplexing and Demultiplexing is done by the Transport layer.

UDP is one of the simplest transport layer protocol and it does only multiplexing and demultiplexing. Another common transport layer protocol TCP does a bunch of other things like reliable communication, flow control and congestion control. UDP is designed to be lightweight and handle communications with little overhead. So, it doesn\u2019t do anything beyond multiplexing and demultiplexing. If applications running on top of UDP need any of the features of TCP, they have to implement that in their application.

This example from python wiki covers a sample UDP client and server where \u201cHello World\u201d is an application payload sent to server listening on port number 5005. The server receives the packet and prints the \u201cHello World\u201d string from the client.

"},{"location":"level101/linux_networking/udp/#applications-in-sre-role","title":"Applications in SRE role","text":"
  1. If the underlying network is slow and the UDP layer is unable to queue packets down to the networking layer, sendto syscall from the application will hang till the kernel finds some of its buffer is freed. This can affect the throughput of the system. Increasing write memory buffer values using sysctl variables net.core.wmem_max and net.core.wmem_default provides some cushion to the application from the slow network
  2. Similarly, if the receiver process is slow in consuming from its buffer, the kernel has to drop packets which it can\u2019t queue due to the buffer being full. Since UDP doesn\u2019t guarantee reliability these dropped packets can cause data loss unless tracked by the application layer. Increasing sysctl variables rmem_default and rmem_max can provide some cushion to slow applications from fast senders.
"},{"location":"level101/messagequeue/further_reading/","title":"Conclusion","text":"

We have covered basic concepts of Message Services. There is much more to learn and do. We hope this course gives you a good start and inspires you to explore further.

"},{"location":"level101/messagequeue/further_reading/#further-reading","title":"Further reading","text":"

https://sudhir.io/the-big-little-guide-to-message-queues

Understanding message brokers: learn the mechanics of messaging though ActiveMQ and Kafka

Video: The Myth of the Magical Messaging Fabric by Jakub Korab

G. Fu, Y. Zhang and G. Yu, \"A Fair Comparison of Message Queuing Systems,\" in IEEE Access, vol. 9, pp. 421-432, 2021, doi: 10.1109/ACCESS.2020.3046503. (PDF)

Design Patterns for Cloud Native Applications: Chapter 2 Communication Patterns

Choose between Azure messaging services - Event Grid, Event Hubs, and Service Bus

Exactly-once message delivery

Task Queues

RabbitMQ tutorial

"},{"location":"level101/messagequeue/intro/","title":"Messaging services","text":""},{"location":"level101/messagequeue/intro/#what-to-expect-from-this-course","title":"What to expect from this course","text":"

At the end of training, you will have an understanding of what a Message Services is, learn about different types of Message Service implementation and understand some of the underlying concepts & trade-offs.

"},{"location":"level101/messagequeue/intro/#what-is-not-covered-under-this-course","title":"What is not covered under this course","text":"

We will not be deep diving into any specific Message Service.

"},{"location":"level101/messagequeue/intro/#course-contents","title":"Course Contents","text":""},{"location":"level101/messagequeue/intro/#introduction","title":"Introduction","text":"

In today's distributed systems and microservices architectures, messaging services play a crucial role in ensuring reliable communication and coordination between different components. These services enable the asynchronous exchange of messages, providing a wide range of benefits, such as increased performance, improved fault tolerance, and enhanced scalability.

This article will provide an overview of the various types of messaging services available, including general-purpose message queues, pub/sub messaging, stream processing, brokerless messaging, and database-as-queue systems. We will also explore key concepts like delivery guarantees, message ordering, parallelism, poison pills, and dead letters, which are essential to understanding how messaging services function and how they can be effectively utilized.

"},{"location":"level101/messagequeue/intro/#types-of-messaging-services","title":"Types of Messaging services:","text":"

In this section, we will explore various types of messaging services, each designed to address different requirements and use cases in distributed systems.

  1. General-purpose message queue: General-purpose message queues are versatile and can be used in various non-very-scenarios, from distributing tasks and buffering requests to enabling communication between microservices. These messaging systems are designed to provide reliable message delivery and ensure that messages are processed in the correct order, and handle message volumes typically up to 100,000 messages per second. Message queues often support multiple messaging patterns, such as point-to-point and publish-subscribe, providing flexibility for different use cases. Examples of general-purpose message queues include RabbitMQ, ActiveMQ, and Amazon SQS. By using these message queues, developers can decouple their applications and scale them independently, improving overall system resilience and performance.

  2. Pub/Sub messaging: Publish-Subscribe (Pub/Sub) messaging services allow publishers to send messages to multiple subscribers without direct point-to-point connections. This enables decoupling of producers and consumers, making the system more scalable and fault-tolerant. Pub/Sub systems are particularly useful in scenarios where multiple consumers need to receive and process the same messages, such as sending notifications, logging, or data replication. The Pub/Sub model supports dynamic subscription management, allowing consumers to subscribe and unsubscribe from specific topics or channels at runtime. Examples of Pub/Sub messaging services include Google Cloud Pub/Sub, Apache Pulsar, Azure Event Grid, AWS SNS and NATS. By adopting a Pub/Sub messaging system, developers can create event-driven architectures, reduce system complexity, and streamline the integration of new services.

  3. Streaming processing: Stream processing services are designed to handle large volumes of real-time data (say 1 milion messages per second), allowing continuous processing and analysis of data streams. These services enable complex event processing, time-windowed aggregations, and stateful transformations. They provide a robust platform for building real-time analytics, monitoring, and alerting applications. Stream processing systems often use a combination of in-memory and disk-based storage to balance performance and durability. They also support horizontal scaling, allowing developers to process massive data volumes with low latency. Examples of stream processing services include Apache Kafka, Amazon Kinesis Data Streams, Azure Event Hubs, RocketMQ, Apache Pulsar and Redis Streams. By leveraging stream processing services, organizations can gain valuable insights from their data in real-time and make data-driven decisions more effectively.

  4. Brokerless: Brokerless messaging systems enable direct communication between producers and consumers without relying on a central broker, thereby reducing latency and improving performance. In brokerless systems, nodes communicate with each other using a peer-to-peer architecture, which can simplify deployment and reduce the need for dedicated message broker infrastructure. These systems are particularly suitable for high-performance, low-latency applications or situations where network connectivity is intermittent or unreliable. Examples of brokerless messaging systems include ZeroMQ, nanomsg, Chronicle Queue and the Disruptor. By adopting a brokerless messaging system, developers can build lightweight, fast, and efficient communication channels between components in their distributed systems

  5. Database-as-queue In some cases, a traditional relational or NoSQL database can be used as a message queue, allowing for simpler integration with existing systems and providing familiar tools for data management. This approach can be particularly useful for smaller-scale applications or as a transitional step when migrating from monolithic to distributed architectures. Using a database-as-queue can leverage built-in database features like transactions, indexing, and querying to manage messages effectively. Examples of using a database-as-queue include PostgreSQL's LISTEN/NOTIFY feature or leveraging Amazon DynamoDB Streams. While using a database-as-queue might not provide the same performance and scalability as dedicated messaging services and sometimes is considered as an anti-pattern, it can be a suitable option for specific use cases or when the application requirements are less demanding.

"},{"location":"level101/messagequeue/intro/#comparsion","title":"Comparsion","text":"Performance Scalability Flexibility Complexity Functionality Ease of Use General-purpose MQ Moderate Moderate High Moderate High Moderate Pub/Sub Moderate to High High High Moderate Moderate to High Moderate to High Stream processing High High Moderate to High High High Moderate Brokerless High Moderate Moderate Low to Moderate Moderate High Database-as-queue Low to Moderate Low to Moderate Moderate Low Low to Moderate High"},{"location":"level101/messagequeue/key_concepts/","title":"Key Concepts","text":"

Let's looks at some of the key concepts when we talk about messaging system

"},{"location":"level101/messagequeue/key_concepts/#delivery-guarantees","title":"Delivery guarantees","text":"

One of the essential aspects of messaging services is ensuring that messages are delivered to their intended recipients. Different systems offer varying levels of delivery guarantees, and it is crucial to understand these guarantees to choose the right messaging service for your needs.

Selecting the right delivery guarantee depends on the specific requirements of your application. For example, in financial transactions, an exactly-once delivery guarantee is essential to avoid double-processing of payments or missed transactions. In contrast, a log monitoring system may only require at-most-once delivery to reduce system overhead.

"},{"location":"level101/messagequeue/key_concepts/#messages-ordering-and-parallelism","title":"Messages ordering and parallelism","text":"

Ensuring the correct order of messages and processing them in parallel can be a challenge in distributed messaging systems. The following strategies help maintain order and ensure parallelism:

Strategies to maintain order and ensure parallelism: Partitioning messages by a key, using sequencing numbers, and buffering can help maintain order while still allowing parallel processing. It is crucial to strike the right balance between ordering requirements and parallelism to optimize system performance.

"},{"location":"level101/messagequeue/key_concepts/#fan-out-in","title":"Fan Out / In","text":"

Fan out and fan in are two crucial concepts in messaging systems that deal with the distribution of messages among multiple consumers and the aggregation of messages from multiple producers, respectively.

"},{"location":"level101/messagequeue/key_concepts/#fan-out","title":"Fan Out","text":"

Fan out is a pattern where a single message is sent to multiple consumers, ensuring that each consumer receives a copy of the message. This can be achieved using the Publish-Subscribe (Pub/Sub) messaging pattern or by creating multiple bindings with unique routing keys in a message broker like RabbitMQ. Fan out is useful in scenarios where multiple services or applications need to process the same messages independently, such as sending notifications to multiple subscribers or replicating data across multiple databases.

"},{"location":"level101/messagequeue/key_concepts/#fan-in","title":"Fan In","text":"

Fan in is a pattern where messages from multiple producers are aggregated and processed by a single consumer or a group of consumers. This can be achieved by using a message broker with multiple producers sending messages to a shared queue, which is then consumed by one or more consumers. Fan in is beneficial when you need to centralize processing or consolidate data from multiple sources, such as aggregating logs from various services or combining sensor data from multiple IoT devices.

"},{"location":"level101/messagequeue/key_concepts/#poison-pills-and-dead-letters","title":"Poison Pills and Dead Letters","text":"

In messaging systems, poison pills are problematic messages that can cause failures or crashes in the message processing pipeline. To handle these messages, messaging services often employ Dead Letter Queues (DLQs).

A poison pill is a message that cannot be processed due to various reasons, such as invalid format, missing information, or incorrect data. When a consumer encounters a poison pill, it must handle it gracefully to avoid crashing or getting stuck in an infinite processing loop.

A Dead Letter Queues (DLQ) is a separate queue used to store poison pills or messages that could not be processed successfully. Instead of discarding problematic messages, they are redirected to a DLQ, allowing engineers to analyze and resolve the issues.

To handle poison pills effectively, you can implement error handling and monitoring, set up retries with backoff policies, and use DLQs for further analysis and resolution. Regularly monitor the DLQ, identify patterns causing poison pills, and implement fixes in the message processing pipeline to prevent future issues.

"},{"location":"level101/messagequeue/key_concepts/#messaging-patterns","title":"Messaging Patterns","text":""},{"location":"level101/messagequeue/key_concepts/#point-to-point-queue-based","title":"Point-to-Point (Queue-based)","text":"

In this pattern, messages are sent from a single producer to a single consumer via a message queue. The message is consumed by only one consumer, even if there are multiple consumers listening to the queue. This pattern ensures that the message is processed by a single consumer, making it suitable for scenarios where messages must be processed in sequence or by specific consumers.

"},{"location":"level101/messagequeue/key_concepts/#publish-subscribe-pattern","title":"Publish-subscribe pattern","text":"

The publish-subscribe pattern involves a producer sending messages to a topic, and multiple consumers subscribing to that topic to receive the messages. This pattern allows for one-to-many communication, where a single message can be delivered to multiple consumers simultaneously. It is ideal for event-driven architectures and applications that require real-time updates or notifications.

"},{"location":"level101/metrics_and_monitoring/alerts/","title":"Proactive Monitoring with Alerts","text":""},{"location":"level101/metrics_and_monitoring/alerts/#_1","title":"Proactive Monitoring with Alerts","text":""},{"location":"level101/metrics_and_monitoring/alerts/#proactive-monitoring-using-alerts","title":"Proactive monitoring using alerts","text":"

Earlier we discussed different ways to collect key metric data points from a service and its underlying infrastructure. This data gives us a better understanding of how the service is performing. One of the main objectives of monitoring is to detect any service degradations early (reduce Mean Time To Detect) and notify stakeholders so that the issues are either avoided or can be fixed early, thus reducing Mean Time To Recover (MTTR). For example, if you are notified when resource usage by a service exceeds 90%, you can take preventive measures to avoid any service breakdown due to a shortage of resources. On the other hand, when a service goes down due to an issue, early detection and notification of such incidents can help you quickly fix the issue.

Figure 8: An alert notification received on Slack

Today most of the monitoring services available provide a mechanism to set up alerts on one or a combination of metrics to actively monitor the service health. These alerts have a set of defined rules or conditions, and when the rule is broken, you are notified. These rules can be as simple as notifying when the metric value exceeds n to as complex as a week-over-week (WoW) comparison of standard deviation over a period of time. Monitoring tools notify you about an active alert, and most of these tools support instant messaging (IM) platforms, SMS, email, or phone calls. Figure 8 shows a sample alert notification received on Slack for memory usage exceeding 90% of total RAM space on the host.

"},{"location":"level101/metrics_and_monitoring/best_practices/","title":"Best Practices for Monitoring","text":""},{"location":"level101/metrics_and_monitoring/best_practices/#_1","title":"Best Practices for Monitoring","text":""},{"location":"level101/metrics_and_monitoring/best_practices/#best-practices-for-monitoring","title":"Best practices for monitoring","text":"

When setting up monitoring for a service, keep the following best practices in mind.

For more information about these metric types, see Data Types.

"},{"location":"level101/metrics_and_monitoring/command-line_tools/","title":"Command-line Tools","text":""},{"location":"level101/metrics_and_monitoring/command-line_tools/#_1","title":"Command-line Tools","text":""},{"location":"level101/metrics_and_monitoring/command-line_tools/#command-line-tools","title":"Command-line tools","text":"

Most of the Linux distributions today come with a set of tools that monitor the system's performance. These tools help you measure and understand various subsystem statistics (CPU, memory, network, and so on). Let's look at some of the tools that are predominantly used.

Figure 2: Results of top command

Figure 3: List of listening sockets on a system

Figure 4: Memory statistics on a host in human-readable form

Figure 5: Disk usage statistics on a system in human-readable form

Figure 6: Network bandwidth usage by active connection on the host

Figure 7: tcpdump of packets on docker0 interface on a host

"},{"location":"level101/metrics_and_monitoring/conclusion/","title":"Conclusion","text":"

A robust monitoring and alerting system is necessary for maintaining and troubleshooting a system. A dashboard with key metrics can give you an overview of service performance, all in one place. Well-defined alerts (with realistic thresholds and notifications) further enable you to quickly identify any anomalies in the service infrastructure and in resource saturation. By taking necessary actions, you can avoid any service degradations and decrease MTTD for service breakdowns.

In addition to in-house monitoring, monitoring real-user experience can help you to understand service performance as perceived by the users. Many modules are involved in serving the user, and most of them are out of your control. Therefore, you need to have real-user monitoring in place.

Metrics give very abstract details on service performance. To get a better understanding of the system and for faster recovery during incidents, you might want to implement the other two pillars of observability: logs and tracing. Logs and trace data can help you understand what led to service failure or degradation.

Following are some resources to learn more about monitoring and observability:

"},{"location":"level101/metrics_and_monitoring/conclusion/#references","title":"References","text":""},{"location":"level101/metrics_and_monitoring/introduction/","title":"Introduction","text":""},{"location":"level101/metrics_and_monitoring/introduction/#_1","title":"Introduction","text":""},{"location":"level101/metrics_and_monitoring/introduction/#prerequisites","title":"Prerequisites","text":""},{"location":"level101/metrics_and_monitoring/introduction/#what-to-expect-from-this-course","title":"What to expect from this course","text":"

Monitoring is an integral part of any system. As an SRE, you need to have a basic understanding of monitoring a service infrastructure. By the end of this course, you will gain a better understanding of the following topics:

"},{"location":"level101/metrics_and_monitoring/introduction/#what-is-not-covered-in-this-course","title":"What is not covered in this course","text":""},{"location":"level101/metrics_and_monitoring/introduction/#course-content","title":"Course content","text":"

Conclusion

"},{"location":"level101/metrics_and_monitoring/introduction/#_2","title":"Introduction","text":""},{"location":"level101/metrics_and_monitoring/introduction/#introduction","title":"Introduction","text":"

Monitoring is a process of collecting real-time performance metrics from a system, analyzing the data to derive meaningful information, and displaying the data to the users. In simple terms, you measure various metrics regularly to understand the state of the system, including but not limited to, user requests, latency, and error rate. What gets measured, gets fixed\u2014if you can measure something, you can reason about it, understand it, discuss it, and act upon it with confidence.

"},{"location":"level101/metrics_and_monitoring/introduction/#four-golden-signals-of-monitoring","title":"Four golden signals of monitoring","text":"

When setting up monitoring for a system, you need to decide what to measure. The four golden signals of monitoring provide a good understanding of service performance and lay a foundation for monitoring a system. These four golden signals are

These metrics help you to understand the system performance and bottlenecks, and to create a better end-user experience. As discussed in the Google SRE book, if you can measure only four metrics of your service, focus on these four. Let's look at each of the four golden signals.

Depending on the type of service, you can measure these signals in different ways. For example, you might measure queries per second served for a web server. In contrast, for a database server, transactions performed and database sessions created give you an idea about the traffic handled by the database server. With the help of additional code logic (monitoring libraries and instrumentation), you can measure these signals periodically and store them for future analysis. Although these metrics give you an idea about the performance at the service end, you need to also ensure that the same user experience is delivered at the client end. Therefore, you might need to monitor the service from outside the service infrastructure, which is discussed under third-party monitoring.

"},{"location":"level101/metrics_and_monitoring/introduction/#why-is-monitoring-important","title":"Why is monitoring important?","text":"

Monitoring plays a key role in the success of a service. As discussed earlier, monitoring provides performance insights for understanding service health. With access to historical data collected over time, you can build intelligent applications to address specific needs. Some of the key use cases follow:

Before we dive deeper into monitoring, let's understand some basic terminologies.

Before we discuss monitoring an application, let us look at the monitoring infrastructure. Following is an illustration of a basic monitoring system.

Figure 1: Illustration of a monitoring infrastructure

Figure 1 shows a monitoring infrastructure mechanism for aggregating metrics on the system, and collecting and storing the data for display. In addition, a monitoring infrastructure includes alert subsystems for notifying concerned parties during any abnormal behavior. Let's look at each of these infrastructure components:

"},{"location":"level101/metrics_and_monitoring/observability/","title":"Observability","text":""},{"location":"level101/metrics_and_monitoring/observability/#_1","title":"Observability","text":""},{"location":"level101/metrics_and_monitoring/observability/#observability","title":"Observability","text":"

Engineers often use observability when referring to building reliable systems. Observability is a term derived from control theory, it is a measure of how well internal states of a system can be inferred from knowledge of its external outputs. Service infrastructures used on a daily basis are becoming more and more complex; proactive monitoring alone is not sufficient to quickly resolve issues causing application failures. With monitoring, you can keep known past failures from recurring, but with a complex service architecture, many unknown factors can cause potential problems. To address such cases, you can make the service observable. An observable system provides highly granular insights into the implicit failure modes. In addition, an observable system furnishes ample context about its inner workings, which unlocks the ability to uncover deeper systemic issues.

Monitoring enables failure detection; observability helps in gaining a better understanding of the system. Among engineers, there is a common misconception that monitoring and observability are two different things. Actually, observability is the superset to monitoring; that is, monitoring improves service observability. The goal of observability is not only to detect problems, but also to understand where the issue is and what is causing it. In addition to metrics, observability has two more pillars: logs and traces, as shown in Figure 9. Although these three components do not make a system 100 percent observable, these are the most important and powerful components that give a better understanding of the system. Each of these pillars has its flaws, which are described in Three Pillars with Zero Answers.

Figure 9: Three pillars of observability

Because we have covered metrics already, let's look at the other two pillars (logs and traces).

"},{"location":"level101/metrics_and_monitoring/observability/#logs","title":"Logs","text":"

Logs (often referred to as events) are a record of activities performed by a service during its run time, with a corresponding timestamp. Metrics give abstract information about degradations in a system, and logs give a detailed view of what is causing these degradations. Logs created by the applications and infrastructure components help in effectively understanding the behavior of the system by providing details on application errors, exceptions, and event timelines. Logs help you to go back in time to understand the events that led to a failure. Therefore, examining logs is essential to troubleshooting system failures.

Log processing involves the aggregation of different logs from individual applications and their subsequent shipment to central storage. Moving logs to central storage helps to preserve the logs, in case the application instances are inaccessible, or the application crashes due to a failure. After the logs are available in a central place, you can analyze the logs to derive sensible information from them. For audit and compliance purposes, you archive these logs on the central storage for a certain period of time. Log analyzers fetch useful information from log lines, such as request user information, request URL (feature), and response headers (such as content length) and response time. This information is grouped based on these attributes and made available to you through a visualization tool for quick understanding.

You might be wondering how this log information helps. This information gives a holistic view of activities performed on all the involved entities. For example, let's say someone is performing a DoS (denial of service) attack on a web application. With the help of log processing, you can quickly look at top client IPs derived from access logs and identify where the attack is coming from.

Similarly, if a feature in an application is causing a high error rate when accessed with a particular request parameter value, the results of log analysis can help you to quickly identify the misbehaving parameter value and take further action.

Figure 10: Log processing and analysis using ELK stack

Figure 10 shows a log processing platform using ELK (Elasticsearch, Logstash, Kibana), which provides centralized log processing. Beats is a collection of lightweight data shippers that can ship logs, audit data, network data, and so on over the network. In this use case specifically, we are using Filebeat as a log shipper. Filebeat watches service log files and ships the log data to Logstash. Logstash parses these logs and transforms the data, preparing it to store on Elasticsearch. Transformed log data is stored on Elasticsearch and indexed for fast retrieval. Kibana searches and displays log data stored on Elasticsearch. Kibana also provides a set of visualizations for graphically displaying summaries derived from log data.

Storing logs is expensive. And extensive logging of every event on the server is costly and takes up more storage space. With an increasing number of services, this cost can increase proportionally to the number of services.

"},{"location":"level101/metrics_and_monitoring/observability/#tracing","title":"Tracing","text":"

So far, we covered the importance of metrics and logging. Metrics give an abstract overview of the system, and logging gives a record of events that occurred. Imagine a complex distributed system with multiple microservices, where a user request is processed by multiple microservices in the system. Metrics and logging give you some information about how these requests are being handled by the system, but they fail to provide detailed information across all the microservices and how they affect a particular client request. If a slow downstream microservice is leading to increased response times, you need to have detailed visibility across all involved microservices to identify such microservice. The answer to this need is a request tracing mechanism.

A trace is a series of spans, where each span is a record of events performed by different microservices to serve the client's request. In simple terms, a trace is a log of client-request serving derived from various microservices across different physical machines. Each span includes span metadata such as trace ID and span ID, and context, which includes information about transactions performed.

Figure 11: Trace and spans for a URL shortener request

Figure 11 is a graphical representation of a trace captured on the URL shortener example we covered earlier while learning Python.

Similar to monitoring, the tracing infrastructure comprises a few modules for collecting traces, storing them, and accessing them. Each microservice runs a tracing library that collects traces in the background, creates in-memory batches, and submits the tracing backend. The tracing backend normalizes received trace data and stores it on persistent storage. Tracing data comes from multiple different microservices; therefore, trace storage is often organized to store data incrementally and is indexed by trace identifier. This organization helps in the reconstruction of trace data and in visualization. Figure 12 illustrates the anatomy of the distributed system.

Figure 12: Anatomy of distributed tracing

Today a set of tools and frameworks are available for building distributed tracing solutions. Following are some of the popular tools:

"},{"location":"level101/metrics_and_monitoring/third-party_monitoring/","title":"Third-party Monitoring","text":""},{"location":"level101/metrics_and_monitoring/third-party_monitoring/#_1","title":"Third-party Monitoring","text":""},{"location":"level101/metrics_and_monitoring/third-party_monitoring/#third-party-monitoring","title":"Third-party monitoring","text":"

Today most cloud providers offer a variety of monitoring solutions. In addition, a number of companies such as Datadog offer monitoring-as-a-service. In this section, we are not covering monitoring-as-a-service in depth.

In recent years, more and more people have access to the Internet. Many services are offered online to cater to the increasing user base. As a result, web pages are becoming larger, with increased client-side scripts. Users want these services to be fast and error-free. From the service point of view, when the response body is composed, an HTTP 200 OK response is sent, and everything looks okay. But there might be errors during transmission or on the client-side. As previously mentioned, monitoring services from within the service infrastructure give good visibility into service health, but this is not enough. You need to monitor user experience, specifically the availability of services for clients. A number of third-party services such as Catchpoint, Pingdom, and so on are available for achieving this goal.

Third-party monitoring services can generate synthetic traffic simulating user requests from various parts of the world, to ensure the service is globally accessible. Other third-party monitoring solutions for real user monitoring (RUM) provide performance statistics such as service uptime and response time, from different geographical locations. This allows you to monitor the user experience from these locations, which might have different Internet backbones, different operating systems, and different browsers and browser versions. Catchpoint Global Monitoring Network is a comprehensive 3-minute video that explains the importance of monitoring the client experience.

"},{"location":"level101/python_web/intro/","title":"Python and The Web","text":""},{"location":"level101/python_web/intro/#prerequisites","title":"Prerequisites","text":""},{"location":"level101/python_web/intro/#what-to-expect-from-this-course","title":"What to expect from this course","text":"

This course is divided into two high-level parts. In the first part, assuming familiarity with Python language\u2019s basic operations and syntax usage, we will dive a little deeper into understanding Python as a language. We will compare Python with other programming languages that you might already know like Java and C. We will also explore concepts of Python objects and with help of that, explore Python features like decorators.

In the second part which will revolve around the web, and also assume familiarity with the Flask framework, we will start from the socket module and work with HTTP requests. This will demystify how frameworks like Flask work internally.

And to introduce SRE flavour to the course, we will design, develop and deploy (in theory) a URL-shortening application. We will emphasize parts of the whole process that are more important as an SRE of the said app/service.

"},{"location":"level101/python_web/intro/#what-is-not-covered-under-this-course","title":"What is not covered under this course","text":"

Extensive knowledge of Python internals and advanced Python.

"},{"location":"level101/python_web/intro/#lab-environment-setup","title":"Lab Environment Setup","text":"

Have latest version of Python installed

"},{"location":"level101/python_web/intro/#course-contents","title":"Course Contents","text":"
  1. The Python Language
    1. Some Python Concepts
    2. Python Gotchas
  2. Python and Web
    1. Sockets
    2. Flask
  3. The URL-Shortening App
    1. Design
    2. Scaling The App
    3. Monitoring The App
"},{"location":"level101/python_web/intro/#the-python-language","title":"The Python Language","text":"

Assuming you know a little bit of C/C++ and Java, let's try to discuss the following questions in context of those two languages and Python. You might have heard that C/C++ is a compiled language while Python is an interpreted language. Generally, with compiled language we first compile the program and then run the executable while in case of Python we run the source code directly like python hello_world.py. While Java, being an interpreted language, still has a separate compilation step and then it's run. So, what's really the difference?

"},{"location":"level101/python_web/intro/#compiled-vs-interpreted","title":"Compiled vs. Interpreted","text":"

This might sound a little weird to you: Python, in a way is a compiled language! Python has a compiler built-in! It is obvious in the case of Java since we compile it using a separate command, ie: javac helloWorld.java and it will produce a .class file which we know as a bytecode. Well, Python is very similar to that. One difference here is that there is no separate compile command/binary needed to run a Python program.

What is the difference then, between Java and Python? Well, Java's compiler is more strict and sophisticated. As you might know Java is a statically typed language. So the compiler is written in a way that it can verify types-related errors during compile time. While Python being a dynamic language, types are not known until a program is run. So in a way, Python compiler is dumb (or, less strict). But there indeed is a compile step involved when a Python program is run. You might have seen Python bytecode files with .pyc extension. Here is how you can see bytecode for a given Python program.

# Create a Hello World\n$ echo \"print('hello world')\" > hello_world.py\n\n# Making sure it runs\n$ python3 hello_world.py\nhello world\n\n# The bytecode of the given program\n$ python -m dis hello_world.py\n 1           0 LOAD_NAME                0 (print)\n             2 LOAD_CONST               0 ('hello world')\n             4 CALL_FUNCTION            1\n             6 POP_TOP\n             8 LOAD_CONST               1 (None)\n            10 RETURN_VALUE\n

Read more about dis module here.

Now coming to C/C++, there of course is a compiler. But the output is different than what Java/Python compiler would produce. Compiling a C program would produce what we also know as machine code, as opposed to bytecode.

"},{"location":"level101/python_web/intro/#running-the-programs","title":"Running The Programs","text":"

We know compilation is involved in all 3 languages we are discussing. Just that the compilers are different in nature and they output different types of content. In case of C/C++, the output is machine code which can be directly read by your operating system. When you execute that program, your OS will know how exactly to run it. But this is not the case with bytecode.

Those bytecodes are language specific. Python has its own set of bytecode defined (more in dis module) and so does Java. So naturally, your operating system will not know how to run it. To run this bytecode, we have something called Virtual Machines. Ie: The JVM or the Python VM (CPython, Jython). These so-called Virtual Machines are the programs which can read the bytecode and run it on a given operating system. Python has multiple VMs available. CPython is a Python VM implemented in C language, similarly Jython is a Java implementation of Python VM. At the end of the day, what they should be capable of is to understand Python language syntax, be able to compile it to bytecode and be able to run that bytecode. You can implement a Python VM in any language! (And people do so, just because it can be done)

                                                              The Operating System\n\n                                                              +------------------------------------+\n                                                              |                                    |\n                                                              |                                    |\n                                                              |                                    |\nhello_world.py                    Python bytecode             |         Python VM Process          |\n                                                              |                                    |\n+----------------+                +----------------+          |         +----------------+         |\n|print(...       |   COMPILE      |LOAD_CONST...   |          |         |Reads bytecode  |         |\n|                +--------------->+                +------------------->+line by line    |         |\n|                |                |                |          |         |and executes.   |         |\n|                |                |                |          |         |                |         |\n+----------------+                +----------------+          |         +----------------+         |\n                                                              |                                    |\n                                                              |                                    |\n                                                              |                                    |\nhello_world.c                     OS Specific machinecode     |         A New Process              |\n                                                              |                                    |\n+----------------+                +----------------+          |         +----------------+         |\n|void main() {   |   COMPILE      | binary contents|          |         | binary contents|         |\n|                +--------------->+                +------------------->+                |         |\n|                |                |                |          |         |                |         |\n|                |                |                |          |         |                |         |\n+----------------+                +----------------+          |         +----------------+         |\n                                                              |         (binary contents           |\n                                                              |         runs as is)                |\n                                                              |                                    |\n                                                              |                                    |\n                                                              +------------------------------------+\n

Two things to note for above diagram:

  1. Generally, when we run a Python program, a Python VM process is started which reads the Python source code, compiles it to bytecode and run it in a single step. Compiling is not a separate step. Shown only for illustration purpose.
  2. Binaries generated for C like languages are not exactly run as is. Since there are multiple types of binaries (eg: ELF), there are more complicated steps involved in order to run a binary but we will not go into that since all that is done at OS level.
"},{"location":"level101/python_web/python-concepts/","title":"Some Python Concepts","text":"

Though you are expected to know python and its syntax at basic level, let us discuss some fundamental concepts that will help you understand the Python language better.

Everything in Python is an object.

That includes the functions, lists, dicts, classes, modules, a running function (instance of function definition), everything. In the CPython, it would mean there is an underlying struct variable for each object.

In Python's current execution context, all the variables are stored in a dict. It'd be a string to object mapping. If you have a function and a float variable defined in the current context, here is how it is handled internally.

>>> float_number=42.0\n>>> def foo_func():\n...     pass\n...\n\n# NOTICE HOW VARIABLE NAMES ARE STRINGS, stored in a dict\n>>> locals()\n{'__name__': '__main__', '__doc__': None, '__package__': None, '__loader__': <class '_frozen_importlib.BuiltinImporter'>, '__spec__': None, '__annotations__': {}, '__builtins__': <module 'builtins' (built-in)>, 'float_number': 42.0, 'foo_func': <function foo_func at 0x1055847a0>}\n
"},{"location":"level101/python_web/python-concepts/#python-functions","title":"Python Functions","text":"

Since functions too are objects, we can see what all attributes a function contains as following

>>> def hello(name):\n...     print(f\"Hello, {name}!\")\n...\n>>> dir(hello)\n['__annotations__', '__call__', '__class__', '__closure__', '__code__', '__defaults__', '__delattr__', '__dict__',\n'__dir__', '__doc__', '__eq__', '__format__', '__ge__', '__get__', '__getattribute__', '__globals__', '__gt__',\n'__hash__', '__init__', '__init_subclass__', '__kwdefaults__', '__le__', '__lt__', '__module__', '__name__',\n'__ne__', '__new__', '__qualname__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__sizeof__', '__str__',\n'__subclasshook__']\n

While there are a lot of them, let's look at some interesting ones.

"},{"location":"level101/python_web/python-concepts/#globals","title":"globals","text":"

This attribute, as the name suggests, has references of global variables. If you ever need to know what all global variables are in the scope of this function, this will tell you. See how the function start seeing the new variable in globals

>>> hello.__globals__\n{'__name__': '__main__', '__doc__': None, '__package__': None, '__loader__': <class '_frozen_importlib.BuiltinImporter'>, '__spec__': None, '__annotations__': {}, '__builtins__': <module 'builtins' (built-in)>, 'hello': <function hello at 0x7fe4e82554c0>}\n\n# adding new global variable\n>>> GLOBAL=\"g_val\"\n>>> hello.__globals__\n{'__name__': '__main__', '__doc__': None, '__package__': None, '__loader__': <class '_frozen_importlib.BuiltinImporter'>, '__spec__': None, '__annotations__': {}, '__builtins__': <module 'builtins' (built-in)>, 'hello': <function hello at 0x7fe4e82554c0>, 'GLOBAL': 'g_val'}\n
"},{"location":"level101/python_web/python-concepts/#code","title":"code","text":"

This is an interesting one! As everything in Python is an object, this includes the bytecode too. The compiled Python bytecode is a Python code object. Which is accessible via __code__ attribute here. A function has an associated code object which carries some interesting information.

# the file in which function is defined\n# stdin here since this is run in an interpreter\n>>> hello.__code__.co_filename\n'<stdin>'\n\n# number of arguments the function takes\n>>> hello.__code__.co_argcount\n1\n\n# local variable names\n>>> hello.__code__.co_varnames\n('name',)\n\n# the function code's compiled bytecode\n>>> hello.__code__.co_code\nb't\\x00d\\x01|\\x00\\x9b\\x00d\\x02\\x9d\\x03\\x83\\x01\\x01\\x00d\\x00S\\x00'\n

There are more code attributes which you can enlist by >>> dir(hello.__code__).

"},{"location":"level101/python_web/python-concepts/#decorators","title":"Decorators","text":"

Related to functions, Python has another feature called decorators. Let's see how that works, keeping everything is an object in mind.

Here is a sample decorator:

>>> def deco(func):\n...     def inner():\n...             print(\"before\")\n...             func()\n...             print(\"after\")\n...     return inner\n...\n>>> @deco\n... def hello_world():\n...     print(\"hello world\")\n...\n>>>\n>>> hello_world()\nbefore\nhello world\nafter\n

Here @deco syntax is used to decorate the hello_world function. It is essentially same as doing

>>> def hello_world():\n...     print(\"hello world\")\n...\n>>> hello_world = deco(hello_world)\n

What goes inside the deco function might seem complex. Let's try to uncover it.

  1. Function hello_world is created
  2. It is passed to deco function
  3. deco create a new function
    1. This new function calls hello_world function
    2. And does a couple other things
  4. deco returns the newly created function
  5. hello_world is replaced with above function

Let's visualize it for better understanding

       BEFORE                   function_object (ID: 100)\n\n       \"hello_world\"            +--------------------+\n               +                |print(\"hello_world\")|\n               |                |                    |\n               +--------------> |                    |\n                                |                    |\n                                +--------------------+\n\n\n       WHAT DECORATOR DOES\n\n       creates a new function (ID: 101)\n       +---------------------------------+\n       |input arg: function with id: 100 |\n       |                                 |\n       |print(\"before\")                  |\n       |call function object with id 100 |\n       |print(\"after\")                   |\n       |                                 |\n       +---------------------------------+\n                                   ^\n                                   |\n       AFTER                       |\n                                   |\n                                   |\n       \"hello_world\" +-------------+\n

Note how the hello_world name points to a new function object but that new function object knows the reference (ID) of the original function.

"},{"location":"level101/python_web/python-concepts/#some-gotchas","title":"Some Gotchas","text":""},{"location":"level101/python_web/python-web-flask/","title":"Python, Web and Flask","text":"

Back in the old days, websites were simple. They were simple static html contents. A webserver would be listening on a defined port and according to the HTTP request received, it would read files from disk and return them in response. But since then, complexity has evolved and websites are now dynamic. Depending on the request, multiple operations need to be performed like reading from database or calling other API and finally returning some response (HTML data, JSON content, etc.)

Since serving web requests is no longer a simple task like reading files from disk and return contents, we need to process each HTTP request, perform some operations programmatically and construct a response.

"},{"location":"level101/python_web/python-web-flask/#sockets","title":"Sockets","text":"

Though we have frameworks like Flask, HTTP is still a protocol that works over TCP protocol. So, let us setup a TCP server and send an HTTP request and inspect the request's payload. Note that this is not a tutorial on socket programming but what we are doing here is inspecting HTTP protocol at its ground level and look at what its contents look like. (Ref: Socket Programming in Python (Guide) on RealPython)

import socket\n\nHOST = '127.0.0.1'  # Standard loopback interface address (localhost)\nPORT = 65432        # Port to listen on (non-privileged ports are > 1023)\n\nwith socket.socket(socket.AF_INET, socket.SOCK_STREAM) as s:\n   s.bind((HOST, PORT))\n   s.listen()\n   conn, addr = s.accept()\n   with conn:\n       print('Connected by', addr)\n       while True:\n           data = conn.recv(1024)\n           if not data:\n               break\n           print(data)\n

Then, we open localhost:65432 in our web browser and following would be the output:

Connected by ('127.0.0.1', 54719)\nb'GET / HTTP/1.1\\r\\nHost: localhost:65432\\r\\nConnection: keep-alive\\r\\nDNT: 1\\r\\nUpgrade-Insecure-Requests: 1\\r\\nUser-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.83 Safari/537.36 Edg/85.0.564.44\\r\\nAccept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9\\r\\nSec-Fetch-Site: none\\r\\nSec-Fetch-Mode: navigate\\r\\nSec-Fetch-User: ?1\\r\\nSec-Fetch-Dest: document\\r\\nAccept-Encoding: gzip, deflate, br\\r\\nAccept-Language: en-US,en;q=0.9\\r\\n\\r\\n'\n

Examine closely and the content will look like the HTTP protocol's format. ie:

HTTP_METHOD URI_PATH HTTP_VERSION\nHEADERS_SEPARATED_BY_SEPARATOR\n

So though it's a blob of bytes, knowing http protocol specification, you can parse that string (ie: split by \\r\\n) and get meaningful information out of it.

"},{"location":"level101/python_web/python-web-flask/#flask","title":"Flask","text":"

Flask, and other such frameworks does pretty much what we just discussed in the last section (with added more sophistication). They listen on a port on a TCP socket, receive an HTTP request, parse the data according to protocol format and make it available to you in a convenient manner.

That is you can access headers in Flask by request.headers which is made available to you by splitting above payload by /r/n, as defined in HTTP protocol.

Another example: we register routes in Flask by @app.route(\"/hello\"). What Flask will do is maintain a registry internally which will map /hello with the function you decorated with. Now, whenever a request comes with the /hello route (second component in the first line, split by space), Flask calls the registered function and returns whatever the function returned.

Same with all other web frameworks in other languages too. They all work on similar principles. What they basically do is understand the HTTP protocol, parses the HTTP request data and gives us programmers a nice interface to work with HTTP requests.

Not so much of magic in it?

"},{"location":"level101/python_web/sre-conclusion/","title":"Conclusion","text":""},{"location":"level101/python_web/sre-conclusion/#scaling-the-app","title":"Scaling The App","text":"

The design and development is just a part of the journey. We will need to setup continuous integration and continuous delivery pipelines sooner or later. And we have to deploy this app somewhere.

Initially, we can start with deploying this app on one virtual machine on any cloud provider. But this is a Single point of failure which is something we never allow as an SRE (or even as an engineer). So an improvement here can be having multiple instances of applications deployed behind a load balancer. This certainly prevents problems of one machine going down.

Scaling here would mean adding more instances behind the load balancer. But this is scalable upto only a certain point. After that, other bottlenecks in the system will start appearing. ie: DB will become the bottleneck, or perhaps the load balancer itself. How do you know what is the bottleneck? You need to have observability into each aspects of the application architecture.

Only after you have metrics, you will be able to know what is going wrong where. What gets measured, gets fixed!

Get deeper insights into scaling from School Of SRE's Scalability module and post going through it, apply your learnings and takeaways to this app. Think how will we make this app geographically distributed and highly available and scalable.

"},{"location":"level101/python_web/sre-conclusion/#monitoring-strategy","title":"Monitoring Strategy","text":"

Once we have our application deployed. It will be working okay. But not forever. Reliability is in the title of our job and we make systems reliable by making the design in a certain way. But things still will go down. Machines will fail. Disks will behave weirdly. Buggy code will get pushed to production. And all these possible scenarios will make the system less reliable. So what do we do? We monitor!

We keep an eye on the system's health and if anything is not going as expected, we want ourselves to get alerted.

Now let's think in terms of the given URL-shortening app. We need to monitor it. And we would want to get notified in case something goes wrong. But we first need to decide what is that something that we want to keep an eye on.

  1. Since it's a web app serving HTTP requests, we want to keep an eye on HTTP Status codes and latencies
  2. Request volume again is a good candidate, if the app is receiving an unusual amount of traffic, something might be off.
  3. We also want to keep an eye on the database so depending on the database solution chosen. Query times, volumes, disk usage, etc.
  4. Finally, there also needs to be some external monitoring which runs periodic tests from devices outside of your data centers. This emulates customers and ensures that from customer point of view, the system is working as expected.
"},{"location":"level101/python_web/sre-conclusion/#applications-in-sre-role","title":"Applications in SRE role","text":"

In the world of SRE, Python is a widely used language for small scripts and tooling developed for various purposes. Since tooling developed by SRE works with critical pieces of infrastructure and has great power (to bring things down), it is important to know what you are doing while using a programming language and its features. Also it is equally important to know the language and its characteristics while debugging the issues. As an SRE having a deeper understanding of Python language, it has helped me a lot to debug very sneaky bugs and be generally more aware and informed while making certain design decisions.

While developing tools may or may not be part of SRE job, supporting tools or services is more likely to be a daily duty. Building an application or tool is just a small part of productionization. While there is certainly that goes in the design of the application itself to make it more robust, as an SRE you are responsible for its reliability and stability once it is deployed and running. And to ensure that, you\u2019d need to understand the application first and then come up with a strategy to monitor it properly and be prepared for various failure scenarios.

"},{"location":"level101/python_web/sre-conclusion/#optional-exercises","title":"Optional Exercises","text":"
  1. Make a decorator that will cache function return values depending on input parameters.
  2. Host the URL-shortening app on any cloud provider.
  3. Setup monitoring using many of the tools available like Catchpoint, Datadog, etc.
  4. Create a minimal Flask-like framework on top of TCP sockets.
"},{"location":"level101/python_web/sre-conclusion/#conclusion_1","title":"Conclusion","text":"

This module, in the first part, aims to make you more aware of the things that will happen when you choose Python as your programming language and what happens when you run a Python program. With the knowledge of how Python handles things internally as objects, lot of seemingly magic things in Python will start to make more sense.

The second part will first explain how a framework like Flask works using the existing knowledge of protocols like TCP and HTTP. It then touches the whole lifecycle of an application development lifecycle including the SRE parts of it. While the design and areas in architecture considered will not be exhaustive, it will give a good overview of things that are also important being an SRE and why they are important.

"},{"location":"level101/python_web/url-shorten-app/","title":"The URL Shortening App","text":"

Let's build a very simple URL-shortening app using Flask and try to incorporate all aspects of the development process including the reliability aspects. We will not be building the UI and we will come up with a minimal set of API that will be enough for the app to function well.

"},{"location":"level101/python_web/url-shorten-app/#design","title":"Design","text":"

We don't jump directly to coding. First thing we do is gather requirements. Come up with an approach. Have the approach/design reviewed by peers. Evolve, iterate, document the decisions and tradeoffs. And then finally implement. While we will not do the full blown design document here, we will raise certain questions here that are important to the design.

"},{"location":"level101/python_web/url-shorten-app/#1-high-level-operations-and-api-endpoints","title":"1. High Level Operations and API Endpoints","text":"

Since it's a URL-shortening app, we will need an API for generating the shorten link given an original link. And an API/Endpoint which will accept the shorten link and redirect to original URL. We are not including the user aspect of the app to keep things minimal. These two API should make app functional and usable by anyone.

"},{"location":"level101/python_web/url-shorten-app/#2-how-to-shorten","title":"2. How to shorten?","text":"

Given a URL, we will need to generate a shortened version of it. One approach could be using random characters for each link. Another thing that can be done is to use some sort of hashing algorithm. The benefit here is we will reuse the same hash for the same link. Ie: if lot of people are shortening https://www.linkedin.com, they all will have the same value, compared to multiple entries in DB if chosen random characters.

What about hash collisions? Even in random characters approach, though there is a less probability, hash collisions can happen. And we need to be mindful of them. In that case, we might want to prepend/append the string with some random value to avoid conflict.

Also, choice of hash algorithm matters. We will need to analyze algorithms. Their CPU requirements and their characteristics. Choose one that suits the most.

"},{"location":"level101/python_web/url-shorten-app/#3-is-url-valid","title":"3. Is URL Valid?","text":"

Given a URL to shorten, how do we verify if the URL is valid? Do we even verify or validate? One basic check that can be done is see if the URL matches a regex of a URL. To go even further, we can try opening/visiting the URL. But there are certain gotchas here.

  1. We need to define success criteria. ie: HTTP 200 means it is valid.
  2. What if the URL is in private network?
  3. What if URL is temporarily down?
"},{"location":"level101/python_web/url-shorten-app/#4-storage","title":"4. Storage","text":"

Finally, storage. Where will we store the data that we will generate over time? There are multiple database solutions available and we will need to choose the one that suits this app the most. Relational database like MySQL would be a fair choice but be sure to checkout School of SRE's SQL database section and NoSQL databases section for deeper insights into making a more informed decision.

"},{"location":"level101/python_web/url-shorten-app/#5-other","title":"5. Other","text":"

We are not accounting for users into our app and other possible features like rate limiting, customized links, etc. but it will eventually come up with time. Depending on the requirements, they too might need to get incorporated.

The minimal working code is given below for reference, but I'd encourage you to come up with your own.

from flask import Flask, redirect, request\nfrom hashlib import md5\n\napp = Flask(\"url_shortener\")\n\nmapping = {}\n\n@app.route(\"/shorten\", methods=[\"POST\"])\ndef shorten():\n    global mapping\n    payload = request.json\n\n    if \"url\" not in payload:\n        return \"Missing URL Parameter\", 400\n\n    # TODO: check if URL is valid\n\n    hash_ = md5()\n    hash_.update(payload[\"url\"].encode())\n    digest = hash_.hexdigest()[:5]  # limiting to 5 chars. Less the limit more the chances of collission\n\n    if digest not in mapping:\n        mapping[digest] = payload[\"url\"]\n        return f\"Shortened: r/{digest}\\n\"\n    else:\n        # TODO: check for hash collission\n        return f\"Already exists: r/{digest}\\n\"\n\n\n@app.route(\"/r/<hash_>\")\ndef redirect_(hash_):\n    if hash_ not in mapping:\n        return \"URL Not Found\", 404\n    return redirect(mapping[hash_])\n\n\nif __name__ == \"__main__\":\n    app.run(debug=True)\n\n\"\"\"\nOUTPUT:\n\n\n===> SHORTENING\n\n$ curl localhost:5000/shorten -H \"content-type: application/json\" --data '{\"url\":\"https://linkedin.com\"}'\nShortened: r/a62a4\n\n\n===> REDIRECTING, notice the response code 302 and the location header\n\n$ curl localhost:5000/r/a62a4 -v\n* Uses proxy env variable NO_PROXY == '127.0.0.1'\n*   Trying ::1...\n* TCP_NODELAY set\n* Connection failed\n* connect to ::1 port 5000 failed: Connection refused\n*   Trying 127.0.0.1...\n* TCP_NODELAY set\n* Connected to localhost (127.0.0.1) port 5000 (#0)\n> GET /r/a62a4 HTTP/1.1\n> Host: localhost:5000\n> User-Agent: curl/7.64.1\n> Accept: */*\n>\n* HTTP 1.0, assume close after body\n< HTTP/1.0 302 FOUND\n< Content-Type: text/html; charset=utf-8\n< Content-Length: 247\n< Location: https://linkedin.com\n< Server: Werkzeug/0.15.4 Python/3.7.7\n< Date: Tue, 27 Oct 2020 09:37:12 GMT\n<\n<!DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML 3.2 Final//EN\">\n<title>Redirecting...</title>\n<h1>Redirecting...</h1>\n* Closing connection 0\n<p>You should be redirected automatically to target URL: <a href=\"https://linkedin.com\">https://linkedin.com</a>.  If not click the link.\n\"\"\"\n
"},{"location":"level101/security/conclusion/","title":"Conclusion","text":"

Now that you have completed this course on Security you are now aware of the possible security threats to computer systems & networks. Not only that, but you are now better able to protect your systems as well as recommend security measures to others.

This course provides fundamental everyday knowledge on security domain which will also help you keep security at the top of your priority.

"},{"location":"level101/security/conclusion/#other-resources","title":"Other Resources","text":"

Some books that would be a great resource

"},{"location":"level101/security/conclusion/#post-training-asks-further-reading","title":"Post Training asks/ Further Reading","text":""},{"location":"level101/security/fundamentals/","title":"Part I: Fundamentals","text":""},{"location":"level101/security/fundamentals/#introduction-to-security-overview-for-sre","title":"Introduction to Security Overview for SRE","text":"