# Step 4: Distributed Database Sharding

> # Distributed Database Sharding

> A powerful capability of xSQL is its ability to manage a single in-memory or persistent database distributed across a cluster of network nodes. To demonstrate this, we will use the configuration files (more about configuration files in step 5) found in the SDK directory `samples/xsql/configs/shards` to launch xSQL in three separate command console windows. This example demonstrates a simple distributed in-memory database working with 2 shards managed by xSQL servers; each shard holds only part of the database.

> To start the servers, open 3 console windows, navigate to `samples/xsql/configs/shards` and in console 1 type:

>         On Unix-Linux:
>         ../../../../target/bin/xsql -c shard1.cfg –i

>         On Windows:
>         ..\..\..\..\target\bin\xsql -c shard1.cfg –i

> In console 2 type:

>         On Unix-Linux:
>         ../../../../target/bin/xsql -c shard2.cfg -i

>         On Windows:
>         ..\..\..\..\target\bin\xsql -c shard2.cfg –i

> Then start an xSQL client in one more console window(s) by typing:

>         On Unix-Linux:
>         ../../../../target/bin/xsql -c client.cfg -i

>         On Windows:
>         ..\..\..\..\target\bin\xsql -c client.cfg –i

> Now execute the following 3 queries in the xSQL client (console 3):

>         XSQL>1:select * from Employee;
>         name    dept_no
>         -------------------------------
>         Han Solo        1
>         Luke Skywalker  1

>         Selected records: 2

>         XSQL>2:select * from Employee;
>         name    dept_no
>         -------------------------------
>         Darth Vader     2

>         Selected records: 1

>         XSQL>select * from Employee;
>         name    dept_no
>         -------------------------------
>         Han Solo        1
>         Luke Skywalker  1
>         Darth Vader     2

>         Selected records: 3

> Note that the leading “`1:`” tells xSQL to access the shard in server 1, and likewise “`2:`” accesses the shard on server 2. Executing a select without specifying a server number causes xSQL to aggregate the results from the `select` on each server - the shards contain only parts of the database.

> Clearly the configurations files, `shard1.cfg`, `shard2.cfg` and `client.cfg` are performing some hidden operations here. We will explain and demonstrate more about config files in the next step.