1) Should these tests use real database data? I mean I'll have to connect to a real database?
If you're testing the integration between your software and the database, then yes you should use the real database (ideally down to the version you will be using in production). If the database isn't supposed to be part of your tests, you might be able to substitute some other storage mechanism (might be possible if you use an adapter pattern or a database abstraction library). Note that if you manually write queries, the SQL is likely database dependent so you cannot substitute a different database.
2) I suppose I cannot use common database, I should use my private database for this but my colleges cannot use my tests because they won't have my database. What to do then?
The database used for testing should only be used for that test during the test run. Afterwards it can be cleared and used for another test run. Therefore, you do need dedicated test databases. Ideally this DB runs locally on your development machine, but managing them centrally would also work (might even be necessary if you have to comply with proprietary licenses).
Because your software will run with different production and test databases, you need the specific database to be configurable – e.g. by reading a connection string from an environment variable. Do not put any information that differs between environments into config files if those config files are checked in to version control. Instead, implement a way to use private configurations, e.g. by providing the config as a command line argument or as environment variables. It is of course OK to check in config templates or configs for specific environments, e.g. the production config.
3) I'll have to pass real data to controllers or I can come up with random data? Same question to database data. If real than I'll need to get data from browser and the other things...
You may not be allowed to use real data due to legal constraints, e.g. privacy regulations such as HIPAA or GDPR. There's also the risk that real data could accidentally cause real-world actions if your testing setup is buggy, such as sending out emails or incurring charges for third party systems.
Instead, prefer simulating a scenario and using that data. If your software has a user interface you could manually play through a scenario and capture this data to replay it later. I've also gathered test data by parsing debug-level log files and manually scrubbing them from any personal data (e.g. exact timestamps, IP addresses, names, emails, …).
4) Do I really need these integration tests if I tested this interactions in unit tests? I just used mocks instead of real data.
If you used mocks you tested one half of the interface, but not the integration of both halves interfaces. This is like testing that an electric socket has power, and testing that a plug has the correct shape, but not testing whether the device runs when you plug it into the socket.
Unit tests are very useful to carefully test some component in isolation, but they are usually not suitable as a primary testing strategy. Especially for web apps, it is usually much easier to run end to end tests (possibly on the scale of integration or system tests). Relevant browser automation tools are widely available, and even more tools if you just need to test a REST API.
5) Won't it be system testing instead of integration?
A integration test integrates some but not all components, others will be replaced by stubs. A system test includes all real components. Typically, integration tests still exclude third party services and only integrate local components.